Community discussions

MikroTik App
 
kipmckay
newbie
Topic Author
Posts: 26
Joined: Tue Sep 13, 2005 9:51 pm

Bridged AP and slow ping times

Thu Feb 16, 2006 5:01 am

I have setup a rb500 as an AP Bridge. I have the Wlan1 and ether1 bridged. One pc can connect but the ping times very from 4ms to 22ms. Once I bring other machines on the ping times jump to 1200ms or more. I bypassed the MT and the pings are 3ms.

It appears that the MT bridge is creating issues. Where do I start? or what is the correct way to do this? I am using the latest MT software.


Thanks
Kip
 
User avatar
acim
Member
Member
Posts: 415
Joined: Mon Sep 12, 2005 12:26 am
Location: Serbia
Contact:

Mon Feb 20, 2006 1:46 am

I have similar situation, PC with SR2 and integrated ethernet card bridged and everything works fine, clients ping the AP with 1-2ms. This is maybe hardware issue. What wireless card have you used? Does it work fine in non-bridged mode? Is ping the same slow through the ethernet connetion?

And what do you mean you bypassed the MT? You put some other AP or what?
 
YappaDappa
Frequent Visitor
Frequent Visitor
Posts: 70
Joined: Mon Dec 12, 2005 12:34 pm

Wed Feb 22, 2006 6:36 am

I am having this problem too. I am currently piping 3Mb to about 45 clients. All are rate limited. I rarely hit >70% bandwidth consumption. Problem is this: ping times and speeds are all over the map. In one speed test I could post a 214, the next a 600. Ping times can go from 3ms to 300, or no reply. Any suggestions
 
wildbill442
Forum Guru
Forum Guru
Posts: 1055
Joined: Wed Dec 08, 2004 7:29 am
Location: Sacramento, CA

Wed Feb 22, 2006 2:10 pm

Try routing? The following is a ping test to a RB532 w/ an SR2 card. However I am the sole wireless client on the network.
C:\Documents and Settings\Administrator>ping 10.100.1.1 -t

Pinging 10.100.1.1 with 32 bytes of data:

Reply from 10.100.1.1: bytes=32 time=3ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=6ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=3ms TTL=6
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=12ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=5ms TTL=64
Reply from 10.100.1.1: bytes=32 time=3ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=4ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=4ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=6ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=3ms TTL=64
Reply from 10.100.1.1: bytes=32 time=4ms TTL=64
Reply from 10.100.1.1: bytes=32 time=3ms TTL=64
Reply from 10.100.1.1: bytes=32 time=4ms TTL=64
Reply from 10.100.1.1: bytes=32 time=3ms TTL=64
Reply from 10.100.1.1: bytes=32 time=5ms TTL=64
Reply from 10.100.1.1: bytes=32 time=5ms TTL=64
Reply from 10.100.1.1: bytes=32 time=3ms TTL=64
Reply from 10.100.1.1: bytes=32 time=6ms TTL=64
Reply from 10.100.1.1: bytes=32 time=4ms TTL=64
Reply from 10.100.1.1: bytes=32 time=4ms TTL=64
Reply from 10.100.1.1: bytes=32 time=5ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=3ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=3ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64
Reply from 10.100.1.1: bytes=32 time=2ms TTL=64

Ping statistics for 10.100.1.1:
    Packets: Sent = 56, Received = 56, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 12ms, Average = 2ms
Also Yappa,

3Mb is your backhaul? or does each individual user have a 3Mbps queue? 802.11b w/ a connection @ 11mbps has a total throughput of 5.5-6mbps. There are other factors that can effect latency... How is the rest of the network designed is it a Flat topology, bridged? If so depending on the amount of users you have on your network broadcast traffic will kill your ping times especially when going through a half duplex wireless AP. You only want legitimate traffic destined for users on that subnet traversing your wireless AP.

Also 802.11 uses CSMA/CA so the more users you put on a wireless segment the more likely there are going to be collisions leading to retransmissions and back off algorithms, causing increased latency, or spikes.

Another thing to look into, check the p/s (packets per second) on the wireless AP when utilization is low.. That will give you an idea of how much broadcast traffic is being sent over the network, on bridged networks I've seen with 200+ users there was a consistant 130-200p/s going through the network, even when no substantial data was being transmitted/recieved.

This is where bridging negatively effects wireless performance.

Just some things to think about...
Last edited by wildbill442 on Thu Feb 23, 2006 4:20 am, edited 2 times in total.
 
kipmckay
newbie
Topic Author
Posts: 26
Joined: Tue Sep 13, 2005 9:51 pm

Thu Feb 23, 2006 3:31 am

than-you all for the replys. It is definately giving me some items to look into. With a single pc my pings are very simular to yours. Its when I started adding that it becomes an issue. I am thinking I have to many high end users on this sector. So I may split it up into 2 sectors. In the mean time I am going to try and throttle them back to 3 meg max usage. This should help my 8 meg backbone and allow me to do some more research.

I am having some p2p filtering issues. does any one have an example that will help me limit p2p traffic to 512k and max 3 connections per user? Or is 3 to low?

Kip
I'm going to MUM ya...
 
YappaDappa
Frequent Visitor
Frequent Visitor
Posts: 70
Joined: Mon Dec 12, 2005 12:34 pm

Thu Feb 23, 2006 4:57 am

Hey, thanks Bill,

Here's a little more info:
NxT1 (3Mbit) backhaul
each user limited to 256k, with 30 sec 1M burst
P2P limited to 64/128 from 7AM-midnight, then opens to full
I am using a 5.7 20Mbit motorola backhaul
I use Senao CB3+ to connect to the MT bridged

So, what can be done to reduce network broadcast traffic?
Do you use firewall rules to maintain "legit traffic" can you give an example?
How can we reduce spikes?
I couldn't get consistant taffic monitoring stats. I'm going to try again around 2AM tonight

OH KIP, here's where someone helped me make P2P queues:
http://forum.mikrotik.com//viewtopic.php?t=6732

Who is online

Users browsing this forum: infabo and 5 guests