strange Ping-times...

matthias · Mon Oct 23, 2006 6:45 pm

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?

4Hell · Mon Oct 23, 2006 10:31 pm

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

matthias · Mon Oct 23, 2006 11:24 pm

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?

jarosoup · Tue Oct 24, 2006 4:14 am

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.

maxfava · Tue Oct 24, 2006 4:56 pm

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?

matthias · Mon Oct 30, 2006 8:57 pm

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)

tgrand · Mon Oct 30, 2006 9:12 pm

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.

maxfava · Wed Nov 01, 2006 9:01 pm

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?

brasileottanta · Thu Nov 16, 2006 2:08 am

Hi ,

no news about this tread ?

111111 · Thu Nov 16, 2006 4:28 am

[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

brasileottanta · Fri Nov 17, 2006 1:12 am

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

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

matthias · Tue Mar 20, 2007 11:20 am

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

strange Ping-times...

strange Ping-times...

Who is online