Vlákno názorů k článku Asymmetric Wireless -- výrazný propad cen bezdrátů od TommyCZ - Rozhodne ale neplati nesmysl: "Synchronní, kdy se informace...

Rozhodne ale neplati nesmysl: "Synchronní, kdy se informace přenášejí po jednotlivých bitech".

Reagoval jsem na tvrzení z původního příspěvku:

"No zapominate jeste na jednu vec 64po bezdratu je mnohem rychlejsi nez synchronni 64.
Prenosove medium funguje vetsinou na 2mbps takze se k vam paket dostane rychleji nez po synchronni lince.
A potom to mate jeste ovlivneno traffic shapingem ktery zareaguje az po te co dostanete nekolik paketu takze. webovska stranka se vam stahne mnohem rychleji. Prostě je bezdrát z pohledu uživatele WWW mnohem rychlejší.

Jak jsem ukázal na prakticky změřených hodnotách, alespoň u BreezeAccessu to není pravda.

OK, ale v tom případě mluvíme každý o něčem jiném :-)

Jenomže v tomto případě dává pathchar dost dobré výsledky, takže je z toho vidět, že metody nastavení maximální přenosové rychlosti budou asi o něco lepší než klasický shaping. Při klasickém shapingu se pakety pouštějí plnou rychlostí, ale jen občas, zatímco alespoň u tohoto BreezeAccessu se skutečně snižuje bitová rychlost, a i osamocený paket prochází pomaleji.

Aby to bylo jasnější, uvádím jednoduchý změřený příklad:

Min RTT na přístupový bod při paketu 84 byte: 6,051 ms
Min RTT na koncový bod při paketu 84 byte: 17,569 ms
Min RTT na přístupový bod při paketu 1084 byte: 20,735 ms
Min RTT na koncový bod při paketu 1084 byte: 80,376 ms

Tedy zvětšení paketu o 1000 byte má za následek zpoždění průchodu 48,123 ms tam a zpět, tedy 24,0615 ms jedním směrem. Z toho lze snadno vypočítat, jakou rychlostí se ten paket přenáší, a to (8 * 1000)/24,0615 = 333 kbps. A ne 3 Mbps.

Docela dobře to souhlasí s deklarovanou rychlostí 384 kbps.

pathchar neposkytuje žádnou záruku, že získané informace budou přesné, obzvlášť na shapovaných linkách. Tvrdí to sami autoři programu a uvádějí i důvody.

Odezva na mnohem rychlejší asynchronní lince bude samozřejmě lepší než na pomalé synchronní. Stačí si spočítat, jak dlouho trvá přenos jednoho takového paketu.

Nejsem si jist, jestli skutečně nějaký paket proběhne rychleji. Zkoušel jsem na lince Tele2 (BreezeAccess XL 3.5GHZ, omezeno na 384 kbps) pathchar, který pracuje na principu prodloužení RTT pingu s velikostí paktetu, a vycházela přesně rychlost 384 kbit/s, tedy treba paket 1500 byte skutecne prochazel rychlosti 384 kbit/s, a ne maximalni fyzickou rychlosti, jakou je mozne na teto bezdratove lince dosahnout (az 3 Mbit/s).
Navíc je to oproti standardní synchronní lince half duplex, takže se mi nezdá, že by mohla být rychlejší odezva.

Ale jo, upozornuje, ale ne ze by se to v praxi moc pouzivalo..

Asi mate pravdu vzhleem k tomu ze nedelam v Telco firmne tak takoveto problemy moc neresim. Nicmene ICMP source quench zase uporoznuje komunikujici strany ze maji spomalit.

kratkodobe to muze jet rychleji, ale dlouhodobe to stejne poklesne na prislusnou rychlost..

Přesně to jsem měl na mysli, když jsem tvrdil, že třeba při stahování webových stránek, které je nárazového charakteru se ta linka může jevit rychlejší. Nic víc.

Myslim, ze vetsinu techto veci jsem cetl.

No, ono je to je trosku slozitejsi.. Existuji ruzne algoritmy frontovani a zahazovani, je okolo toho spousta teorie atd.. Doporucuju paper Sally Floydove a Van Jacobsona Link Sharing and Resource Management Strategies for Packet Networks, neco se da take vycist z Linux Advanced Routing and Traffic Control HOWTO..
Jinak ICMP Source Quench, ktere asi mate na mysli, neni to, co dela ten shaping, ten dela to zahozeni paketu..

Hm, a jakou rychlost mas nasmlouvanou? Rychlost jednoho paketu? Rychlost danou tim jak velky soubor stahnes za 5 minut? Tvuj priklad s pulpaketem bych fakt nevidel jako problem, proste se zahodi kazdy druhy, misto toho aby se zahodila z kazdych dvou paketu pulka. :-)

Taky moc nechapu ze 64 kbps na bezdratu se shapingem ma byt jinak rychle nez na 64 kbps lince. Pokud je ten shaping udelany spravne, oboji bude 64 kbps. Pokud bude mit ten shaping bursty, kratkodobe to muze jet rychleji, ale dlouhodobe to stejne poklesne na prislusnou rychlost.. Spis zalezi na tom, jak je ten shaping udelany, jake je tam frontovani, jake jsou charakteristiky te linky samotne. .

Nevím, to prostě záleží případ od případu, třeba na implementaci TCP/IP stacku na koncových počítačích. Pak taky na nastavení burstu atd.

Ale řekl bych, že traffic-shapovaný bezdrát bude přece jenom rychlejší než neshapovaná linka stejné rychlosti. Asi ne při větších přenosech, ale třeba při takovém stahování webových stránek to může být poznat.

Ale to je jenom takové teoretizování, jinak než experimentem se to zjistit nedá.

Jasne Davide,
zkus nam rict, jakou efektivni spickovou a prumernou rychlost dosahne clovek na 2Mb/s synchronni lince (zanedbej vliv IP hlavicek) s traffic shapingem na 64 Kb/s. At vime, o cem se bavime.

A proto nemůžu dosáhnout přesně té rychlosti, jakou mám nasmlouvanou...

Ano, bursty funguji, ale pakety na pulky delit nemusis: vyhodnocuje se to za delsi dobu..

Idealni stav by byl kdyby ho Shaper pozdrzel.(vlozil do fronty )

Jenze ten v tom pripade by vas filtr musel fungovat tak ze dalsi paket posle dalsi paket az po pevne danem casovem useku ktery by byl dan velikosti pedchoziho paketu. (a tak to nefunguje) traffic shapery prumnerujou podle nekolika oslednich paketu a az potom dochazi ke snizeni rychlosti. Ktereho docilujou tak ze odelilateli posilaji ICMP paket s informaci o tom ze dana linka je pretizena aby snizil rychlost a paket primo zahazuji.

co já vím, tak cisco u svých traffic shapingů definuje něco jako burst a většinou se nastavuje o něco vyšší než je rychlost linky, protože jinak by ta linka požadované rychlost i nikdy nedosáhla.

Co udelas s paketem, ktery mas poslat, ale trafic shaping ti muze aktualne poslat jenom polovinu? Zahodis ho nebo pustis. Obe moznosti jsou blbe, ale zahodit je ta horsi.

Router reaguje s urcitym zpozdenim? Pokud je mi znamo, tak vsechny krabice, ktere implemetuji nektery traffic shaping, funguji na tom principu, ze vsechny IP pakety musi projit nejakym SW filtrem, ktery pracuje real-time nikoliv se zpozdenim.

Napada me sice jedna moznost, kdy by Vas navrh mel nejakou sanci na zivot a tim je velky nepomer mezi omezenou kapacitou a velikosti paketu. Ale v praxi to vidim jako velmi problematickou tezi.

No to je vec nazoru v urcitejch pripadech butete it pravdu vy v nekterejch zase ja. na 64 muze klient dosahnout spiskove mhorem rychlejsich prenosovych rychlosti. Protoze rychlost neni omezena prenosovym mediem ale az na routeru kterej reaguje s urcitym spozdenim. A to uzivatel uz ma stazenou stranku kterou pozadoval .

Martine dle meho je tomu naopak. Rychlejsi L2 je po SDHcku.

No zapominate jeste na jednu vec 64po bezdratu je mnohem rychlejsi nez synchronni 64.
Prenosove medium funguje vetsinou na 2mbps takze se k vam paket dostane rychleji nez po synchronni lince.
A potom to mate jeste ovlivneno traffic shapingem ktery zareaguje az po te co dostanete nekolik paketu takze. webovska stranka se vam stahne mnohem rychleji. Prostě je bezdrát z pohledu uživatele WWW mnohem rychlejší.

Prestavam cist lupu , ona uz neni odborna a o internetu ale spise to bude reklamni agentura , ktere slouzi vybranym firmam . To ze je tu i spousta levnejsiho internetu je preci jasne ... Ja internet za levny povazuju a myslim ze merena linka za patnact stovek musi stacit kazdemu domacimu uzivateli. Nevim proc se tu dava tolik durazu tematu "Internet zadarmo"

Celý problém je v tom, že se to v praxi hodně míchá s těmito pojmy (tj. zaměňuje se asynchronní a half duplex). Ten třetí odstavec je myšlen tak, že asynchronní přenos se používá tak, že se nejdříve vykecá jedna strana a pak dá prostor druhé. Klasické CB, schéma příjem, přepínám. Synchroní propojení (například fónický provoz) už umožňuje přenos v obou směrech (tj. používají se dvě trasy) které kvůli zachování posloupnosti informací se vzájemně synchronizují (protože by za chvilku došlo k takovým rozdílům ve vysílaných a přijímaných datech, že by vyšší vrstvy nestíhaly opravovat) - tzv. kvantování informace. Jelikož synchronní spojení - aby mělo smysl (pak by se musel superponovat na synchronní spojení asynchronní přenos) - je realizováno ve dvou směrech, jsou tato zařízení principielně dražší (potřebují zdvojené obvody).
Simplex, half dupex a duplex pak označují způsob komunikace na těchto propojeních, přičemž duplex (nebo zdůrazněně Full Duplex) je možný pouze na synchronním spojení z výše uvedeného důvodu.
A protože komunikace na fyzické vrstvě u WLL je asynchronní, tak nelze dosáhnout (full) duplexního přenosu dat, jak zde již bylo zmíněno.
Jiná věc, že se to uživateli tváří, že odesílá a přijímá data zároveň, že pak jsou někteří obchodníci schopni toto připojení srovnávat s připojením pevnou linkou (kde full duplex je), tj. prodávají poloviční kapacitu.
Možná by mohla Lupa provést srovnávací měření propustnosti, aby to bylo jasné i v číslech, co je half a co full. Pak by si možná někteří uvědomili, že přes pevnou linku o stejné rychlosti mohou přenést mnohem více dat (a proto také více stojí)

Je to uz delsi dobu co jsem studoval:-) a mohu se plest, ale stejne tomu moc nerozumim.
Vezmeme to poporadku:
S prvnim odstavcem souhlas, tam nemam problem.
Druhy odstavec take.
Tretimu odstavci zase nerozumim. Moje pripominka - "...aby na dvou asynchronních linkách bylo možno přenášet data současně, proto se při asynchronním režimu používá Half Duplex." - proc na dvou? To jako ze jednu pouziji na jeden smer a druhou na druhy? To je ale prece pak z pohledu te linky SIMPLEX!? S tim prikladem fakt nevim, nejsem na to odbornik, proste ji jen prijde, ze synchronni/asynchronni je jedna charakteristika a simplex/duplex je druha charakteristika. Kdyz tu Vasi otazku/tvrzeni otocim, tak zrejme neni problem vyrobit zarizeni synchronni a simplexove, pripadne duplexove....:-)?

Ne, pri synchronnim prenosu opravdu nemusi byt prenasen zadny synchronizacni signal ...

To snad nemyslite vazne ? Prenos informace po jednotlivych bitech -> SERIOVY. Synchronni prenos znamena, ze soucasne s daty je prenasen i synchronizacni signal.

Nevite, o cem mluvite. Asynchronni nerovna se half duplex !

SIMPLEX - přenos v jednom směru
HALF DUPLEX - přenos v obou směrech, ale ne současně
DUPLEX - v obou směrech najednou

Synchronní, kdy se informace přenášejí po jednotlivých bitech. Okamžiky přechodu od přenosu jednoho přenášeného bitu k přenosu dalšího bitu jsou vždy stejně vzdáleny.
Asynchronní, kdy okamžiky přechodu od přenosu jednoho bitu k přenosu dalšího bitu nejsou stejně vzdáleny. Zvláštním případem asynchronního přenosu dat je tzv. arytmický přenos. U arytmického přenosu je přenos znaků asynchronní, ale jednotlivé bity v přenášeném znaku se přenáší synchronně. Pokud se hovoří o asynchronním přenosu, pak se má většinou na mysli asynchronní arytmický přenos.

V praxi je složité udělat zařízení tak, aby na dvou asynchronních linkách bylo možno přenášet data současně, proto se při asynchronním režimu používá Half Duplex.
Jestli znáte nějaké zařízení s asynchronním přenosem a full duplexem, tak mně poučte.

Priznam se, ze tady poprve slysim, ze asynchronni znamena half duplex a synchronni full duplex. Z dob svych studii jsem nabyl nazoru, ze jde o dve odlisne veci a vzajemnou zavislost jsem tedy opravdu, ale opravdu necekal. Jste si tim opravdu jist? Prijde mi totiz, ze neni problem udelat napr. full duplex komunikaci na asynchronnim spojeni:-)

Malinko si totiž plete pojmy a plete pátý přes devátý - asymetrickou linku s asynchronní a full duplex/half duplex. Ještě nikdy sem neviděl totiž full duplexní BreezeNet...! Rozdíl mezi asymetrickou linkou linkou a half duplexem je totiž v tom, že asymetrická linka má rozdíl v kapacitě downloadu a uploadu, kdeždo asynchronní (half duplex)umí v jednotce času posílat data jen jedním směrem (buď mluvím já, nebo druhá strana, ale ne obě najednou). Z toho pak vyplívá že symetrická linka má stejnou kapacitu download a upload a synchronní linka (digitální full duplex) zase umí posílat data současně oběma směrama. Myslim si, že než autor začne psát takovejdle článek a pokouší se vysmívat operátorům, který asymetrický připojení nenabízej z logickýho důvodu (kapacita AP totiž musí bejt spočítaná na ty vyšší hodnoty) zajde na nějakej malej kurz o telekomunikacích, aby neplácal nesmylsly.
Čagos,
Chorche