Test a analýza hraničních routerů

[hapi]

no vem si že když z nějakýho stroje pingáš, tak je to pro něj náročnější než když má na icmp pouze odpovídat. U těhle pomalích cpůček je to ještě znatelnější.

[ludvik]

My měli při 300M lince (a na strop si to sahalo dost často) běžný desktop intel board (myslím PEARL) a v tom Core2Duo okolo 2.4GHz. A rozhodně to nelossilo. Byl v tom čistý linux (verzi už nevím, okolo 2.6.20, ale distribučně jsem založený na Archlinuxu), NATka a shapper (HTB+SFQ) tenkrát pro nějakých jestli si dobře pamatuju 1200 až 1300 lidí.

Ale je fakt, že na trochu větší místa (což jsou všechny, kam nelze dát RB) už mi nesmí nic jiného, než opravdu serverová věc. Byť třeba entry-level AspenHill, Gross Point atp. Byl to spíš subjektivní dojem, než něco exaktně změřeného, ale chová se to prostě lépe i když to papírově vypadá úplně stejně. Je to poznat i na obyčejné práci v příkazové řádce. Desktopy jako kdyby měly občas problém s latencí na sběrnicích, či co.

Byť kdybych musel šetřit, tak se do těch 200-300Mbit desktopu nijak zvlášť nebojím (ale ne atom). Na podřadných routerech ovšem neNATkuju, ani neQOSuju. Ale conntrack používám. Firewally stavím na IPSETech, což srazí CPU na nulu ... Podobný případ je i shapper. Pokud se použije markování paketů, byť v optimalizovaném "stromečku", tak je to procesorově náročné (u nás tenkrát cca 40-60%). Ve chvíli, kdy jsem to přepsal na CLASSIFY target, vytížení skoro nebylo v htopu poznat (pozor, musí se sledovat i kernel časy).

Bohužel všechno souvisí tak nějak se vším. Pochybuju, že se dá udělat nějaký univerzální závěr. Ale také by mě zajímal.

[sub_zero]

prosím všechny, aby akceptovali případný chyby, pač Hapi pingá od nás obvykle v pátek mezi 2 a 4 ranní, když přijdu z chlastačky a začnu reonfigurovat

jo a pointa je jaká? zjistit, proč nepoužívat desktop board na hraničním routeru?

[hapi]

tak předně je pointa třeba taková, že jsem asi 3 lidem odhalil packet losty o kterých neměly ani potuchu. Ono se zdá že 0.1% packet lostu za 24 hodin je málo ale ono je to docela sem tam znát při serfování, sem tam se ztratí paket při stahování obrázku a stahování se na chvíly zasekne atd.. nebo třeba i ssh je na tom cítit, píšete do konzole a najednou typickej herní lag.

Cílem je ověřit jakej vliv má použitej HW a OS na datový přenosy.

Nicméně spousta lidí si koupí HW sestavu s tim, že výrobce na to napsal server ale uvnitř je desktop chipset... je to stále server? nebude to blbnout tak jako klasickej desktop? Typickej příklad k tomu je atom od supermicro. Intel ethernety, desktop chipset.

[sub_zero]

a tihle packetloosari maj ty desktopovy fosny?

[hapi]

a to se právě snažim zjistit ale zatim naprostá většina z nich ano. Jeden v nejbližších dnech vymění os a druhej hw. To by mohlo podat zajímavý výsledky. Já chápu že na server patří serverový věci a na desktop desktopový. Ale nikoho z vás nezajímalo co je na těch serverech jinýho? Nebo spíš, co když nekoupim skutečnej serverovej procesor nebo chipset. Jo výrobci tvrdí že to je serverová sestava ale komponenty jsou desktopový. Nebude to dělat PL? Už jenom fakt že se objevilo něco jako PL na 40Mbit datovýho toku je fascinující. Tim to mění všechny odpovědi co koupit na hlavní bránu když mám jenom 50Mbit. Odpověď neni nějakej dual stačí ale odpověď je ......?

[sub_zero]

..odpověď je Cisco ne, joke.. hele, my když skládali náš hraniční router, poptal sem u Klímy ideální konfiguraci. Tu jsem nakoupili, poskládali a už dva roky nám jede bez problémů. Znám taky případ, kdy někdo skládal novej router, navalil tam nejnovější fošnu od SM, redundantní zdroje a packetloss a natahování pingů měl jak z praku A to byl board za 12 prutů, na dvě CPUčka a zloušel x verzí Mikrotiku.
Zamyslel si se třeba nad tím, že i když jsou chipsety identický, že třeba Bios může bejt jinej? Nebo myslíš, že výrobci desek budou prodávat tu samou desku jen s přívlastkem "serverová" za 3x větší prachy jen tak? Že to bude úplně stejný? Že bude stejná součástková základna? Pořád hledáte viditelný a dohledatelný rozdíly, ale ony to můžou být ty vnitřní, který každej výrobce třeba střeží jako oko v hlavě.
Píšu to jako lajk na problematiku serverovejch fošen, ale když třeba fošna, která je deklarovaná jako serverová a má 7.1 kanálovej zvuk + HDMI + nonECC paměti..tak nevím, asi bych si ji nekoupil na takovej klíčovej uzel jako iGW. Ano, ono to třeba "nějak" pojede, ale jak si psal..

tak předně je pointa třeba taková, že jsem asi 3 lidem odhalil packet losty o kterých neměly ani potuchu.

[hapi]

jo tak jasně, já to chápu. Na druhou stranu jak píšeš, i super HW se prostě neschodne a nejede to pořádně. Zatim se v testu osvědčily starý dobrý chipsety serie i3000 na dneska už dost přestárlou LGA775. Tady je vidět že vůbec na ramkách přímo do cpu a vývody z cpu přímo do ethernetů na to vliv vůbec nemá. Tyhle cpučka do toho maji jednu zběrnici na všechno včetně paměťovýho subsystemu a aktuálně to je z dnešního podheldu směšná propustnost mezi cpu a chipsetem ale ukazujou že je bohatě dostatečná.

[dantasik]

U toho sm za 12klacku bych to videl ze si stim neporadi mikrotik...
Kterej zacina na nejakym jadru a uz ho moc neupdati.
Kdyz jsme koupili desku na gw na ktere jedem dotedka tak sem se taky pral s linux kernelem aby to vsecko nacetlo a tak + aby umel hazet irq na tx a rx u jednotlivych sitovek.

Ted se uvidi pri zmene OS...

[sub_zero]

tak... od včerejška jsem na Hapiho core router pingal..jak klasickej ping (12 pingu za minutu, nastaveno stejne jako jeho Smoke Ping), tak i flood ping (50 pingu) + jitter. n
V úvodním kecání Hapi píše, cituji:

Pokud se průtok přes hraniční router přiblíží k 50Mbit, router začne prostě a jednoduše vytvářet packet lost.

z čeho chápu, že se jedná o PL při průchodu routerem. Tak jak mi potom vysvětlíš PL přímo na WAN tvýho routeru? Nebo Mikrotik je taky takový Cisco, který lossuje na inputu ICMP, protože maj nejnižší prioritu? Tenhle PL myslím nemá nic společnýho s deskou..........ani s chipsetem......ani s CPU

hapi_WAN.jpg (81.6 KiB) Zobrazeno 2011 x

[hapi]

hmm, při forwardu cca 50Mbit, spíš by jsme to měly pasovat na průtoku cca 5000 paketů za sekundu router obecně na všechny strany začne dělat PL. No abych to ještě upřesnil, pokud by jsi z netu pingal na něco uvnit naší sítě, bude tam PL tak jako na ten router. Pokud ale budu pingat já z vnitřku sítě hned na nějakej router přímo za hlavnim routerem na kabelu, PL tam nebude. Proč? Já nevim. Jenom jsem si ověřil, že to nedělá jenom u mě ale u asi 5 dalších lidí. Dial se brání, že u nich to neni a já jim věřim protože na starý konektivitě u někoho jinýho to dělalo uplně to samí a navíc těch 5 dalších lídí to maji uplně totožný. Neumim si to vysvětlit a ani najít kde je problem. HW byl vyměněnej, ethernety jiný, chipset jinej, ramky jiný, verze rosu jiná, kabely jiný, zdroj jinej, usp jiná, jenom desktop zůstal.

Jestli máš jiný vysvětlení, sem s nim.

[sub_zero]

ne, já žádný vysvětlení nemám. Jen sem to sem dával z toho důvodu, že si psal: "při průchodu routerem..." A tohle není průchod routerem.
Pokud se na to zaměřím z čistě lajckýho pohledu, jednoznačně to na mě působí jako problém ještě před tím routerem, kterej ty vyvracíš a argumentuješ dalíma 5ti ISPky, u kterých se to chová stejně. Já si pingám na x zařízení Mikrotiku po celý republice a jsou to i posraný RB a ne x86 a ty PL tam nejsou. Chápu, že spousta mašin má na inputu icmp v qosu na nejnižsí prioritu, ale ne na takovou, aby to dělalo takovej PL.

[hapi]

no a teče jim tam 50Mbit? Pod tuto hranici tam skoro PL neni. Klidně ti ukážu když omezim síť na 50Mbit že tam nic nevypadne. Dám 60Mbit a je tam cca 0.2PL, dám 70Mbit a je tam 0.4PL atd..

jo tak při průchodu datovýho toku, tak to bylo myšlený. Co by router asi jinýho dělal. Prostě jak forwarduje cca 50Mbit, je tam PL obecně kamkoliv, skrz i na něj. Záleží na pps. Nicméně, čim dál seš, tim větší PL je. Lokální smokeping přes jeden switch ukazuje 0PL. Za router 0PL. Z netu na cokoliv už PL je. U ostatních 5 lidí to samí. Já nevim, nechápu to, snažim se na to přijít. Mám v testu jednoho, co má na hlavní GW linux, na něj žádnej PL. Hned za nim je desktopový MKčko co natuje a tam chybovost je a přitom to je pouze propojený switchem takže chybovost by tam bejt neměla nebo aspoň ne taková jakou tam má. Já pro tohle vysvětlení nemám nebo spíš nemůžu aktuálně říct "je to timhle".

MKčko by mělo na ICMP odpovídat bez problémů i když nějaký omezení na něco ve vnitřní konfiguraci mikrotiku bylo ale to bylo tušim řádově ve stovkách ICMP paketů za sekundu.

[Walkeer]

Ono se zdá že 0.1% packet lostu za 24 hodin je málo ale ono je to docela sem tam znát při serfování, sem tam se ztratí paket při stahování obrázku a stahování se na chvíly zasekne atd.. nebo třeba i ssh je na tom cítit, píšete do konzole a najednou typickej herní lag.

Myslim ze u TCP maly PL nevadi, rozhodne ne u nacitani obrazku, od toho je TCP reliable, aby si to retransmitlo znovu, takze jediny vysledek bude male zpomaleni. Daleko vetsi problem to je u UDP, tedy napr. DNS, VoIP a pod, problem je z me zkusenosti i u navazovani TCP, idkyz tam to bude zrejme take nejake resene.


Me by obecne zajimalo, jak se muze stat, ze na zeleze, kde neni CPU na 100%, vznikne PL. to by totiz znamenalo, ze
1) zpracovani toho ztracenho packetu trvalo tak dlouho, ze ho neco zahodilo nebo proste timeout, coz ale pri nizsim nez 100% vytizeni zrejme nehrozi
2) ten packet se proste nekde po ceste ztratil, coz je, pokud to dobre chapu, chyba budto SW, nebo HW (nepravdepodobne). Kazdopadne by to mela byt buga a ne vlasnost.

Me z toho vypliva, ze tvrzeni, ze desktop desky delaj PL a je to vlastne jejich vlasnost, nikoli zavada, je nesmysl. Pripada mi to podobne, jako kdyby desktop desky napr. zpusobovaly ztraty dat na disku. Pocitace nejsou analogova technika, ktera musi byt draha, aby fungovala dobre, od toho maj vsechny sbernice kontrolni kody, pripadne se pouziva SW kontrola chyb.

Je mi jasne, ze vase zkusenost je ponekud jina, ale vazne by me zajimalo, cim konkretne to je zpusobene.

[hapi]

no ano, tcp se opraví, ale ne hned a přeruší to stahování na nějakou dobu než vyprší nějakej timeout a pošle se znova. S tim souvisí windows size, dokud jedno windows size nedorazí, nepošle se další. Tedy dokud většinou nedorazí 16kB blok dat celej, tak se neposílá nic dalšího. Tim dojde k chvilkovýmu záseku. Doufám že to tak je. Jo UDP je pak v háji. Tam je jasná past.

no, kdyby to byla chyba SW, tak proč se neprojeví na serverových komponentech čili tohle vylučuju.

Jo taky by mě zajímalo čim je tahle kravina způsobená. Musim ještě prolíst datasheet k i3000 a třeba k P35 chipsetu jaký tam jsou rozdíly. Reálně totiž třeba mezi P45 a G31 nebyl žádný rozdíl v PL i když ty chipsety se zase tak moc od sebe neliší.

Já mám třeba teorii takovou, že na desktop věcech nejsou takový buffery u zběrnic, přerušení atd.. Když si vemu kolik přerušení vyvolá například 5000pps... takovej náhul přerušení neni ani když člověk hraje na PCčku hru. Normálně na PCčku většinou procesor něco vytváří z ničeho (něco počítá, komprimuje, atd) a externí podněty na přerušení moc nejsou ovšem ethernet s 5000pps průtokem vyvolá defakto 5000 externích IRQ za sekundu z jednoho ethernetu a to prostě u desktop používání nehrozí protože jediný co tam je, je řadič disku co vyvolá nějaký nášupy IRQ. Pak bych to prostě viděl na zátěž způsobenou IRQčkama kdy se je chipset snaží předat CPUčku ale nestíhá to tak dobře a pak prostě nestačí buffery a ethernet zahodí paket ale taky můžu kecat uplný kraviny a sem mimo mísu.