1st aerial - AirBQ 9GHz

Kolobok

V podstatě ano, ale s Gbit ethernetem a propustností 150Mbit

ladik

No a kdy nstreme pojede i u mne na tri mesice starych jednotkach?

Takto je to strasne pomale s tim NV2.

Diky

Kolobok

Nstreme se tyka spoju s RB951. Nevim ,už třikrat jsem nabizel pomoc, že ti to zkontroluju, co tam mas blbe nastavene. Zatim bez odpovedi. M

ladik

Nevim blbe tam asi nic neni proste chci nstreme ne NV2 to je cele (ve specifikacich to nikde neni ze je to NV2 only) jinak to jede, ale latence je velka proste NV2 :-(

Takze kdyz tam vrazim 951 nstreme pojede? To urcite ne mas tam prece jakousi upravu toho nasobice ne?

hapi

vůbec nečum na latenci. Nstreme já má taky neboj ale až když se zatíží a je daleko větší než u NV2. Spíš bych se zaměřil na to aby přes to proteklo co nejvíc při jednom spojení na TCP. Ping neni dobrej diagnostickej nástroj obzvlášť když tam nic neteče :-)

grfs

u RB by me osobne zajimala prenosova rychlost na 64byte ramcich, nebot tam dostava CPU nejvetsi zahul

Kolobok

cca 40000 paketu za sekundu..

lwq

Lehky dotaz ... Kolik tenhle spoj vzladne UDP provozu typu multicast ? Jde mi o IPTV ... Chci timto spojem nahradit na 3km spoj v 5G ... Podminka 100mbps a multicast ... 8)

Kolobok

cca 220 Mbit s ROS 6. 250

Kolobok

AirBQ s integrovaným AP pro 5 GHz 2x2 MIMO skladem a v ceníku..

Letošní jednotka se sériovým číslem 1000 bude zdarma! Hlídejte si faktury :

Kolobok

Doporučujeme všem, kteří na svých spojích používají Nstreme přenosovou metodu, aby si nahráli nový ROS 6.7, kde došlo k výraznému zlepšení přenosových parametrů a především k výrazné stabilizaci přepínání modulačních metod!

P.S. No konečně : Nstreme bude moci být plnokrevným zástupcem NV2 s nízkou latencí..

Zatím jsem to testoval jenom asi na 30 spojích, ale u všech je vidět okamžitý rozdíl.

Kolobok

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

O co jde?

V momentě, kdy děláte testy propustnosti jenom mezi MW jednotkami, chybka není vidět, spoj pouští, kolik dá (cca do 220Mbit)

Jakmile jej ale skřípnete mezi další dva routery a děláte testy přes spoj, tak pomocí jedné fronty protáhnete maximálně cca 25-45Mbit (takhle se ten bug projevuje). Stává se to velmi řídce (například u nás v síti, ačkoliv máme nasazeny desítky jednotek se to neprojevuje a na jednom spoji, na 1 frontu mám propustnost cca 140Mbit).

Je to něco, co chce teď MikroTik řešit, protože na to vedou dost připomínek. Pravděpodobně to souvisí se skladbou v síti, typem komponent a balastem, který se tam šíří, možná nakládáním dat na interfacech.

V některých typech sítí se to projevuje, jinde ne.. Pokud něco podobného pozorujete a byli byste ochotni zřídit na dotčených prvcích účet pro Mikrotik, dejte mi prosím vědět do PM.

Dík Michal

zero

předpokládám, že by to měli být pčístupy na nějaký testovací mašiny, ne? Nebo se pánové inženýři budou hrabat na prvcích sítě s ostrým provozem?

Díky za info

Kolobok

předpokládám, že by to měli být pčístupy na nějaký testovací mašiny, ne? Nebo se pánové inženýři budou hrabat na prvcích sítě s ostrým provozem?

Díky za info

Chtějí na tom pustit, nějaké vlastní testy propustnosti.. Ostrý provoz asi není na překážku

dalibortoman

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?

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í.

Kolobok

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..

Kolobok

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.

dalibortoman

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 ...

« Předchozí stránka Další stránka »