Page 1 of 1

CQQ=100% but extensive data los - why ?

Posted: Mon Sep 27, 2010 4:51 pm
by batot
http://89.25.159.18/~bartosz/mikrotik_error01.png

Why microtik diconnect?
RB433 + CM9 card v.4.11
AP BRIDGE 2,4Ghz + MODE:ONLY_G

Sometimes 5h working properly but later x times diconnect between 1~5min.
Who have any idea why disconnect?

SCAN FREQ USE CHANNEL <0~3% - CQQ-100%!!!

Mikrotik it's shit, isn't suited for hardware solution.

Re: CQQ=100% but extensive data los - why ?

Posted: Tue Sep 28, 2010 3:31 am
by xxiii
The CCQ in the other direction isn't necessarily 100%. If the client you're using supports reporting the values back to the AP, (which apparently it doesn't in this case), the CCQ box would show something like 100/100, one of which would be the CCQ from the AP to the client, and the other would be the CCQ from the client to the AP.

Check on the client side what the connection is like. There may also be an intermittent interference problem which isn't present when you are running your scan.

Re: CQQ=100% but extensive data los - why ?

Posted: Tue Sep 28, 2010 4:17 am
by charliebrown
Can confirm on PtP links with MT on both sides running new gear we sometimes see EDL's even when link SNR is 30+ and CCQ's 100%. Have put it down to thermal ducting for now since its mainly Hill to Hill over valley links that seem to do it. But would interested to hear what MT have to say about this

Re: CQQ=100% but extensive data los - why ?

Posted: Tue Sep 28, 2010 12:44 pm
by ayufan
SCAN FREQ USE CHANNEL <0~3% - CQQ-100%!!!

Mikrotik it's **it, isn't suited for hardware solution.
Because CCQ=100% when link is idle is not valid measurement of link quality. That's why I test it from linux:
ping -f -s 1400 <ip_address_of_device_on_the_other_side>
Stable and efficient link should have a packet loss up to 3%.

Re: CQQ=100% but extensive data los - why ?

Posted: Wed Sep 29, 2010 12:59 am
by charliebrown
3%!!! Really?

We dont like 1% on links and try for .1-.2%

Re: CQQ=100% but extensive data los - why ?

Posted: Wed Sep 29, 2010 10:01 am
by ayufan
3% is safe to work just ok, on wireless links is not that much. Also take in account that you send MTU sized packets, so you check full duplex connectivity ;)

Re: CQQ=100% but extensive data los - why ?

Posted: Thu Sep 30, 2010 1:07 am
by charliebrown
3% is rubbish if your trying to do VOIP, We have 0% PL on all our backhauls in the last 10 days

Re: CQQ=100% but extensive data los - why ?

Posted: Thu Sep 30, 2010 1:30 am
by ayufan
"Small" loss on VoIP is not a problem as long as you have low jitter.

Re: CQQ=100% but extensive data los - why ?

Posted: Thu Sep 30, 2010 3:38 am
by charliebrown
Any loss is detectable in the audio quality, Not so much running G711 but thats a bandwidth hog and G729 will show up even small packetloss in the call, Jitter buffers help slightly but RTP uses UDP and thus has no voice retransmission

Re: CQQ=100% but extensive data los - why ?

Posted: Thu Sep 30, 2010 1:06 pm
by Muqatil
retransmissions are done by wireless hardware, so i don't think it's a problem of UDP..
I've some packet loss on my backhaul, but the voice quality is excellent (like PSTN)

Re: CQQ=100% but extensive data los - why ?

Posted: Fri Oct 01, 2010 2:16 am
by charliebrown
retransmissions are done by wireless hardware, so i don't think it's a problem of UDP..
I've some packet loss on my backhaul, but the voice quality is excellent (like PSTN)
If the wireless retransmit's, We dont have packetloss on our main links, If you get packetloss on a PTP link your doing it wrong

Re: CQQ=100% but extensive data los - why ?

Posted: Mon Oct 04, 2010 2:37 am
by Belyivulk
I thought that UDP wasn't retransmitted since it doesn't receive an ACK?

Re: CQQ=100% but extensive data los - why ?

Posted: Mon Oct 04, 2010 5:31 am
by ayufan
It's done by wireless hardware.

Re: CQQ=100% but extensive data los - why ?

Posted: Mon Oct 04, 2010 10:06 pm
by xxiii
Its a layer-2 retransmission, as opposed to layer-3.

Re: CQQ=100% but extensive data los - why ?

Posted: Tue Oct 05, 2010 12:07 am
by charliebrown
In some case's, If it worked as well as its meant to you wouldn't see loss on a link unless you hit the l2 retransmission limit you would just see high jitter and latency spikes.

That fact that you do see packet loss on a link shows that l2 retransmission doesn't always work