strange Ping-times...

RouterOS Wireless Networking
1

we have some Mikrotik APs on RB532 with Linksys Client (2,4GHz) and WPA AES enabled

When i Ping a few minutes, the result is as following:


64 bytes from 192.168.182.1: icmp_seq=0 ttl=64 time=7.2 ms
64 bytes from 192.168.182.1: icmp_seq=0 ttl=64 time=8.1 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=1 ttl=64 time=999.4 ms
64 bytes from 192.168.182.1: icmp_seq=1 ttl=64 time=1001.8 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=2 ttl=64 time=306.6 ms
64 bytes from 192.168.182.1: icmp_seq=2 ttl=64 time=306.9 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=3 ttl=64 time=5.2 ms
64 bytes from 192.168.182.1: icmp_seq=3 ttl=64 time=6.7 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=4 ttl=64 time=6.6 ms
64 bytes from 192.168.182.1: icmp_seq=4 ttl=64 time=6.9 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=5 ttl=64 time=4.8 ms
64 bytes from 192.168.182.1: icmp_seq=5 ttl=64 time=7.0 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=6 ttl=64 time=5.5 ms
64 bytes from 192.168.182.1: icmp_seq=6 ttl=64 time=5.8 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=7 ttl=64 time=5.0 ms
64 bytes from 192.168.182.1: icmp_seq=7 ttl=64 time=5.7 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=8 ttl=64 time=6.9 ms
64 bytes from 192.168.182.1: icmp_seq=8 ttl=64 time=7.2 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=9 ttl=64 time=5.8 ms
64 bytes from 192.168.182.1: icmp_seq=9 ttl=64 time=7.8 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=10 ttl=64 time=4.6 ms
64 bytes from 192.168.182.1: icmp_seq=10 ttl=64 time=5.4 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=11 ttl=64 time=284.5 ms
64 bytes from 192.168.182.1: icmp_seq=11 ttl=64 time=286.0 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=12 ttl=64 time=8.5 ms
64 bytes from 192.168.182.1: icmp_seq=12 ttl=64 time=9.2 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=13 ttl=64 time=5.3 ms
64 bytes from 192.168.182.1: icmp_seq=13 ttl=64 time=5.6 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=14 ttl=64 time=6.1 ms
64 bytes from 192.168.182.1: icmp_seq=14 ttl=64 time=6.5 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=15 ttl=64 time=6.5 ms
64 bytes from 192.168.182.1: icmp_seq=15 ttl=64 time=7.3 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=16 ttl=64 time=10.9 ms
64 bytes from 192.168.182.1: icmp_seq=16 ttl=64 time=12.4 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=17 ttl=64 time=5.6 ms
64 bytes from 192.168.182.1: icmp_seq=17 ttl=64 time=6.3 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=18 ttl=64 time=9.3 ms
64 bytes from 192.168.182.1: icmp_seq=18 ttl=64 time=9.6 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=19 ttl=64 time=5.2 ms
64 bytes from 192.168.182.1: icmp_seq=19 ttl=64 time=6.9 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=20 ttl=64 time=8.4 ms
64 bytes from 192.168.182.1: icmp_seq=20 ttl=64 time=8.8 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=21 ttl=64 time=269.3 ms
64 bytes from 192.168.182.1: icmp_seq=21 ttl=64 time=270.9 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=22 ttl=64 time=65.3 ms
64 bytes from 192.168.182.1: icmp_seq=22 ttl=64 time=66.8 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=23 ttl=64 time=7.0 ms
64 bytes from 192.168.182.1: icmp_seq=23 ttl=64 time=7.4 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=24 ttl=64 time=102.8 ms
64 bytes from 192.168.182.1: icmp_seq=24 ttl=64 time=104.4 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=25 ttl=64 time=4.7 ms
64 bytes from 192.168.182.1: icmp_seq=25 ttl=64 time=6.3 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=26 ttl=64 time=6.5 ms
64 bytes from 192.168.182.1: icmp_seq=26 ttl=64 time=9.5 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=27 ttl=64 time=6.4 ms
64 bytes from 192.168.182.1: icmp_seq=27 ttl=64 time=8.1 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=28 ttl=64 time=11.0 ms
64 bytes from 192.168.182.1: icmp_seq=28 ttl=64 time=12.4 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=29 ttl=64 time=5.0 ms
64 bytes from 192.168.182.1: icmp_seq=29 ttl=64 time=6.5 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=30 ttl=64 time=4.9 ms
64 bytes from 192.168.182.1: icmp_seq=30 ttl=64 time=6.5 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=31 ttl=64 time=199.8 ms
64 bytes from 192.168.182.1: icmp_seq=31 ttl=64 time=201.7 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=32 ttl=64 time=16.1 ms
64 bytes from 192.168.182.1: icmp_seq=32 ttl=64 time=17.7 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=33 ttl=64 time=8.4 ms
64 bytes from 192.168.182.1: icmp_seq=33 ttl=64 time=10.1 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=34 ttl=64 time=4.6 ms
64 bytes from 192.168.182.1: icmp_seq=34 ttl=64 time=8.3 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=35 ttl=64 time=10.5 ms
64 bytes from 192.168.182.1: icmp_seq=35 ttl=64 time=12.4 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=36 ttl=64 time=9.5 ms
64 bytes from 192.168.182.1: icmp_seq=36 ttl=64 time=11.0 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=37 ttl=64 time=6.2 ms
64 bytes from 192.168.182.1: icmp_seq=37 ttl=64 time=7.6 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=38 ttl=64 time=9.5 ms
64 bytes from 192.168.182.1: icmp_seq=38 ttl=64 time=10.8 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=39 ttl=64 time=7.6 ms
64 bytes from 192.168.182.1: icmp_seq=39 ttl=64 time=9.2 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=40 ttl=64 time=14.8 ms
64 bytes from 192.168.182.1: icmp_seq=40 ttl=64 time=16.1 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=41 ttl=64 time=481.6 ms
64 bytes from 192.168.182.1: icmp_seq=41 ttl=64 time=483.2 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=42 ttl=64 time=24.5 ms
64 bytes from 192.168.182.1: icmp_seq=42 ttl=64 time=26.1 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=43 ttl=64 time=7.5 ms
64 bytes from 192.168.182.1: icmp_seq=43 ttl=64 time=9.1 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=44 ttl=64 time=5.7 ms
64 bytes from 192.168.182.1: icmp_seq=44 ttl=64 time=8.3 ms (DUP!)
64 bytes from 192.168.182.1: icmp_seq=45 ttl=64 time=4.9 ms
64 bytes from 192.168.182.1: icmp_seq=45 ttl=64 time=6.5 ms (DUP!)

The distance is about 500 Meters, Signal is at -65 / so everything should be fine…

But why do i have such big delay sometimes?

any suggestions?

2

The “DUP” means that “ping” received two replies in one enquiry, something is wrong with routing table!

3

thanks - the DUP is a known “problem” wich we will solve next days…

The Problem i´m speaking about are the high ping times of 200ms and more…

Before we installed an Mikrotik AP we had an Linksys AP and there we had always ping times of <10ms

But with Mikrotik there are always sporadic pings that are very high!

Other people don´t have this problem?

4

Is the MT AP running in b/g mode? If so, try with b-only mode and see if things change. We have seen some very strange issues and bad pings with CM9 radios running in b/g mode.

5

Is the MT AP running in b/g mode? If so, try with b-only mode and see if things change. We have seen some very strange issues and bad pings with CM9 radios running in b/g mode.

What the radio that does not cause this sporadic high ping?

6

seems that there is no difference if i do b oder g mode…

With Linksys-only configuration (Broadcom chipset) G-only, WPA-AES we had stable pings for about 3-5ms
But the hardware was not good to manage for an Accesspoint…

So - i think it should be possible to have stable pings for distances <1km - but it seems not to work in Linksys/Mikrotik configuration (atm)

7

Go to wireless and check your registered clients to see the signal strength.
I recently had a client that the signal would drop from -61dB to -91dB, and when this occured ping time on other clients would go through the roof.

The signal drop created noise which affected the entire Network.

8

Go to wireless and check your registered clients to see the signal strength.
I recently had a client that the signal would drop from -61dB to -91dB, and when this occured ping time on other clients would go through the roof.

The signal drop created noise which affected the entire Network.

Do you know how to isolate the issue only for client with low signal?
Also have you encountered this issue only with Atheros Chipset based board?

9

Hi ,

no news about this tread ?

10 
[SAENTIST@MAIN] > ping 192.168.7.4
192.168.7.4 64 byte ping: ttl=128 time=8 ms
192.168.7.4 64 byte ping: ttl=128 time=4 ms
192.168.7.4 64 byte ping: ttl=128 time=2 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=7 ms
192.168.7.4 64 byte ping: ttl=128 time=4 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=4 ms
192.168.7.4 64 byte ping: ttl=128 time=499 ms
192.168.7.4 64 byte ping: ttl=128 time=163 ms
192.168.7.4 64 byte ping: ttl=128 time=2 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=54 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=2 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=2 ms
192.168.7.4 64 byte ping: ttl=128 time=256 ms
192.168.7.4 64 byte ping: ttl=128 time=536 ms
192.168.7.4 64 byte ping: ttl=128 time=452 ms
192.168.7.4 64 byte ping: ttl=128 time=729 ms
192.168.7.4 ping timeout
192.168.7.4 64 byte ping: ttl=128 time=191 ms
192.168.7.4 64 byte ping: ttl=128 time=7 ms
192.168.7.4 64 byte ping: ttl=128 time=2 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=112 ms
192.168.7.4 64 byte ping: ttl=128 time=9 ms
192.168.7.4 64 byte ping: ttl=128 time=46 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=5 ms
192.168.7.4 64 byte ping: ttl=128 time=3 ms
192.168.7.4 64 byte ping: ttl=128 time=301 ms
192.168.7.4 64 byte ping: ttl=128 time=403 ms
43 packets transmitted, 42 packets received, 2% packet loss
round-trip min/avg/max = 2/91.6/729 ms
[SAENTIST@MAIN] >

with atheros 730meters clear view max 12Mbit
but in my case, 34 neighbourhood APs min 2 per channel
on all 14 channels

11

Hi ,

some problems with my station . But i reduce the effect with put every client in G only mode .

In B only mode , i reveice the ip from dhcp server external connect to eth of mikrotik but don’t ping nothing !!!

Bye

12

Hello,

by using another SSID the link seems to work better.
We have several Accesspoints in our area - all with the same SSID.
That helps, if one Accesspoint has power outage, or anything like this…

But it seems, that ROS has a Problem if same SSID is close to the Accesspoint?!
Channels are different…

Could this be?
If it is like this - i think it´s a problem of ROS - with other vendors we don´t have this problem…