vypadek paketu

[hapi]

In Dropped Packets: 17047025

[Pintero]

Je to spoj na CCA 3.5 kilometru na 40cm parabolách

Takže to máš o 20 dBm z antény přepálený

[hapi]

no to je mi celkem fuk, to má každej první

ale vidim tam že jedna strana nejede zrovna rychlostí na max.

[zdwena]

To že to není slinkováno rychlosti na max neznamená, že je úplně špatně.
Když to padá do racom A ze switche každopadně dneska budu zkouše laborovat s tím kabelem.

O tom ,že vysiláme vyžším výkonem víme ale jsme omezení velikosti antény kterou můžeme v daném místě použít

[zdwena]

Tak ted jsem v koncích včera jsem ještě zapnul flow control na anténach
a:

In All Packets: 6475032
In Unicast Packets: 6473999
In Multicast Packets: 808
In Broadcast Packets: 225
In All Errors: 0
In Dropped Packets: 0
In Crc Errors: 0
Out All Packets: 4543275
Out Unicast Packets: 4517092
Out Multicast Packets: 10804
Out Broadcast Packets: 15379
Out All Errors: 0
Out Dropped Packets: 0
Out Collisions: 0
Statistics Cleared: 1464939554
Statistics Period: 1428
Uptime: 1428
Downtime: 0
Reliability: 100.0000
The Longest Drop: 153760
Number of Drops: 0

žádne errory nenaskakuji....

ale vypadky jsou porad...

[zdwena]

A ted s vypnutym flow control

In All Packets: 165169
In Unicast Packets: 165146
In Multicast Packets: 21
In Broadcast Packets: 2
In All Errors: 650
In Dropped Packets: 650
In Crc Errors: 0
Out All Packets: 95255
Out Unicast Packets: 94541
Out Multicast Packets: 300
Out Broadcast Packets: 414
Out All Errors: 0
Out Dropped Packets: 0
Out Collisions: 0
Statistics Cleared: 1464941299
Statistics Period: 42
Uptime: 42
Downtime: 0
Reliability: 100.0000
The Longest Drop: 154119
Number of Drops: 0


naskakuji IN all errors

nic mene zkusime ten kabel

[Dalibor Toman]

to je nejake divne. Konzultoval bych s vyrobcem co to ma znamenat.

[zdwena]

Ještě další test pokud by to někoho ještě zajímalo..

nechal jsem vypnute flow control tip padem naskakovaly
ty errory na ethernetu

ale když jsem slinkoval tu vysilaci stranu jen na 100MB/s misto puvodnich 1000MB/s

tak přestalo vypadavat spojeni a zadne errory nenaskakuji

[Dalibor Toman]

u ALCOM je nekdy problem na 1000mbps se synchronizaci hodinoveo signalu diky nepovedene domluve, kdo bude Master a kdo Slave na tom ethernetu. Objevuji se CRC chyby. Je treba rucne ethernet v radiu nastavit do Slave modu. Nevim jestli neco takoveho Racom umoznuje...

[zdwena]

To bych potřeboval torchu vysvětlit prosím ..

[Dalibor Toman]

na gigovem eth se musi pri sestavovani spojeni obe strany dohodnout, kdo bude Master a kdo Slave. Slave IMHO provadi synchronizaci svych hodinovych obvodu rekonstrukci hodin ze signalu, ktery posila Master. Pokud selze negociace a obe strany jsou Master (coz se stava MPckovym ALCOMam), muze dojit k tomu, ze nevysilaji na stejne frekvenci a pak se nesampluje prijimany signal spravne a vznikaji chyby. Proto je treba tu ALCOMu v nekterych pripadech prepnout do Slave modu (typycky po pripojeni k Cisco switchi ci RB2011)

[zdwena]

Doufám že to není můj připad:

Na jedné straně spoje dochází ke ztrátám paketů, roste položka InDroppedPkts ve statistice. Mám vadnou jednu stranu spoje?

S největší pravděpodobností nemáte. Ke ztrátám dochází na rozhraní mezi 1 Gb Ethernetem a 170 Mbps rádiem. Určité procento ztrát na takovém „zúžení“ linky je projevem normální činnosti TCP protokolu: TCP se snaží z linky „vymačkat“ co nejvíc, každou chvíli zvýší rychlost, pošle burst, na „zúžení“ se část burstu ztratí, TCP ubere na rychlosti a tak pořád dokola.
Typicky jsou ztráty pouze na straně připojené ke zdroji konektivity, protože průměrná velikost paketu ze strany klientů je výrazně menší, i když počet je přibližně stejný.
Z výše popsaného chování TCP protokolu vyplývá, že ke ztrátám na trase někde docházet vždycky musí, logicky je to většinou na zařízení, kde je největší rozdíl mezi vstupní a výstupní rychlostí.

[hapi]

kdyby si chvilku taky poslouchal. errory muzes mit proto, protoze uz radio tak moc nestiha ze se to uz jako dropy neda povazovat.

Jiste ze po zapnuti flow control vsechno vypada ok akorat si to prenesl ten problem jinam, na switch. Asi bych pichnul racoma do mikrotika, zapnul flow control a zvetsil vystupni buffer v mikroitku na portu do racoma.

je hezke sledovat jak to stoji takovy prachy a tak malo to zvlade, ze. zajimalo by me jak pres to muze chodit qos kdyz to nezvladne ani normalni provoz.

proc ti tam pisou 170mbit kdyz si poslal 360mbit?

[ludvik]

jak?

... a zvetsil vystupni buffer v mikroitku na portu do racoma.

[hapi]

v queue máš záložku interface queues. Tam můžeš měnit typ queue. Můžeš si tedy v záložce queue types vytvořit tovej typ, nastavit jí třeba fifo a klidně 2MB buffer a pak ho zvolíš v interface queues. Měl by se zařazovat na výstup ifacu.

Teoreticky by racom měl signalizovat přes flow control pozastavení provozu a mikrotik by to měl nějakou dobu ustát přes tenhle buffer a pak začne dropovat sám případně signalizovat sám flow control někam dál.

Jo a samozřejmě musíš na portu v mikrotiku do racoma povolit flow control.

Je to jenom teorie ale mohla by fungovat.