Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Ubuntu tietokoneissa => Aiheen aloitti: FUbu - 15.05.07 - klo:20.58
-
Tiedetään "Pielessä" on suhteellinen käsite, mutta sanotaan että täyttä tehoa ei saa irti nopeista ADSL liittymistä yksittäisellä TCP/IP connectionilla esim jenkkeihin (150-300ms) ilman tweakkausta.
Ensin:
Noista tweakkauksista tuli mieleen, että miten ihmeessä Ubuntussa voi olla niin huonot TCP/IP pinon asetukset oletuksena kun siinä on? Suurimpana ongelmana näin Window Scalingin puuttumisen. Pudotti verkkoyhteyden nopeudesta monissa isommissa siirroissa puolet pois. Samoin SACK ei ollut käytössä. Jotka molemmat on kyllä selkeästi tätä päivää. Renon tilalle vois pistää kyllä tietysti vielä jotain fiksumpaa.
Sinänsä oletin että verkko-hommat olisivat Linuxissa paremmalla mallilla kuin esim Vistassa oletuksena.
Mielenkiintoista taustatietoa: http://www.microsoft.com/technet/community/columns/cableguy/cg1105.mspx
Renon tilalle voisi pistää vaikka Vegasin, Reno tuottaa usein ongelmia mm. nettiradion kanssa jos puskuri on pieni, kun yhteys "tökkii niin pahasti" aina jos paketti katoaa.
Sitten:
No niin! Nyt kun rynkkäsin Ubuntu TCP/IP stack jutut kuntoon on suorituskyky jenkki siteihin noin kaksinkertainen verrattuna alkuperäisiin ja Windowssin (XP) vastaaviin asetuksiin.
~40-50 kt / siirtonopeus on kasvanut kaistan täyteen eli 95 kt/s tasolle ja olisi kyllä mennyt pidemmällekkin selvästi jos vaan kaistaa olisi. Samoin download nopeudet noin nelinkertaistuivat, 200kt/s -> 800kt/s tasolle.
Käytössä Window Scaling, Maksimi ikkuna 512kilotavua, sack, fack, dscak ja Vegas stackki. Timestampit jätin tarkoituksella pois koska tutkittuani tilannetta huomasin että yhteydessä on vain viivettä, ei packet lossia. (alle 1%. loss)
Tietysti jotta homma pelaa, pitää myös vastapäässä olla verme joka tukee tätä. Jos siellä ei ole Window scaling käytössä ei merkittävää hyötyä tule. Vegas auttaa (lähettävässä päässä) sen verran että jos paketti putoaa windowia ei pienennetä niin rankalla kädellä. TCPDUMPin tiedoista päätellen myös ikkunan kasvatus oli nopeaa eikä sitä N+1 vaan N*2 tasoa.
Nyt rullaa bitit todella hienosti...
Ref:
www.safe-mail.net
Ping-tilastot 213.8.161.230:
Paketit: Lähetetty = 100, Vastaanotettu = 100, Kadonnut = 0 (0% hävikki),
Arvioitu kiertoaika millisekunteina:
Pienin = 195 ms, Suurin = 201 ms, Keskiarvo = 196 ms
www.afterdawn.com
Ping-tilastot 70.85.60.100:
Paketit: Lähetetty = 100, Vastaanotettu = 100, Kadonnut = 0 (0% hävikki),
Arvioitu kiertoaika millisekunteina:
Pienin = 146 ms, Suurin = 152 ms, Keskiarvo = 147 ms
http://forum.ubuntu-fi.org
Ping-tilastot 69.60.114.102:
Paketit: Lähetetty = 100, Vastaanotettu = 100, Kadonnut = 0 (0% hävikki),
Arvioitu kiertoaika millisekunteina:
Pienin = 157 ms, Suurin = 162 ms, Keskiarvo = 158 ms
-
Kuulostaa hyvältä...oliskohan mahdollista, että kertoisit miten nuo säädöt olet tehnyt...? tai ainakin linkkaisit joitain sivuja mistä olet ohjeita löytänyt? ;)
-
Opas tuonne wikiin olisi kova (http://www.ubuntu-fi.org/Wiki/Wiki ) mutta kerro nyt vähintään tässä miten sen teit..
r
-
juu kiinnostas muakin
-
Noista tweakkauksista tuli mieleen, että miten ihmeessä Ubuntussa voi olla niin huonot TCP/IP pinon asetukset oletuksena kun siinä on?
Jospa niitä säädetään vaikkapa tällä pienellä ohjeella:
http://dsd.lbl.gov/TCP-tuning/linux.html
Ystävällisin terveisin Asmo Koskinen.
-
www.safe-mail.net
Pienin = 195 ms, Suurin = 201 ms, Keskiarvo = 196 ms
www.afterdawn.com
Pienin = 146 ms, Suurin = 152 ms, Keskiarvo = 147 ms
http://forum.ubuntu-fi.org
Pienin = 157 ms, Suurin = 162 ms, Keskiarvo = 158 ms
Minulla näin, mitähän tämän nyt sitten pitäisi kertoa? Käytössä on realtime-kernel:
koskias@ubuntu:~$ uname -a
Linux ubuntu 2.6.20-15-realtime #2 SMP PREEMPT Tue Apr 24 01:53:29 UTC 2007 i686 GNU/Linux
koskias@ubuntu:~$
koskias@ubuntu:~$ ping -c 5 safe-mail.net
PING safe-mail.net (213.8.161.230) 56(84) bytes of data.
64 bytes from tapuz.safe-mail.net (213.8.161.230): icmp_seq=1 ttl=37 time=208 ms
64 bytes from tapuz.safe-mail.net (213.8.161.230): icmp_seq=2 ttl=37 time=212 ms
64 bytes from tapuz.safe-mail.net (213.8.161.230): icmp_seq=3 ttl=37 time=208 ms
64 bytes from tapuz.safe-mail.net (213.8.161.230): icmp_seq=4 ttl=37 time=210 ms
64 bytes from tapuz.safe-mail.net (213.8.161.230): icmp_seq=5 ttl=37 time=209 ms
--- safe-mail.net ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 8217ms
rtt min/avg/max/mdev = 208.335/209.658/212.148/1.416 ms
koskias@ubuntu:~$
koskias@ubuntu:~$ ping -c 5 afterdawn.com
PING afterdawn.com (70.85.60.100) 56(84) bytes of data.
64 bytes from www2.afterdawn.net (70.85.60.100): icmp_seq=1 ttl=34 time=184 ms
64 bytes from www2.afterdawn.net (70.85.60.100): icmp_seq=2 ttl=34 time=184 ms
64 bytes from www2.afterdawn.net (70.85.60.100): icmp_seq=3 ttl=34 time=184 ms
64 bytes from www2.afterdawn.net (70.85.60.100): icmp_seq=4 ttl=34 time=184 ms
64 bytes from www2.afterdawn.net (70.85.60.100): icmp_seq=5 ttl=33 time=184 ms
--- afterdawn.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 184.072/184.720/184.994/0.506 ms
koskias@ubuntu:~$
koskias@ubuntu:~$ ping -c 5 ubuntu-fi.org
PING ubuntu-fi.org (69.60.114.112) 56(84) bytes of data.
64 bytes from zambezi.serverpronto.com (69.60.114.112): icmp_seq=1 ttl=37 time=168 ms
64 bytes from zambezi.serverpronto.com (69.60.114.112): icmp_seq=2 ttl=37 time=171 ms
64 bytes from zambezi.serverpronto.com (69.60.114.112): icmp_seq=3 ttl=37 time=173 ms
64 bytes from zambezi.serverpronto.com (69.60.114.112): icmp_seq=4 ttl=37 time=168 ms
64 bytes from zambezi.serverpronto.com (69.60.114.112): icmp_seq=5 ttl=37 time=169 ms
--- ubuntu-fi.org ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 168.430/170.246/173.973/2.132 ms
koskias@ubuntu:~$
Ystävällisin terveisin Asmo Koskinen.
-
Tässä on mainio testeri:
http://www.speedguide.net/analyzer.php
Tältä näyttää optimoituna:
TCP options string: 020405b40103030301010402
MSS: 1460
MTU: 1500
TCP Window: 385440 (multiple of MSS)
RWIN Scaling: 3
Unscaled RWIN : 48180
Reccomended RWINs: 64240, 128480, 256960, 513920
BDP limit (200ms): 15418kbps (1927KBytes/s)
BDP limit (500ms): 6167kbps (771KBytes/s)
MTU Discovery: ON
TTL: 242
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)
Tärkeintä on siis SACKs, MTU discovery sekä se että RWIN on riittävän iso kuten tässä: 385440
BDP laskee suoraan jos ikkuna on liian pieni. Tuosta se hyöty tulee jonka ilmaisin tuolla alussa. Nyt siis vielä 500ms:n latenssilla saadaan tulemaan melkein 8 megasen täydeltä tavaraa. Jos RWIN on pieni ei jenkeistä saa millään kamaa kunnon vauhdilla koska silloin on 200ms latenssi.
-
« SpeedGuide.net TCP Analyzer Results »
TCP options string: 020405b40402080a0046e0fa0000000001030302
MSS: 1460
MTU: 1500
TCP Window: 5840 (multiple of MSS)
RWIN Scaling: 2
Unscaled RWIN : 1460
Reccomended RWINs: 64240, 128480, 256960, 513920
BDP limit (200ms): 234kbps (29KBytes/s)
BDP limit (500ms): 93kbps (12KBytes/s)
MTU Discovery: ON
TTL: 49
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)
Consider increasing your RWIN value to optimize TCP/IP for broadband.
miten tuota RWIN valueta suurennetaan??
haluaa nopeampaa yhteyttä!
-
Minä en kans ymmärrä mitään näistä tuloksista. Miksi suurempi "viive" (latency) on parempi kuin pienempi?
Tässä mun tulokset ilman mitään säätämistä. Kaikki tarpeelliseksi mainitsemasi ovat minulla ilmeisesti päällä.
« SpeedGuide.net TCP Analyzer Results »
Tested on: 05.17.2007 14:58
IP address: 82.141.xxx.xx
TCP options string: 020405980402080a00282fbb0000000001030305
MSS: 1432
MTU: 1472
TCP Window: 5856 (NOT multiple of MSS)
RWIN Scaling: 5
Unscaled RWIN : 183
Reccomended RWINs: 63008, 126016, 252032, 504064
BDP limit (200ms): 234kbps (29KBytes/s)
BDP limit (500ms): 94kbps (12KBytes/s)
MTU Discovery: ON
TTL: 44
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)
-
Fubu: voisitko meille tyhmille kertoa miten tuo käytännössä tehdään..Miten säätöjä tehdän, mitä mikäkin säätö tekee, minkälaiset arvot ovat tolkkuja ja mistä niitä voisi päätellä jne..
r
-
Elikkäs elikkäs, nuo muutokset tehdään ubuntussa /etc/sysctl.conf tiedostoon.
Lisää seuraavat tiedoston loppuun:
# increase TCP max buffer size
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# increase Linux autotuning TCP buffer limits
# min, default, and max number of bytes to use
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
#several tcp optimizations
net.ipv4.tcp_congestion_control = cubic
#vegas olisi parempi ylempään, mutta ubuntu ei tue oletusarvoisesti. voit toki koitaa sitäkin.
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_rfc1337 = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_moderate_rcvbuf = 1
# don't cache ssthresh from previous connection
net.ipv4.tcp_no_metrics_save = 1
# recommended to increase this for 1000 BT or higher
net.core.netdev_max_backlog = 2500
Tämän jälkeen sudo sysctl -p ja asetukset tulevat lennossa käyttöön.
Tämä esimerkki käyttää automaattista rwin-haistelua, eli rwin skaalautuu sen mukaan mitä yhteys antaa periksi. Tuo analysaattori kertoo edelleen 5860, mutta todellisuudessa se kyllä auto-tuunaa sen kohilleen. Analysaattori kun ei kerro kuin ensimmäisen paketin tiedot.
Tässä tuninki esimerkissä on noin parin kolmen tunnin lueskelun saldo.
lähteitä:
http://www.psc.edu/networking/projects/tcptune/
http://dsd.lbl.gov/TCP-tuning/linux.html
-
Tämä esimerkki käyttää automaattista rwin-haistelua, eli rwin skaalautuu sen mukaan mitä yhteys antaa periksi. Tuo analysaattori kertoo edelleen 5860, mutta todellisuudessa se kyllä auto-tuunaa sen kohilleen. Analysaattori kun ei kerro kuin ensimmäisen paketin tiedot.
Tässä tuninki esimerkissä on noin parin kolmen tunnin lueskelun saldo.
Samaa harrastit kuin minäkin tänään...
Mietinkin, miksi tuo analysaattori kertoo
Default TCP Receive Window (RWIN) = 6144
...RWIN seems to be set to a very small number.
kun taas tämä
http://www.dslreports.com/tweaks
puolestaan sanoo
Receive Window (RWIN): 412160
Tuolta kun klikkaa sivun alalaidasta vielä sitä more detail...-linkkiä niin...
-
« SpeedGuide.net TCP Analyzer Results »
Tested on: 05.20.2007 13:52
IP address: 85.156.xxx.xx
TCP options string: 020405b40101040201030309
MSS: 1460
MTU: 1500
TCP Window: 6144 (NOT multiple of MSS)
RWIN Scaling: 9
Unscaled RWIN : 12
Reccomended RWINs: 64240, 128480, 256960, 513920
BDP limit (200ms): 246kbps (31KBytes/s)
BDP limit (500ms): 98kbps (12KBytes/s)
MTU Discovery: ON
TTL: 43
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)
Mun RWIN on nyt 12 miksi näin??? nopeus nousi iha pikkasen, mulla on kasi meganen netti.
ja miksi tuo timestamps sammutettiin?
nyt pingatessa ei tuu enää lossia ja nopeudet nousi sielläkin 4ms
http://www.dslreports.com/tweaks
tuolla on server busy joten onko muita paikkoja joissa voi hyvin testata tuota RWIN:ä
EDIT: ja miksi tuo TTL pieneni?
-
http://www.dslreports.com/tweakr/block:45fc05d?service=dsl&speed=8000&os=Linux&via=normal
nyt aukes tämä ja tuolla tämä RWIN-value oli hyvä
-
Jos tuon moderate receive bufferin laittaa nollaan, niin alkaako RWIN silloin isompana? Tuli vielä tällainen optio mieleen.
Vista näyttää käyttävän oletuksena noin 64K ikkunaa ja suurentaa sitä nopeasti 2x / kopittelu. Eikä aina yhdellä paketilla (1.5k)
RWIN kasvaa Vistalla myös todella nopeasti samoin kuin Ubuntulla.
Ubuntu tuntuu käyttävän oletusarvoisesti kovin pientä RWINiä tämä voi hidastaa toimintaa esim web-sivujen selailussa. Kuten tämän foorumin tapauksessa. Koska RWIN kasvaa kopittelujen myötä ja jos latenssi on iso tapahtuu kopittelut hitaasti. (Round Trip Time siis).
Ubuntu forumin latenssi tuntuu olevan melkoinen täältä kotisuomesta. (177 ms)
sendspace.com palvelun kanssa huomasin oudon asian. Ubuntulla uploadit siteen samoille servereille kulkee yli kaksi kertaa nopeammin kuin XP:llä tai Vistalla. Tämä ihmetyttää minua suuresti. En keksi mitään muuta syytä asiaan kuin että toinen pää antaisi jostain syystä Ubuntun yhteydelle isomman RWINin kuin Windowssille. Mutta miksi, kun molempien pitäisi tuunattuna tukea samoja TCP/IP optioita ja riittävää ikkunaa.
Ehkä Windowssissa pitäisi jossain sallia myös SendWindow (remote receive window) scaling. Useimmissa tweakkauksissa keskitytään vain datan vastaanottamiseen, ei sen lähettämiseen.
Ja huom! Dokumenteissa on mainittu että jos SynCookiet on päällä, niin silloin Window Scaling putoaa pois. En näe mitään syytä miksi normaalin käyttäjän pitäisi käyttää SynCookieita. Ne ovat vain tarpeellisia DDoS hyökkäysten ilmetessä.
-
Viimeisen näkemyksen mukaan XP:n huono uppausvauhti johtuu siitä, että RWIN asetukset vaikuttavat nimenomaisesti vastaanottoon.
Eli:
Ubuntun oletusasetukset on huonot
WIndowssin (XP) oletusasetukset on huonot
Tweakkaamalalla saa seuraavan tilanteen aikaiseksi:
XP:ssä iso RWIN heti kättelyssä. - Eri kätevää.
Ubuntussa pienehkö RWIN heti kättelyssä. -> Kasvaa nopeasti - Ihan ok isompien tiedostojen siirtoon, ehkä heikoimmillaan juuri HTTP tms lyhyiden sessioiden käytössä.
XP:n lähetyspuoli ei kuitenkaan tunnu toimivan oikein, eli siinä jää tuo 64 Kibyten raja tökkimään.
Ubuntussa myös lähetyspuoli skaalaantuu kuten pitää ja siirtonopeudet ovat paremmat isompia tiedostoja lähetettäessä.
Kaiken säätämisen jälkeen tutkin vielä Vistan ja totesin että tässä pelaa kaikki oletuksena kuten pitää. RWIN on oletuksena kohtuullinen, mutta kasvaa nopeasti siitä kuten Ubuntussa. Myös lähetyspuolen skaalaus toimii ok.
Olipahan taas säätämistä moneksi illaksi. ;) Jokuhan täällä foorumeissa totesikin että kun se säätäminen on niin mahdottoman kivaa.
Nyt koneessa on siis kolme käyttistä ja kaikkia on tweakattu. Ubuntun kanssa on vielä pari ongelmaa miksi en käytä sitä pääsääntöisesti. Ne liittyvät tosin kaikki kaksoisnäyttö toimintoihin. Joista olen täällä kirjoitellut.
Jos joku nörtti-guru-propellihattumus vielä voisi vilkaista tuota http://forum.ubuntu-fi.org/index.php?topic=10431.0 - Kiitos!
-
Morjens,
Tämä asia putkahti takaisin mieleen luettuani Googlen tutkimuksen (http://code.google.com/speed/articles/tcp_initcwnd_paper.pdf), jossa todettiin että nykyaikaisista käyttöjärjestelmistä oikeastaan Linux (Ubuntu) on ainoa, joka kärsii tästä merkittävästi.
Jos et usko heti lukemaasi, niin vieraileppa tällä testaus sivulla. (http://www.speedguide.net/analyzer.php)
Koneellani saan tulokseksi 5888 tavua. Paljonko sinä sait? Windows Vista ilmoittaa tweakkaamattomilla oletusarvoilla 64 kilotavua. Asetin sysctl:llä minimiksi 64 kiloa, mutta siitä huolimatta testi näyttää nyt 6144 tavua.
Olen aina säätänyt Windowssissa asetukset kuntoon vaikka ne ovat oletusarvoiltaan jo huomattavasti paremmat. Ubuntun puolella oli iso yllätys, että oletusarvot ovat suorastaan esihistoriallisella tasolla. Eihän enää 2400 bps modeemeita käytetä, kuten vanhoina hyvinä aikoina.
Yritin Googlata korjausta asetukseen, mutta epäonnistuin säälittävästi. Korjauksen pitäisi onnistua Ip komennon ROUTE parametrin optiolla initcwnd jonka arvoksi asetetaan montako pakettia tcp initial receive window on. Tuntematta tarkemmin IP komennon parametrejä totesin homman noin puolen tunnin jälkeen turhan haastavaksi. Mistään ei lyödy nimittäin kunnollista esimerkkiä tai ohjetta.
Eikä man ip anna mitään kovin selkeää, vaikka minullakin näistä hommista pitkä kokemus on.
Joten nyt täytyy lähteä siitä liikenteeseen, että toivottavasti joku osaa, kun minä en osaa. Millä komennolla arvo muutetaan helposti ja mihin se pitää sijoittaa, jotta arvo on aina käytössä. Ehkä yrittämäni menetelmä on kokonaan väärä? sysctl:n kautta voi kyllä muuttaa autotuning toiminnon maksimi rajoja, mutta alussa käytettävää oletusarvoa tuolta ei pääse säätämään(?).
- Kiitos guruille!
Vielä tuosta ongelmastani:
ip route komennon kanssa ongelmia aiheutti lähinnä oudot virheilmoitukset ja toiminta.
ip route list, palauttaa listan reiteistä. Listassa on default ja yleisesti tuohon default routeen voidaan myös reitillä 0/0. Kuitenkin default tai 0/0 merkintöjen käyttö johtaa change komennon yhteydessä ilmoitukseen "RTNETLINK answers: No such device". Eli deviceä oltiin hakemassa, eikä routea? Ok.
Annetaan sitten tilalle device eth0 ja sitten tulee taas vastaukseksi että: "Error: an inet prefix is expected rather than "eth0""? Hieman jäin pattiin tuon kanssa.
Asiasta kiinnostuneille kevyttä välipalaa YouTubesta (http://www.youtube.com/watch?v=MStKwEff_kY).
-
Mulla näin----->>
« SpeedGuide.net TCP Analyzer Results »
Tested on: 06.30.2010 15:03
IP address: 84.249.xxx.xxx
Client OS: Linux
TCP options string: 020405b40402080a00824eb60000000001030306
MSS: 1460
MTU: 1500
TCP Window: 5888 (NOT multiple of MSS)
RWIN Scaling: 6 bits (2^6=64)
Unscaled RWIN : 92
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 236kbps (29KBytes/s)
BDP limit (500ms): 94kbps (12KBytes/s)
MTU Discovery: ON
TTL: 44
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)
-
TCP Window: 5888 (NOT multiple of MSS)
Tuossahan se suurin ongelma on. Eli esim, web sivua ei voida lähettää koneellesi kerralla, vaan se pitää lähettää monessa pienessä palassa. Sama koskee myös kaikkia muita rinnakkaisia yhteyksiä joita palvelimelle tai palvelimille muodostetaan.
Netti (varsinkin http / selailu siis) nopeutuisi olennaisesti, jos tuon arvon saisi pumpattua vaikka 64 kilon tietämille.
Mikä hienointa, osa web-palvelimista ei edes käytä keep-aliveä saati sitten pipeliningiä, joten noiden ominaisuuksien puutteen yhteydessä tuosta pienestä ikkunasta on vielä merkittävästi enemmän haittaa.
Onhan sinun selaimessasi pipelining päällä?
-
selaimen asetuksista en löytänyt tuonlaista asetusta :-(
Miten noita muita asetuksia pystyy muuttamaan?
Käytän chromium selainta (firefoxista en tykkää koska on hidas)
-
http://www.speedguide.net/read_articles.php?id=121 oletko noita katsellut
-
Keep in mind everything under /proc is volatile, so any changes you make are lost after reboot.
saako noi jotenkin pysyväksi?
-
http://www.speedguide.net/read_articles.php?id=121 oletko noita katsellut
Netistä näyttäisi löytyvän patcheja joilla voi korjata tuon auto tuninging initial windowin koon. Mutta ilmeisesti millään parametrillä sitä ei voi säätää. Tai ainakaan en sellaista löytänyt. Ainoa mikä siihen voisi vaikuttaa on tuo ip:n initcwnd mutta sekin on epäselvää tekeekö se parametri mitään kun auto-tuning on käytössä. Ongelman ydin on TCP/IP:n slow startti ja tässä tapauksessa se, että se on todellakin slow start.
TCP Slow Start (Wikipedia) (http://en.wikipedia.org/wiki/Slow-start)
Kuten sanoin, olen kyllä yrittänyt helpoimpia asioita ja lukenut aiheesta noin 10 tuntia. Joten mitään aivan triviaalia ratkaisua ei löytynyt mistään tähän asiaan. Kernel patchit ovat toistaiseksi olleet poissa laskuista, koska minulla ei ole siihen tarvittavaa osaamista, eikä aikaa (priorisointi kysymys) noin syvälliseen linux-opiskeluun.
-
Hieman on hakusessa mistä puhutte, mutta tweakkasin taannoin Firefoxin asetuksia ilman havaittavia muutoksia. Yleensä rukkausten vaikutus on ollut havaittavissa!
Eli, ymmärsinkö oikein: Yleiset verkkoasetukset toimivat "nopeudenrajoittimena" ja jonkun ohjelman asetusten säätö on osittain turhaa?
-
Hieman on hakusessa mistä puhutte, mutta tweakkasin taannoin Firefoxin asetuksia ilman havaittavia muutoksia. Yleensä rukkausten vaikutus on ollut havaittavissa!
Eli, ymmärsinkö oikein: Yleiset verkkoasetukset toimivat "nopeudenrajoittimena" ja jonkun ohjelman asetusten säätö on osittain turhaa?
Aivan näin. Varsinkin web-selailussa tuo pieni aloitusikkuna hidastaa merkittävästi tiedon siirtymistä. Niissä protokollissa jotka käyttää pitkään samaa sessiota, ongelmaa ei periaatteessa olekkaan. Eli suurin vaikutus on juuri http:n ja muihin lyhytkestoisten sessioiden protokolliin.
Valitettavasti on olemassa sivustoja jotka eivät tue keep-alivea ja pipelinigiä, jolloin vaikutus on aivan erityisen suuri.
Parhaiten tämä ilmenee esimerkiksi tilanteessa jossa lataat tiedostoa. Siirto alkaa hitaasti ja kiihtyy sitten vasta täyteen vauhtiin. Valitettavasti jokainen web-sivun lataus alkaa aina hitaasti. Säätämällä asetukset kuntoon saataisiin web-sivun lataus lähtemään heti alussa täydellä vauhdilla liikenteeseen. Mutta tämä korjaaminen ei onnistu mitenkään järkevästi Linuxissa, korjatkaa jos olen väärässä.
- Kiitos
-
Ok. Jatkan varovaisesti.
Firefoxin sivunlataus hidastui aavistuksen verran. Ja jos juoksen fleksin päässä hieman niin onkohan tämän selityksenä "järjestelmän sisäinen palvelunesto hyökkäys" tai ainakin jonkin asteinen ristiriita. Vaikuttaisi ihan loogiselta.
Täytynee palauttaa selaimen defaultit.
Edit: Läppärin akku imppautuu siltikin tyhjäksi alle vartissa, joten tuplakuormaa jäänee hurumykky! Mitä, mitä? Hävittiinkö joku skaba.