Majklik píše:Switch to může ovlivňovat prakticky velmi dobře, zvláště s dopadem na TCP. A zrovny tyto TPlinky s nevypnutelným a trvle zapnutým flow control jsou ideální příklad (802.3x). Ale je blbost, aby se tak dělo při tokách kolem pár desítek Mbps,jestli-že oba zapojene porty jsou na gigu (ke xeonu i rb711g).
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Zamyšlení - Více hopů na 5GHz
Re: Zamyšlení - Více hopů na 5GHz
Flow ano, ale neuvažoval jsem o něm vzhledem k rychlostem. Ale teď si vzpomínám, když si mi to připomenul, že jsem něco podobného řešil na Allied Telesyn (GS950 nebo tak nějak). Pause pakety chodily, i když neměly důvod.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
no ano, jistě, tam neteče ani 50Mbit na to aby se muselo začít něco dít. U brány máme tplink serie jetstream kterej to dál vede pryč k příhradě kde je/byl ten "poruchovej" switch. Odtud 100Mbit porty do RBček. Nemyslim si že by se vůbec muselo aktivovat flow control když jde o TCP při těhle rychlostech. Pokud teda ten switch nemá ultra malí buffery a neběží pro flow control každou chvilku. Žádný vlany tu neběhají, čistě přepínání běžnýho toku.
ta macovka je jako čí?
ale asi to řešit nebudu ale zapojit do cesty RB250GS můžu co to udělá ale až okolo 11 v noci.
Kód: Vybrat vše
Kbyby se Hapi moc nudil. Co se stane, když mezi ten TPlink a xeon strčíš tu RB250GS? Jde to blbě nebo dobře (signalizačně a elektricky jsi oddělil intel síťovku a tplinkl)? A co se stane, kdyř pak na tom 250GS zapneš MAC filtr, který nebude propouštět rámce s cílovou MAC 01:80:C2:00:00:01 (zablokuji doručování pauze rámců do xeonu)? Má to dopad?ta macovka je jako čí?
ale asi to řešit nebudu ale zapojit do cesty RB250GS můžu co to udělá ale až okolo 11 v noci.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
Teraz som sa vrátil od klienta Pripojený na airmax sektor uplink sektoru nv2 2x2 2ms a dalej dva skoky airmax 2x2 na rocketoch . UDP cez toto 60 Mbit 1 TCP 50 Mbit
switch až na jeden planet všetko cisco .
switch až na jeden planet všetko cisco .
0 x
-
neverhappy
- Příspěvky: 565
- Registrován: 19 years ago
Hatatitla píše:Teraz som sa vrátil od klienta Pripojený na airmax sektor uplink sektoru nv2 2x2 2ms a dalej dva skoky airmax 2x2 na rocketoch . UDP cez toto 60 Mbit 1 TCP 50 Mbit
switch až na jeden planet všetko cisco .
Jak jsi to meril? Ja jsem udelal trasu x86---NB25-------airmax 2x2------NB22-----x86. Pres jperf jsem v jednom TCP protahl 28 Mb. zitra to zkusim jeste premerit.
0 x
Hele, Hapi tam má těch switchů víc za sebou. Pěkně pomalu to z tebe leze. 
Jinak TPlink jetstream také podporuje a používá flow control. Srážka dvou takových switchů za sebou dopadá nedobře. Na tom jetstreamu jde vypnout (klasika v cmd: interface ethernet X / no flow-control). A zkontroluj si, zda náhodou nemáš zapnuté i nějaké řízení rychlosti. Tyhle switche mají "vlastnost", že když je zapnuté flow cotrol a je nastaven rate limit, tak to ztrátuje pakety tak nějak od přírody (port rate-limit, ať užiingress nebo outgress) a nemusí se ani nějak hluboce přibližovat k nastaveným stropům. Pokud si pamatuji, tak i dokumentace to nějak kulantně rozebírala.
Ta MAC 01:80:C2:00:00:01 je muticast adresa na kterou by posílal prvek oznámení protistraně, že chce přerušit vysílání od ní. Takže pokud by při zahjájení přenosu začly ty pakety chodit, tak to smrdí, že se snaží ten switch nadřazený pauzovat. nicméně v tvém případě by to spíš bylo, že tne vyhozený TPlink y se snažil pauzovat toho jetstreama. A tne by pak teoreticky později mohl zkusit pauzovat xeona. takže pro detekci by bylo třeba se píchnout mezi ne.
GS950 eco green low cost... je podezřelá krabička sama od sebe. Ať už provedneím nebo nastavneím to připomíná několik identických jiných krabic s dosti podivnými názvy, takže možná AT to kupuje někde v Číně a jen nechá lepit na to svoje logo, takže u tohoto typu s enedá divit ničemu.
A po zkušenosti i s takovou x900, což je trošku jiná cenová kategorie, se u AT nedá divit vůbec ničemu.
Jinak TPlink jetstream také podporuje a používá flow control. Srážka dvou takových switchů za sebou dopadá nedobře. Na tom jetstreamu jde vypnout (klasika v cmd: interface ethernet X / no flow-control). A zkontroluj si, zda náhodou nemáš zapnuté i nějaké řízení rychlosti. Tyhle switche mají "vlastnost", že když je zapnuté flow cotrol a je nastaven rate limit, tak to ztrátuje pakety tak nějak od přírody (port rate-limit, ať užiingress nebo outgress) a nemusí se ani nějak hluboce přibližovat k nastaveným stropům. Pokud si pamatuji, tak i dokumentace to nějak kulantně rozebírala.
Ta MAC 01:80:C2:00:00:01 je muticast adresa na kterou by posílal prvek oznámení protistraně, že chce přerušit vysílání od ní. Takže pokud by při zahjájení přenosu začly ty pakety chodit, tak to smrdí, že se snaží ten switch nadřazený pauzovat. nicméně v tvém případě by to spíš bylo, že tne vyhozený TPlink y se snažil pauzovat toho jetstreama. A tne by pak teoreticky později mohl zkusit pauzovat xeona. takže pro detekci by bylo třeba se píchnout mezi ne.
ludvik píše:Flow ano, ale neuvažoval jsem o něm vzhledem k rychlostem. Ale teď si vzpomínám, když si mi to připomenul, že jsem něco podobného řešil na Allied Telesyn (GS950 nebo tak nějak). Pause pakety chodily, i když neměly důvod.
GS950 eco green low cost... je podezřelá krabička sama od sebe. Ať už provedneím nebo nastavneím to připomíná několik identických jiných krabic s dosti podivnými názvy, takže možná AT to kupuje někde v Číně a jen nechá lepit na to svoje logo, takže u tohoto typu s enedá divit ničemu.
A po zkušenosti i s takovou x900, což je trošku jiná cenová kategorie, se u AT nedá divit vůbec ničemu.
1 x
na jetstemu to mám vypnutý, vždycky všude flow control vypínám. Za cca půl hoďky zapnu původní switch a něco budou zkoušet. Jestli mě nasere tak ho vymontuju a podám si ho na stole mezi dvěmi servery
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
neverhappy píše:Hatatitla píše:Teraz som sa vrátil od klienta Pripojený na airmax sektor uplink sektoru nv2 2x2 2ms a dalej dva skoky airmax 2x2 na rocketoch . UDP cez toto 60 Mbit 1 TCP 50 Mbit
switch až na jeden planet všetko cisco .
Jak jsi to meril? Ja jsem udelal trasu x86---NB25-------airmax 2x2------NB22-----x86. Pres jperf jsem v jednom TCP protahl 28 Mb. zitra to zkusim jeste premerit.
U klienta btest pre windows protistrana virtuálny mikrotik na blade centre.
0 x
Majklik píše:Kbyby se Hapi moc nudil. Co se stane, když mezi ten TPlink a xeon strčíš tu RB250GS? Jde to blbě nebo dobře (signalizačně a elektricky jsi oddělil intel síťovku a tplinkl)? A co se stane, kdyř pak na tom 250GS zapneš MAC filtr, který nebude propouštět rámce s cílovou MAC 01:80:C2:00:00:01 (zablokuji doručování pauze rámců do xeonu)? Má to dopad?
tak jsem si pohrál
xeon - jetstream - RB250GS = ok
xeon - jetstream - tplink - RB250GS = ok
xeon - jetstream - RB250GS - tplink = ko!!
xeon - jetstream - tplink = ko!!
znatelně poklesly i aktuální toky co tam userům tečou. Chápu že to může způsobovat traffic flow. Jestli ho má ten nemanagement tplink zapnutej defaultně tak může zasekávat provoz. Proto když je v cestě na gigovym spoji tak se neaktivuje a propouští dál bez problémů. Jakmile má toky cpát do 100Mbit hrdla tak je v háji. Řešením tedy je použít management switch a vypnout flow control tak jako to je na RB250GS.
Je moje dedukce správná? Pokud budu nasazovat L2 switche při přechodech gigo/fast a vypínat flow control tak bych se měl těchto průserů vyvarovat.
EDIT: zapnul jsem na RB250GS traffc flow a žádná změna nenastala takže předpokládám že má RB250GS větší buffery kam se data vejdou a stihne to vykrejt než se data nasoukaji do fast ethernetu.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
Ty brdo dle toho testu babo rad, nedava me to vubec smysl kde je brzda.
Edit: aha vzdy kdyz je na konci TP-LINK, tak je to ko, co je to za model?
Edit: aha vzdy kdyz je na konci TP-LINK, tak je to ko, co je to za model?
0 x
je to TL-SG1016, doufám
no předpokládám že problém je mezi přechodem gigo/fast a tam záleží na switchy. Myšleno jako že uplink je gigo a dál to jede na fast. Myslím že nasazení L2 switchů se tomu dá předejít. Jiným směrem máme L2 switch a nedělá to tam. Oba přitom vedou do toho samého jestreamu.
Mějme test v TCPku. Stanoví se tcp window size a xeon to pošle všechno plnou gigovou rychlostí. Dejme tomu že se nastaví 16kB a to se pošle. Switch to musí zpomalit z giga na fast. V ten okamžik se nejspíš začnou zahazovat na switchy pakety aby to zbrzdil. Předchozí switch na flow control neraguje, je vypnutý takže prostě musí zahodit. No a to uměle sníží tcp window size a pak jsou to mizerný rychlosti. Proto z xeonu to jelo tak blbě a z RB433AH která má fast ethernet to jelo v pohodě. RB433AH nemůže na fastu donutit switch k zahazování paketů protože se stejnou rychlostí odesílají dál. To samí linux server na gigu se speedtestem. Paradoxně větší tcp window size bylo víc na škodu.
Jo pozor, na tom obrázku jsou sice RB711G ale neni tam gigový poe takže jedou na fast. Proto to musí zabrzdit switch. Předpokládám že RB250GS má větší buffer.
no předpokládám že problém je mezi přechodem gigo/fast a tam záleží na switchy. Myšleno jako že uplink je gigo a dál to jede na fast. Myslím že nasazení L2 switchů se tomu dá předejít. Jiným směrem máme L2 switch a nedělá to tam. Oba přitom vedou do toho samého jestreamu.
Mějme test v TCPku. Stanoví se tcp window size a xeon to pošle všechno plnou gigovou rychlostí. Dejme tomu že se nastaví 16kB a to se pošle. Switch to musí zpomalit z giga na fast. V ten okamžik se nejspíš začnou zahazovat na switchy pakety aby to zbrzdil. Předchozí switch na flow control neraguje, je vypnutý takže prostě musí zahodit. No a to uměle sníží tcp window size a pak jsou to mizerný rychlosti. Proto z xeonu to jelo tak blbě a z RB433AH která má fast ethernet to jelo v pohodě. RB433AH nemůže na fastu donutit switch k zahazování paketů protože se stejnou rychlostí odesílají dál. To samí linux server na gigu se speedtestem. Paradoxně větší tcp window size bylo víc na škodu.
Jo pozor, na tom obrázku jsou sice RB711G ale neni tam gigový poe takže jedou na fast. Proto to musí zabrzdit switch. Předpokládám že RB250GS má větší buffer.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
Takze pokud mam vse na 100Mbitu nebo vse na gigu melo by to byt OK, pokud to nekrmim nicim vetsim.
Pokud mam v ceste jakekoli zpomaleni treba wifi tak se to pak chova stejne jako skok z 1Gbit na 100Mbit.
Jak je teda mozne ze se zahazovani packetu pri 1TCP spojeni projevi az na druhem wifi spoji a da to tolik malo?
Jedine ze by to retezilo nejak chyby prenosu a zahlcovalo CPU dopocitavanim chyb ktere tam jsou a tim snizovalo rychlost - asi blbost.
Pokud mam v ceste jakekoli zpomaleni treba wifi tak se to pak chova stejne jako skok z 1Gbit na 100Mbit.
Jak je teda mozne ze se zahazovani packetu pri 1TCP spojeni projevi az na druhem wifi spoji a da to tolik malo?
Jedine ze by to retezilo nejak chyby prenosu a zahlcovalo CPU dopocitavanim chyb ktere tam jsou a tim snizovalo rychlost - asi blbost.
0 x
předně... cpu žádný chyby nikdy nedopočítává. Buď chyby jsou a přenos se opakuje což je záležitost koncových bodů a nebo nejsou. Žádný dopočítávání neni kromě FECu na wifině který ale řeší wifi chipset.
Mě se to projevuje hned na prvnim spoji.
Mě se to projevuje hned na prvnim spoji.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
hapi píše:Mě se to projevuje hned na prvnim spoji.
Súhlas, hneď prvý spoj buď maká alebo nie. Ďalšími spojmi sa len percentuálne znižuje už i tak nízka prenosovka na jedno spojenie. Dnes som spozoroval, že pri ccq 90/100 mi v konfigurácii MIMO 2x2 20Mhz rb711G vs RB711G dá na spojenie 7-15Mbps. Zmena frekvencie, ccq 100/100 a prenosovka 38Mbps! Totožný config, len iný sajt a to samé. Jedno spojenie v ccq 80/95 a spojenie až 5-10Mbps, po zmene frekcencie 32Mbps.
A zaujímavé, že spoj na 4km v rovnakej konfigurácii nie je takto nemocný. Rozdieľ je, že vzdialenejší spoj jede na 411AH na obidvoch stranách a nemá žiadny problém a ccq mi tam behá k 90/90. Mám nastavené NV2 size na 3, po zmene na 1 priepustnosť spoja ako celku klesla z 96Mbps na 66Mbps, odozvy padli k 4ms, ale na jedno spojenie takmer rovnaká bieda.
0 x
Hapi, při tom testu:
"xeon - jetstream - tplink - RB250GS = ok"
jsi nastavovla rb250GS tak, aby proti TPlinku vynutil 100 Mbps linku? Pokud ano, tak tplink to neprzní na problému přechodu 1G/100M, pokud ne a jelo to na gigu do 250gs, tak při pohledu na větu:
"Jo pozor, na tom obrázku jsou sice RB711G ale neni tam gigový poe takže jedou na fast. "
Tak nevylučuji i problém se signalizací na L1 vrstvě. Si vybavuji jednu hodně škaredou vzpomínku na stejné téma. V mém připadě to byla gigová RB600A, z nutnosti napájeno přes PoE dovolující jen stovku a píchlé do gigového switche. A ono to bylo naprd, ztrátovlo to, teorie o rušení karet v RBčku, magie s dráty, ... Nakonec se ukázalo, že sice RB600A poctivě hlásila a držela 100 Mbps, ale switch na druhé straně byl signalizačně zmaten a většinu života trávil pokusy o přehození na gigo, což logicky nešlo. Měl naštěstí managament a zcela výmluvný obsah logu. Linka slušně ztrátovala. I když se na RB600A natvrdo nastavila stovka, tak RB hlásilo stabilní stovku a switch cvičil, až po nastavneí switche na 100 to dalo pokoj. Ale šlo o chybu v ROS, kdy to nastavneí nefungovalo, v nějaké další verzi to opravili.
Takže v tvém případě by se i hodilo tu 711G nastavit natvrdo, že chceš stovku ethernet. Ale jeslti jsi to při použití toho TL-SG1016 to krmil odshora něčím s limitme na stovku (RB433AH) a neblbo to, tak se dá L1 problém považovat za nepravděpodobný. Na UDP testu u toho už by byla vidět dosti vysoká ztrátovost (aspoň mi tma naskakovala).
Jinak hádat, zda ma RB250GS menší/vtší bafry než ten TPlink je spekulace, dá se najít teorie pro oba případy, proč to blbne.
"xeon - jetstream - tplink - RB250GS = ok"
jsi nastavovla rb250GS tak, aby proti TPlinku vynutil 100 Mbps linku? Pokud ano, tak tplink to neprzní na problému přechodu 1G/100M, pokud ne a jelo to na gigu do 250gs, tak při pohledu na větu:
"Jo pozor, na tom obrázku jsou sice RB711G ale neni tam gigový poe takže jedou na fast. "
Tak nevylučuji i problém se signalizací na L1 vrstvě. Si vybavuji jednu hodně škaredou vzpomínku na stejné téma. V mém připadě to byla gigová RB600A, z nutnosti napájeno přes PoE dovolující jen stovku a píchlé do gigového switche. A ono to bylo naprd, ztrátovlo to, teorie o rušení karet v RBčku, magie s dráty, ... Nakonec se ukázalo, že sice RB600A poctivě hlásila a držela 100 Mbps, ale switch na druhé straně byl signalizačně zmaten a většinu života trávil pokusy o přehození na gigo, což logicky nešlo. Měl naštěstí managament a zcela výmluvný obsah logu. Linka slušně ztrátovala. I když se na RB600A natvrdo nastavila stovka, tak RB hlásilo stabilní stovku a switch cvičil, až po nastavneí switche na 100 to dalo pokoj. Ale šlo o chybu v ROS, kdy to nastavneí nefungovalo, v nějaké další verzi to opravili.
Takže v tvém případě by se i hodilo tu 711G nastavit natvrdo, že chceš stovku ethernet. Ale jeslti jsi to při použití toho TL-SG1016 to krmil odshora něčím s limitme na stovku (RB433AH) a neblbo to, tak se dá L1 problém považovat za nepravděpodobný. Na UDP testu u toho už by byla vidět dosti vysoká ztrátovost (aspoň mi tma naskakovala).
Jinak hádat, zda ma RB250GS menší/vtší bafry než ten TPlink je spekulace, dá se najít teorie pro oba případy, proč to blbne.
0 x
žádný vynucování. Mezi tplinku a rb250 běželo gigo. Jo asi kybych stahnul gigo na fast tak to začne blbnout.
Jako jo, asi by bylo vhodný najít proč to dělá ale nebudu to řešit. Nasadim L2 switche a bude klid. Naše core obsahuje pouze 3 switche na plnym gigu takže nic velkýho. Dál už je všude fast i když se jednou stranou do města gigo je ale tam je orcave na gigo ethernetech a frčí to tam o sto šest. Dál jsou přes router gigový rozvody do L2 switchů s vlany na fast porty a tam taky neni problem.
Teď tu mám signamaxe a ten ukazuje jestli na porty použil flow control což je zajimavá věc. Proti PC flow control nikdy nenaskočilo ale proti neřízenýmu switchy vždy.
Jako nevim, všechno jsou spekulace. Výsledek je že stačilo vyměnit switch a je klid. Ještě bych tam mohl šoupnout nějakej stolní switch na gigu jestli to bude dělat taky,
Jako jo, asi by bylo vhodný najít proč to dělá ale nebudu to řešit. Nasadim L2 switche a bude klid. Naše core obsahuje pouze 3 switche na plnym gigu takže nic velkýho. Dál už je všude fast i když se jednou stranou do města gigo je ale tam je orcave na gigo ethernetech a frčí to tam o sto šest. Dál jsou přes router gigový rozvody do L2 switchů s vlany na fast porty a tam taky neni problem.
Teď tu mám signamaxe a ten ukazuje jestli na porty použil flow control což je zajimavá věc. Proti PC flow control nikdy nenaskočilo ale proti neřízenýmu switchy vždy.
Jako nevim, všechno jsou spekulace. Výsledek je že stačilo vyměnit switch a je klid. Ještě bych tam mohl šoupnout nějakej stolní switch na gigu jestli to bude dělat taky,
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků