Vlákno názorů k článku
ADSL: co se stalo? (2.)

Chtel bych se zeptat, proc je agregace na koncentratorech zapnuta prave na urovni jednotlivych vlaken? Znamena to, ze to _nelze_ udelat na urovni IP adres (coz by bylo mnohem spravedlivejsi)? Znamena to take, ze kdyz si nejaky uzivatel pusti 50 threadu naraz, tak uz si ostatni uzivatele, kteri jsou s nim agregovani pres stejny DSLAM, ani nepingnou? Dekuji.

Vtip je v tom, že tomu tak není. Ačkoliv je to obecně zažitý mýtus, není pravda, že by ČTc měl nějakou technologii, která by byla schopna definovat rychlost pro jeden thread. Uvědomte si, že ČTc má velmi levný DSLAM hardware (výprodejový, několik let starý) a i routery za tím umístěné jsou pouze L3. Na to, abyste zjistil vlákno, byste musel jít do vyšších vrstev.
Vtip je opravdu v tom principu zahazování paketů - když totiž používáte nějaký mass downloader, tak ten používá vlastní techniku pro posílání paketů a zatímco běžný TCP protokol se dle standardu chová "standardně" tedy tak jak popisoval pan Peterka - maximálně 4 vlákna, každé po ztrátě paketu šlápne na brzu a začne od nejmenší rychlosti, tak mass downloader to nedělá a snaží se ji využívat stále naplno a při ztrátě paketu v jednom vlákně stále přijímá správně pakety v jiných vláknech a tak když zpomaluje jedno vlákno, tak ty další třeba stále jedou naplno a než spadne další vlákno, tak to první se zas dostane do maxima. Takže když dáíte dost velký počet vláken (10+) tak statisticky bude většina vláken stále na maximu.
Teoreticky by to šlo řešit používáním jiného ovladače pro TCP - pro linux to imho půjde relativně snadno upravit standardní tcp stack tak, aby se choval více agresivně. U windows se dá v registrech také něco měnit (většinou jsou takové optimalizace možné i klikáním v nějakých web acceleratorech - http://www.tucows.cz/accel95_default.html), žádné nastavení vám ale nedoporučím, krom toho se může lišit podle místa i času (když to optimalizují i na těch cisco).

Konecne nejakej zajimavej prispevek..nezkusil byste to rozvest??? Myslim, ze by to zajimalo spoustu uzivatelu..

Podla reakcii pouzivatelov musi telecom porusovat zmluvu. CAR je technologia, ktora vie iba zahadzovat pakety, ale nedokaze zvysovat oneskorenie pingov na 500 ms. T.j. prvy pokus o zavedenie agregacie zrejme bol realizovany cez CAR, ale toto musi byt nieco ine.

Car sice zahazuje packety, ale teprve pote, co mu pretece vystupni fronta na interfacu. A kdyz je fronta plna, tak logicky vidite i vetsi latenci, protoze dyl trva nez packet probubla na drat.

Tak to je perla, jak muze probublat nekam neco, co je zamerne zahozeno?!?!

CAR nezahazuje vsechny packety, to by moc uzitecny nebyl. Nahodne je vybira, tim casteji, cim je fronta delsi.

A kde se v tom zahozeni nachazi prostor pro cekani az na nej dojde rada?

Když je ICMP paket zahozenej, uvidíte po jedné vteřině (nebo kolik máte nastaven timeout) hvězdičku, je úplně jedno jestli se packet zahodí hned, nebo až po 800ms. Když vidíte 800ms pingy, je to proto, že packet zahozen nebyl, ale musel projít krz plnou FIFO frontu na interface, který jede do plna. A když se jede do plna, tak se přirozeně řeže, protože voda a packety jsou nestlačitelné. Už tomu rozumíš, ty jeden drzej ignorante?

Husy jsme nepasli a ignorant jste spise Vy (o Vasi drzosti rovnez svedci Vas pristup a mluva zde)... Vase moudra jsou toho dukazem.

U Vaseho popisu, co tech 800ms znamena se musi jezit vlasy na hlave kazdemu, kdo o ICMP protokolu zna jen zakladni veci a je schopen rozlisit rozdil mezi Request a Reply...

Nemate pravdu - to, co popisujete je Random Early Drop (RED). CAR, na Cisco IOSu konfigurovany pomoci prikazu "rate-limit", sleduje nastaveny limit (kontrakt) a v pripade jeho prekroceni muze provest nekolik akci, napr. zahozeni paketu, snizeni DSCP/IPprec prioriry atd. Podrobny popis prikazu "rate-limit" je zde:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_r/qrfcmd8.htm#1037428

Borek

myslim, ze ten prispevek je plny chyb - rozhodne zadny downloader nemuze ovlivnit jak se chova TCP spojeni. Proste proto, ze se chova jako kazda jina sitova aplikace. Stahuje data a jemu jedno jak je to tam "dole" udelany. Aby downloader mohl nejak zasahnout do chovani TCP/IP v PC musel by v podstate implementovat vlastni TCP/IP protokol - a to si troufam tvrdit zadny downloader nedela.

Cili omezovani rychlosti spojeni se projevuje stejne negativne jak v tom browseru tak v downloaderu. Jediny rozdil je ten, ze pokud se v downloaderu stahuje najednou vic souboru (vice soubeznych TCP spojeni), pak celkova rychlost prenosu bude vyssi. Jednotliva spojeni samozrejme diky ztratam packetu pojedou pomaleji (stejne jako v prohlizeci).

Browser vetsinou navaze jen jedno TCP spojeni (nebo nekolik malo) na jeden WWW server a tim spojenim prenese vsechny objekty na strance (at vlastni stranku ci obrazky atd). Pokud toto spojeni nejede plynule (ztray packetu zpusobene napriklad nesetrnym omezenim rychlosti) pak samozrejme cela stranka bude nacitana dlouho.
Paradoxne - starsi prohlizece, ktere neumi HTTP 1.1 a neumi ani persistent connections rozsireni k HTTP 1.0 mohou mit vyhodu. Stahuji kazdy objekt novym spojenim a soubezne se tenkrat tusim pracovalo typicky se 4 spojenimi na server (slo nastavit)

Kdyby chtel Telekom opravdu omezovat rychlost kazdeho jednotliveho TCP spojeni, musel by mit pomerne sofistikovane zarizeni, ktere by bylo schopne v packetech odlisit nejen packety daneho uzivatele (IP adresa) ale i packety patrici do ruznych spojeni. Ne ze by to neslo udelat, ale je to naprosto zbytecne a hardwarove (cenove) mnohem narocnejsi.

Je mozne, ze limit rychlosti provadi Telekom tak jak popisoval p. Peterka - CAR na ciscu a vysledkem je to, ze packet, ktery je prez limit se proste zahodi coz zpusobi uvadene problemy (degradace rychlosti TCP spojeni hluboko pod prah nastavenou omezovacem).
Jedine co mi do toho nesedi je prodlouzeny ping - to je typicka vlastnost shapingu, kdy se packety nejprve zarazuji do fronty aby doslo k jejich zpomaleni na pozadovanou rychlost a teprve pak zahazuji (kdyz je fronta plna). CAR zadnou frontu nema a nemel by tedy zpomalovat packety.

Souhlas s Vami, jen na doplneni, neda se moc presne urcit, kdy se paket zahodi, v CARu se nastavuji parametry jako
commited rate,burst size a extended burst, pak do hry
vstupuje takovy ten kyblik a zavisi na velikosti paketu, jak rychle jdou za sebou a jaky jsou ty paramatry, az se kyblik naplni, zacne se zahazovat, neco je na http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_chapter09186a00800c60d1.html
, takze nastavovat to, je v podstate ducharina

to zpozdeni muze byt mit ruzny priciny, treba je neco pred nebo za tim CARem, co to jeste nekde "hazi" do fronty, mozna se to jeste mezi sebou kombinuje

To je řečené dost zmateně, TCP stack je požádán aplikací o vytvoření TCP/IP spojení a rozhodně víc vláken nevytváří, ta 4 vlákna je standardní omezení prohlížeče (aplikace) pro protokol HTTP.

Před lety, když jsme ještě měli sdílenou 64 kbps linku, jsem dost experimentoval s různými nastaveními, ale žádné zázraky se s tím udělat nedaly. Jenom můžu potvrdit, že i malý packet loss způsobuje velké zpomalení TCP spojení, hluboko pod fyzické možnosti linky i celé trasy.

No to je tim, ze flow window se celkem dobre vyrovna s opozdenym ACK - a dle toho uprvi rychlost, ale DROP packetu zpusobi zaplneni flow window a WAIT az do okamziku, kdy se probere budik a je pozadano o preneseni celeho bloku ZNOVU - extremni pripad je ten, kdy je DROPnuty prave ten packet s ACK...

Takze TCP je fakt hodne nachylne na kvalitu na sitove vrstve, zpomaleni z duvodu chyb na linkove ci fyzicke mu nevadi skoro vubec... - a o tom je dnesni problem s CAR, tak jak jsem ho pochopil...

Presne tak. Osobne pouzivam HTB (Linux router) a chova se to velmi prijemne, k zahazovani paketu dochazi az pri extremnim zatizeni, takze prevazna vetsina paketu nad sdilenou kapacitu je jen zpozdena, scimz si TCP poradi celkem bez problemu.

Zjednodušeně řečeno, tím že jeden file stahuji více thready, stane se tok v rámci jednoho TCP streamu tak pomalým, že přestane fungovat "fair use" regulační mechanismus zabudovaný v TCP, tok totiž začně mít spíš charakter UDP přenosu izolovaných datagramů. Je to podobné jako když někdo v dopravní zácpě přestane dodržovat dopravní předpisy: také získá výhodu na úkor těch, kteří je dodržují.

Proboha, kdybyste radsi drzel usta kdyz technice nerozumite...

Muzete mi vysvetlit pojmoslovi "vice threadu v ramci JEDNOHO TCP streamu"?

Dekuji predem...

Neumíte číst? Já Vás to učit nebudu...

Zajímavé, ale ještě to neříká, jestli se při zahazování paketů se rozhoduje také podle klienta (IPadresy) či něčeho jiného, nebo je to jen náhodné? Podle mě je to náhodné a přiškrcuje to celkový tok bez nějaké analýzy...a to vysvětluje, proč si lze ukousnout větší rychlost při více vláknech stahování.

A ještě jedna věc: proč některé přípojky agregace nezasáhla? Mám 192/64 a pořád mi to jede na 155-174k podle toho čím měřím, ping 18 ms....