Community discussions

MikroTik App
 
BluemaxOhio
just joined
Topic Author
Posts: 1
Joined: Wed Jul 01, 2020 1:46 am

Tracking down the source of jitter.

Wed Jul 01, 2020 1:55 am

Greetings,
Like many others I troll the forums looking for information. Never participating, just using and ditching. Rather like a bad boyfriend. I made an account to ask you Mikrotik Mages for wisdom.

I'm running Mikrotik RouterBoard CCR1036-12G-4S which is the brain behind my wireless network. Currently I have 13 wireless clients from 1 to 4 miles away. At the start of my project, Ping was always below 10, jitter was 0-1 down\up was almost always 20\20 ( where I have it capped ) I am also feeding this router with a 1GB fiber connection.

However something has changed and I cant figure out what. All clients are having a serious jitter\upload issue. No equipment changes, no software changes. etc. Everything is as, as was.
Speeds have dropped on on the downloads to an average of 5 or less and uploads on all clients are around 0.80 to 0.30
With pings averaging almost 100, and jitter now going from 500 to over 5000.

I went over all wireless equipment. Up to date, signal is phenomenal. ( SINADR\RSSI ) 30+ above.
Throughput is barely being utilized.

Could my jitter\bottlneck of dumb have something to do with my router?

Thanks for any input, much appreciated!

- larry
 
changeip
Forum Guru
Forum Guru
Posts: 3830
Joined: Fri May 28, 2004 5:22 pm

Re: Tracking down the source of jitter.

Thu Jul 02, 2020 8:09 pm

+30 is too hot - turn the power down. thats like shouting at your mom with a megaphone in the same room.

There is probably interference. Try changing channels.
 
User avatar
bpwl
Forum Guru
Forum Guru
Posts: 2994
Joined: Mon Apr 08, 2019 1:16 am

Re: Tracking down the source of jitter.

Thu Jul 02, 2020 9:57 pm

"Everything is as, as was."

Your equipment is, your settings are .... but the RF environment is not under your control. Clients 4 km away, there can be a lot that has changed.

Check the quality of your connection (not only RSSI and SNR) but check for retransmits due to bit errors and interference. Bit errors may be due to things in the fresnel zone of your link. (eg.: the tree has grown larger)
The check is not only for the P throughput, but also the CCQ of your connection. The CCQ depends on the need for retransmission (retransmission because no valid ACK was received for the packet).

In wireless "registration" all information can be found. Compare the number of frames with the number of HW frames. How stable is the interface data rate for RX and TX? (Failing 3 times the number of HW_retries will step down the interface rate one step.)
 
n21roadie
Forum Guru
Forum Guru
Posts: 1949
Joined: Fri Aug 07, 2009 10:36 pm
Location: Limerick,Ireland

Re: Tracking down the source of jitter.

Sun Dec 06, 2020 10:44 pm

@bpwl
...In wireless "registration" all information can be found. Compare the number of frames with the number of HW frames. How stable is the interface data rate for RX and TX? (Failing 3 times the number of HW_retries will step down the interface rate one step.)...


I have attached screenshots of a CPE with poor signal and fresnel zone clearance issue - Can you explain please where the CPE would report HW-retries ?
You do not have the required permissions to view the files attached to this post.
 
User avatar
bpwl
Forum Guru
Forum Guru
Posts: 2994
Joined: Mon Apr 08, 2019 1:16 am

Re: Tracking down the source of jitter.

Mon Dec 07, 2020 12:57 am

@bpwl
...In wireless "registration" all information can be found. Compare the number of frames with the number of HW frames. How stable is the interface data rate for RX and TX? (Failing 3 times the number of HW_retries will step down the interface rate one step.)...


I have attached screenshots of a CPE with poor signal and fresnel zone clearance issue - Can you explain please where the CPE would report HW-retries ?
You look at NV2 information. So I assume, based on that, that you are using NV2 as protocol. NV2 has other mechanisms than 802.11 to handle the traffic. 802.11 does retransmit when there is no ACK received, and has a frames counter and a HW frames counter (which includes the retransmits). That ratio is calculated and averaged in the CCQ number. There is also a settable parameter "hw_retries" in the advanced tab. NV2 is more obscure in its working. It is not showing the HW frames, but the CCQ is still there. I'm not sure this has the same meaning, as nstreme and NV2 use error correction techniques to correct corrupted packets. (For the official text see the FAQ: https://wiki.mikrotik.com/wiki/Manual:Wireless_FAQ ). In practice I know that changing from 802.11ac to NV2 , the CCQ jumped from 90% to 98% in most of my links. The PHY rate went to max after some traffic, and stayed there.

Looking at you screen-shots : a "Tx/Rx CCQ of 41/56%" looks very low to me. (I even did not have this low numbers with the leaves growing on the trees in summertime. I ended up with 70% and lost quite some speed. Switching to NV2 could not correct this. Cleaning the fresnel zone, trimming the trees, did improve till 90%, NV2 did the rest. Unfortunately I do not know how NV2 could be made more robust, apart from HW retries which I set to 15. For jitter the number of priority queues in NV2 could matter. https://wiki.mikrotik.com/wiki/Manual:Nv2 , no experience with that).

Who is online

Users browsing this forum: dgel27 and 139 guests