Re: [smartBridges] Bringing up the latency issue again new findings..

[Ian Ellison]

Is the Canopy AP/CPE being used solely for a backhaul?   If so, you would have been way better off using Canopys backhaul radios.  What is managing the sync timing on the Canopy's?  The AP is creating its own sync or what?   I have a multi-hop Canopy backhaul, 1 leg is 14 miles, the short leg is 3 miles, with a Cluster Management Module in the middle.  This unit has worked flawlessly for me, and I dont experience the 20ms latency at all.  I could produce the same statistics as below all day and all night long with this configuration.  A little more info?  Good luck. PING 169.254.1.4 (169.254.1.4) from 204.119.20.3 : 56(84) bytes of data. 64 bytes from 169.254.1.4: icmp_seq=0 ttl=254 time=4.084 msec 64 bytes from 169.254.1.4: icmp_seq=1 ttl=254 time=3.781 msec 64 bytes from 169.254.1.4: icmp_seq=2 ttl=254 time=3.764 msec 64 bytes from 169.254.1.4: icmp_seq=3 ttl=254 time=6.204 msec 64 bytes from 169.254.1.4: icmp_seq=4 ttl=254 time=6.028 msec 64 bytes from 169.254.1.4: icmp_seq=5 ttl=254 time=6.005 msec 64 bytes from 169.254.1.4: icmp_seq=6 ttl=254 time=5.991 msec 64 bytes from 169.254.1.4: icmp_seq=7 ttl=254 time=5.816 msec 64 bytes from 169.254.1.4: icmp_seq=8 ttl=254 time=4.563 msec 64 bytes from 169.254.1.4: icmp_seq=9 ttl=254 time=5.613 msec 64 bytes from 169.254.1.4: icmp_seq=10 ttl=254 time=4.332 msec 64 bytes from 169.254.1.4: icmp_seq=11 ttl=254 time=5.449 msec 64 bytes from 169.254.1.4: icmp_seq=12 ttl=254 time=5.267 msec 64 bytes from 169.254.1.4: icmp_seq=13 ttl=254 time=3.953 msec 64 bytes from 169.254.1.4: icmp_seq=14 ttl=254 time=5.090 msec 64 bytes from 169.254.1.4: icmp_seq=15 ttl=254 time=5.016 msec 64 bytes from 169.254.1.4: icmp_seq=16 ttl=254 time=4.956 msec 64 bytes from 169.254.1.4: icmp_seq=17 ttl=254 time=4.775 msec 64 bytes from 169.254.1.4: icmp_seq=18 ttl=254 time=4.295 msec 64 bytes from 169.254.1.4: icmp_seq=19 ttl=254 time=4.637 msec 64 bytes from 169.254.1.4: icmp_seq=20 ttl=254 time=4.614 msec 64 bytes from 169.254.1.4: icmp_seq=21 ttl=254 time=4.474 msec 64 bytes from 169.254.1.4: icmp_seq=22 ttl=254 time=4.415 msec --- 169.254.1.4 ping statistics --- 23 packets transmitted, 23 packets received, 0% packet loss round-trip min/avg/max/mdev = 3.764/4.918/6.204/0.745 ms Blazen Wireless wrote: Okay as you all know I have been having latency issues when one or two people get on pings go thru the roof 100-600ms..   We ran a test from my partners house on wireless. He faces are furthest tower which gets its backhaul from our main tower 8 miles away. This remote tower he faces has 3 clients on it right now and it has two APPO's one for backhaul (in client bridge mode) and the other in Access point mode.   So we set up a constant ping to each radio in the chain all the way to the main tower an noc.   1. Before starting the test we see <10 ms to main tower to the noc about 30 -40 ( all cause the automatic 20ms+ latency the Motorola adds)   2. We start a bandwidth test and every radio we ping stays at <10ms all the way to the main tower which is good!!!   3. Now here is where we see the problem we ping the radio at the tower that serves as the backhaul ( Motorola client unit) the pings go way up to over 500ms at times????   anyone have any ides? all three radios at the main tower are plugged into a dlink 5 port switch that has been working great so I thought. I have the Motorola unit forced at 10 meg 1/2 duplex. I tried setting it to full and 100 and no difference? I think I have found where the problem lies just not sure why?   Any help would be appreciated as to what else I can try??   Here is a link to a rough pic of what I have set up http://www.blazenwireless.com/system         Martin & Steve Blazen Wireless 909-326-5003 www.blazenwireless.com