1st aerial - AirBQ 9GHz

[sub_zero]

Zdravím.. Potřebuju pomoc od uživatelů našich spojů při odhalování Bugu v Mikrotiku.

a nejedna se jen o stary znamy problem - maximalni rychlost TCP (s beznou velikosti okna) versus latence po trase? Cili to, co trapi kazdeho s NV2, diky latencim NV2jky?

nás to třeba trápí i na eth, optice, atd.

[hapi]

jo, protože tohle latenční klišé se budou lidi držet vždy. Akorát jim nedojde že to okno se samo zvětší aby se zvýšila rychlost a tím že se zvětší dojde k něčemu na co moc lidí nepřijde a to k většímu plnění bufferů na trase. Pokud tam pak teče tisícovky takových spojení tak je průůůser pokud tam máte nějaký shit zařízení. Ovšem najít to shit zařízení neni prdel protože to může bejt i racková záležitost která je shit a desktop věc to přitom zvládne.

A ano, bude to dělat problémy i na eth a optice. Ono totiž každá věc je určená na jistý místo. Dám příklad: rackovej tplink 16Gbit portů. Ten jsme musely od hlavního routeru vyhodit. Proč? protože je určenej na konec trasy a tedy k zákazníkovy kde na portech sedí samotný počítače a takovou haldu datového toku nikdy na ráz nevytvoří ovšem u hlavní gw to je každý večer protože přes něj nejde 24 počítačů tak jako v nějakym kanclu ale 240 nebo 2400 počítačů. To je sakra rozdíl. Tady nejde jenom o rychlost, tady je o daleko víc věcí kterou tu rychlost ovlivní.

[Insider]

Zdravím.. Potřebuju pomoc od uživatelů našich spojů při odhalování Bugu v Mikrotiku.

a nejedna se jen o stary znamy problem - maximalni rychlost TCP (s beznou velikosti okna) versus latence po trase? Cili to, co trapi kazdeho s NV2, diky latencim NV2jky?

Nemyslím, projevovalo by se to všude..

[Insider]

jo, protože tohle latenční klišé se budou lidi držet vždy. Akorát jim nedojde že to okno se samo zvětší aby se zvýšila rychlost a tím že se zvětší dojde k něčemu na co moc lidí nepřijde a to k většímu plnění bufferů na trase. Pokud tam pak teče tisícovky takových spojení tak je průůůser pokud tam máte nějaký shit zařízení. Ovšem najít to shit zařízení neni prdel protože to může bejt i racková záležitost která je shit a desktop věc to přitom zvládne.

A ano, bude to dělat problémy i na eth a optice. Ono totiž každá věc je určená na jistý místo. Dám příklad: rackovej tplink 16Gbit portů. Ten jsme musely od hlavního routeru vyhodit. Proč? protože je určenej na konec trasy a tedy k zákazníkovy kde na portech sedí samotný počítače a takovou haldu datového toku nikdy na ráz nevytvoří ovšem u hlavní gw to je každý večer protože přes něj nejde 24 počítačů tak jako v nějakym kanclu ale 240 nebo 2400 počítačů. To je sakra rozdíl. Tady nejde jenom o rychlost, tady je o daleko víc věcí kterou tu rychlost ovlivní.

Ten pocit z toho mám taky, že se to láme někde na adapterech, které zahazují část trafiku, protože jim přetejkaj buffery.

[Dalibor Toman]

jo, protože tohle latenční klišé se budou lidi držet vždy. Akorát jim nedojde že to okno se samo zvětší aby se zvýšila rychlost a tím že se zvětší dojde k něčemu na co moc lidí nepřijde a to k většímu plnění bufferů na trase. Pokud tam pak teče tisícovky takových spojení tak je průůůser pokud tam máte nějaký shit zařízení. Ovšem najít to shit zařízení neni prdel protože to může bejt i racková záležitost která je shit a desktop věc to přitom zvládne.

A ano, bude to dělat problémy i na eth a optice. Ono totiž každá věc je určená na jistý místo. Dám příklad: rackovej tplink 16Gbit portů. Ten jsme musely od hlavního routeru vyhodit. Proč? protože je určenej na konec trasy a tedy k zákazníkovy kde na portech sedí samotný počítače a takovou haldu datového toku nikdy na ráz nevytvoří ovšem u hlavní gw to je každý večer protože přes něj nejde 24 počítačů tak jako v nějakym kanclu ale 240 nebo 2400 počítačů. To je sakra rozdíl. Tady nejde jenom o rychlost, tady je o daleko víc věcí kterou tu rychlost ovlivní.

no ono by stacilo, kdyby kazde zarizeni melo poctivy counter packetu dropnutych prave kvuli nedostatku mista ve fronte na odchozim interfacu dostupny po SNMP. Pak by se snadno videlo, kde je po trase problem a ktere zarizeni umi hospodarit s pameti pro buffery.

A dulezity je pomer linkove rychlosti uplink/downlink. Pokud mas ve switchi vsechno nabehle na 1gbps pak pravdepodobne i mizerne zelezo nebude mit problem protoze se tech packetu rychle zbavi (pokud nebude vice portu slouzit jako uplink). Dobry priklad potencialniho problemu jsou porty k radiove trase, ktera ma obvykle mensi rychlost nez ten 1gbps na kterych bezi shaping ci flowcontrol. A pokud na takovem portu nekdo pousti data bez brzdeni rovnou do radia, pak spoleha na frontu radia ...

[sub_zero]

jo, protože tohle latenční klišé se budou lidi držet vždy. Akorát jim nedojde že to okno se samo zvětší aby se zvýšila rychlost a tím že se zvětší dojde k něčemu na co moc lidí nepřijde a to k většímu plnění bufferů na trase. Pokud tam pak teče tisícovky takových spojení tak je průůůser pokud tam máte nějaký shit zařízení. Ovšem najít to shit zařízení neni prdel protože to může bejt i racková záležitost která je shit a desktop věc to přitom zvládne.

A ano, bude to dělat problémy i na eth a optice. Ono totiž každá věc je určená na jistý místo. Dám příklad: rackovej tplink 16Gbit portů. Ten jsme musely od hlavního routeru vyhodit. Proč? protože je určenej na konec trasy a tedy k zákazníkovy kde na portech sedí samotný počítače a takovou haldu datového toku nikdy na ráz nevytvoří ovšem u hlavní gw to je každý večer protože přes něj nejde 24 počítačů tak jako v nějakym kanclu ale 240 nebo 2400 počítačů. To je sakra rozdíl. Tady nejde jenom o rychlost, tady je o daleko víc věcí kterou tu rychlost ovlivní.

Stando, pár věcí:

-TP linky nikde na backbone nepoužíváme
-pokud odbavuješ toky 300mbps a víc máš na to odpovídající krabice
- používáme SuperMicro desky, SuperMicro popř. Intel PCIex karty
- tam kde není v cestě Mikrotik a je tam třeba Juniper, problém není
- pokud se zapojím přímo do core našeho upstream providera, problém nemám
-tipuju to na karty

[hapi]

jo, protože tohle latenční klišé se budou lidi držet vždy. Akorát jim nedojde že to okno se samo zvětší aby se zvýšila rychlost a tím že se zvětší dojde k něčemu na co moc lidí nepřijde a to k většímu plnění bufferů na trase. Pokud tam pak teče tisícovky takových spojení tak je průůůser pokud tam máte nějaký shit zařízení. Ovšem najít to shit zařízení neni prdel protože to může bejt i racková záležitost která je shit a desktop věc to přitom zvládne.

A ano, bude to dělat problémy i na eth a optice. Ono totiž každá věc je určená na jistý místo. Dám příklad: rackovej tplink 16Gbit portů. Ten jsme musely od hlavního routeru vyhodit. Proč? protože je určenej na konec trasy a tedy k zákazníkovy kde na portech sedí samotný počítače a takovou haldu datového toku nikdy na ráz nevytvoří ovšem u hlavní gw to je každý večer protože přes něj nejde 24 počítačů tak jako v nějakym kanclu ale 240 nebo 2400 počítačů. To je sakra rozdíl. Tady nejde jenom o rychlost, tady je o daleko víc věcí kterou tu rychlost ovlivní.

no ono by stacilo, kdyby kazde zarizeni melo poctivy counter packetu dropnutych prave kvuli nedostatku mista ve fronte na odchozim interfacu dostupny po SNMP. Pak by se snadno videlo, kde je po trase problem a ktere zarizeni umi hospodarit s pameti pro buffery.

A dulezity je pomer linkove rychlosti uplink/downlink. Pokud mas ve switchi vsechno nabehle na 1gbps pak pravdepodobne i mizerne zelezo nebude mit problem protoze se tech packetu rychle zbavi (pokud nebude vice portu slouzit jako uplink). Dobry priklad potencialniho problemu jsou porty k radiove trase, ktera ma obvykle mensi rychlost nez ten 1gbps na kterych bezi shaping ci flowcontrol. A pokud na takovem portu nekdo pousti data bez brzdeni rovnou do radia, pak spoleha na frontu radia ...

no ano, ono stačí i když to do radia dostaneš na gigu ale radio má licenci jenom na 200Mbit. V ceragonu na to technici pak přišli, někde tam ten counter je.

[hapi]

jo, protože tohle latenční klišé se budou lidi držet vždy. Akorát jim nedojde že to okno se samo zvětší aby se zvýšila rychlost a tím že se zvětší dojde k něčemu na co moc lidí nepřijde a to k většímu plnění bufferů na trase. Pokud tam pak teče tisícovky takových spojení tak je průůůser pokud tam máte nějaký shit zařízení. Ovšem najít to shit zařízení neni prdel protože to může bejt i racková záležitost která je shit a desktop věc to přitom zvládne.

A ano, bude to dělat problémy i na eth a optice. Ono totiž každá věc je určená na jistý místo. Dám příklad: rackovej tplink 16Gbit portů. Ten jsme musely od hlavního routeru vyhodit. Proč? protože je určenej na konec trasy a tedy k zákazníkovy kde na portech sedí samotný počítače a takovou haldu datového toku nikdy na ráz nevytvoří ovšem u hlavní gw to je každý večer protože přes něj nejde 24 počítačů tak jako v nějakym kanclu ale 240 nebo 2400 počítačů. To je sakra rozdíl. Tady nejde jenom o rychlost, tady je o daleko víc věcí kterou tu rychlost ovlivní.

Stando, pár věcí:

-TP linky nikde na backbone nepoužíváme
-pokud odbavuješ toky 300mbps a víc máš na to odpovídající krabice
- používáme SuperMicro desky, SuperMicro popř. Intel PCIex karty
- tam kde není v cestě Mikrotik a je tam třeba Juniper, problém není
- pokud se zapojím přímo do core našeho upstream providera, problém nemám
-tipuju to na karty

já vim, to byl jenom příklad. Asi bych se ve vašem případě zaměřil na ty routery a použil ethernety s více hw frontami. Viděl sem několik silných routerů na mikrotiku kdy je odrovnalo 200kpps na chipu i82574 (1TX,1RX HW queue). Většinou jsem jim doporučil osadit do slotu tu novou dual/quad kartu od supermicra postavenou na chipu i350 (tušim 4TX, 4RX HW queue) a rázem router zase fičí bez špiček na jednom jádře. A samozřejmě minimálně MKv6.1

Každopádně nej je vzít trasu a vždy měřit z prvku na nejbližší prvek nebo ob prvek a vnášet si výsledky do mapy a pak to nějak vyhodnotit kde se to ztrácí. Jak to nevidíš vizuálně tak to nemá smysl

[sub_zero]

to je tahle? http://www.abacus.cz/supermicro-sgp-i2- ... 46399.html

[Insider]

jo, protože tohle latenční klišé se budou lidi držet vždy. Akorát jim nedojde že to okno se samo zvětší aby se zvýšila rychlost a tím že se zvětší dojde k něčemu na co moc lidí nepřijde a to k většímu plnění bufferů na trase. Pokud tam pak teče tisícovky takových spojení tak je průůůser pokud tam máte nějaký shit zařízení. Ovšem najít to shit zařízení neni prdel protože to může bejt i racková záležitost která je shit a desktop věc to přitom zvládne.

A ano, bude to dělat problémy i na eth a optice. Ono totiž každá věc je určená na jistý místo. Dám příklad: rackovej tplink 16Gbit portů. Ten jsme musely od hlavního routeru vyhodit. Proč? protože je určenej na konec trasy a tedy k zákazníkovy kde na portech sedí samotný počítače a takovou haldu datového toku nikdy na ráz nevytvoří ovšem u hlavní gw to je každý večer protože přes něj nejde 24 počítačů tak jako v nějakym kanclu ale 240 nebo 2400 počítačů. To je sakra rozdíl. Tady nejde jenom o rychlost, tady je o daleko víc věcí kterou tu rychlost ovlivní.

no ono by stacilo, kdyby kazde zarizeni melo poctivy counter packetu dropnutych prave kvuli nedostatku mista ve fronte na odchozim interfacu dostupny po SNMP. Pak by se snadno videlo, kde je po trase problem a ktere zarizeni umi hospodarit s pameti pro buffery.

A dulezity je pomer linkove rychlosti uplink/downlink. Pokud mas ve switchi vsechno nabehle na 1gbps pak pravdepodobne i mizerne zelezo nebude mit problem protoze se tech packetu rychle zbavi (pokud nebude vice portu slouzit jako uplink). Dobry priklad potencialniho problemu jsou porty k radiove trase, ktera ma obvykle mensi rychlost nez ten 1gbps na kterych bezi shaping ci flowcontrol. A pokud na takovem portu nekdo pousti data bez brzdeni rovnou do radia, pak spoleha na frontu radia ...

1+
Taky to tak vidim.. V každým řípadě MT flow COntrol nemá a nepodporuje.

[hapi]

jo, protože tohle latenční klišé se budou lidi držet vždy. Akorát jim nedojde že to okno se samo zvětší aby se zvýšila rychlost a tím že se zvětší dojde k něčemu na co moc lidí nepřijde a to k většímu plnění bufferů na trase. Pokud tam pak teče tisícovky takových spojení tak je průůůser pokud tam máte nějaký shit zařízení. Ovšem najít to shit zařízení neni prdel protože to může bejt i racková záležitost která je shit a desktop věc to přitom zvládne.

A ano, bude to dělat problémy i na eth a optice. Ono totiž každá věc je určená na jistý místo. Dám příklad: rackovej tplink 16Gbit portů. Ten jsme musely od hlavního routeru vyhodit. Proč? protože je určenej na konec trasy a tedy k zákazníkovy kde na portech sedí samotný počítače a takovou haldu datového toku nikdy na ráz nevytvoří ovšem u hlavní gw to je každý večer protože přes něj nejde 24 počítačů tak jako v nějakym kanclu ale 240 nebo 2400 počítačů. To je sakra rozdíl. Tady nejde jenom o rychlost, tady je o daleko víc věcí kterou tu rychlost ovlivní.

Ten pocit z toho mám taky, že se to láme někde na adapterech, které zahazují část trafiku, protože jim přetejkaj buffery.

ono je dost možný že se přijde na to, že ty ethernety v atheros chipech nebudou dostačovat navíc se všude defaultně zapiná only hardware queue... nevim jestli je to zrovna šťasný řešení a nevim jestli se tam ještě řeší nějaký jiný bufferování atd.. alem ožný je defakto cokoliv.

[hapi]

to je tahle? http://www.abacus.cz/supermicro-sgp-i2- ... 46399.html

jo to je ona, pozor na low profile a myslim že i nutnost mít v6 na routeru. Nevim jestli se s ní dodávaji oba plechy. Pokud máš quad core router tak je to best. Pokud máš i víc tak bych se pokouknul po 82599 kterou začlo mkčko podporovat, ta umí tušim až 16 RX front takže pro víc jak quad core mašinu určitě ještě víc best.

To jestli na routeru máš teď víc queue na ethernetu najdeš v /system resources irq a tam by měly být halda IRQ k jednomu ethernetu. nějak takhle:
zelená je tušim ta supermicro co si poslal a ta červená je nějakej broadcom.

[sub_zero]

Dikec.
Ted nemam na iGW stejne v6, a je to stara deska, takze objednam tu Quadku.

[hapi]

quadku?

[sub_zero]

quadku?

4portovku