My provider and me have stablized the jitter and rssi. Unfortunately my ms and packet loss still jump around. I have no idea what’s going on. My general ms ranges from 9-200 with jumps up to 3000+ms with some total loss of packets. One day i had 33% packet loss. Any ideas of what could cause this. I have been using neotrace which pings the server every 5 seconds.
Numbers wise i should have a better connection then dsl, cable, etc but a game i play wow. I consistently have horrible game play as soon as multipule things happen in game sending me up passed 1000ms often to 3000+ ms for 10-20 secs or more. I am really confused.
I use to have some stable game play at night 1am-6am usually stablizing at average 300 ms with few jumps in ms but now that is gone as i have regular lag spikes.
That packet loss is unacceptable.
Do you know if the radio is configured in 1x/2x and software/hardware mode?
What is the jitter/rssi stabilized to?
I would suggest some traceroutes to see where the slow downs are occurring, either internal or external…
Keep in mind that if the provider is running a bridged network that you will not see where the losses are (if it is localized to the WISP network) because switches and hubs do not reply to traceroutes.
You will however see the last hop (edge router) on the network and if the times to that device are obnoxious it may be a busy router, or you indeed have issues somewhere in the WISP core.
I can almost guarantee this is due to a poor wireless link, or interference.
just so you know 33% was one day my regular packet loss sits around 10% and fluxuates up and down to day it’s sitting at about 16%.
my jitter sits about 2 and my rssi sits about 675 roughly.
traceroute is similar to neotrace. The difference is traceroute runs over whatever amount you ping the ip. Neotrace does a ping ever 5 secs and can run as long as you like. I’ve been running it for over an hour now and is awsome for long term ping rate. It only shows my computer ip and the tower ip as this is my only connection concern.
When my MS to the tower jumps then my game MS jumps. generally as a rule. 90% of my ms ping to the game cames from my connection. If i’m sitting at 700ms in game my connection is sitting at 600+ to my tower.
Ok so what do they have to fix to get this crap in gear. I mean i’m suffering here. what do we have to do to get this working. As i can’t see all the jumps in the system. I can only recommend some actions. They updated some stuff on thier tower so i’m limited in what i can do if anything.
It’s interference between you and the tower. Either there is another Canopy AP in the vicinity that is not in sync with the AP you are on, or there is another 900MHz RF source.
Anything over 2% packet loss is a problem.
I know there’s another company with similar to same set up on the mountain. Is there a way to get around this or? The reason i know this is a friend who lives 1-2 miles away has his wireless internet with them.
anyway to fix this?
A few steps you could take.
1. If you know the address of your SM. Run a ping test from your computer to the SM (large packets). At the command propt type:
ping ip of sm -t -l 1494
If the pings are good there then it’s not a cable issue. at your place.
2. If you know the IP address of the AP you are linked to, set up a ping from your computer to the AP. This will test your wireless
ping ip of AP -t -l 1494
If the pings are all over the place (20-1000ms) then you have a wireless problem.
Oh i tell tell you right now it’s a wireless problem. I’ve used neotrace even before this 1000ms lateny problem i’ve had it bounce from 0-3000 and up and down like a yo-yo. It’s good to have more confirmation though.
The question isn’t that it’s a bad connection, it’s where that bad connection is occuring. Whether it’s your PC to the SM, the SM to the AP, the AP to the router/switch. Or it could be on one of the BH’s going to their POP site.
Ok i’ll be testing the sm to my computer. I’m just curious if 50 feet of line to my sm is too much to weaken the signal or something but the input from the ap is totally fine though last i looked.
Try ping from Linux machine. From time to time we have problem with incorrect packet order with one of about 2500 Canopy SM connecten in our network. Reboot of Canopy SM is always solution of problem.
We unsuccessfully have tried to resovle the problem with US or UK Motorola Canopy Support.
64 bytes from x.x.x.x: icmp_seq=0 ttl=62 time=17.3 ms
64 bytes from x.x.x.x: icmp_seq=1 ttl=62 time=8.80 ms
64 bytes from x.x.x.x: icmp_seq=3 ttl=62 time=7.27 ms
64 bytes from x.x.x.x: icmp_seq=4 ttl=62 time=10.3 ms
64 bytes from x.x.x.x: icmp_seq=5 ttl=62 time=8.26 ms
64 bytes from x.x.x.x: icmp_seq=6 ttl=62 time=13.9 ms
64 bytes from x.x.x.x: icmp_seq=7 ttl=62 time=9.69 ms
64 bytes from x.x.x.x: icmp_seq=8 ttl=62 time=10.2 ms
64 bytes from x.x.x.x: icmp_seq=9 ttl=62 time=8.40 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=62 time=1431 ms
64 bytes from x.x.x.x: icmp_seq=11 ttl=62 time=6.08 ms
64 bytes from x.x.x.x: icmp_seq=12 ttl=62 time=4.70 ms
64 bytes from x.x.x.x: icmp_seq=13 ttl=62 time=22.4 ms
64 bytes from x.x.x.x: icmp_seq=14 ttl=62 time=10.0 ms
64 bytes from x.x.x.x: icmp_seq=15 ttl=62 time=19.6 ms
64 bytes from x.x.x.x: icmp_seq=16 ttl=62 time=7.46 ms
64 bytes from x.x.x.x: icmp_seq=17 ttl=62 time=11.1 ms
64 bytes from x.x.x.x: icmp_seq=10 ttl=62 time=1421 ms
64 bytes from x.x.x.x: icmp_seq=19 ttl=62 time=9.91 ms
64 bytes from x.x.x.x: icmp_seq=20 ttl=62 time=10.5 ms
64 bytes from x.x.x.x: icmp_seq=21 ttl=62 time=8.66 ms
64 bytes from x.x.x.x: icmp_seq=22 ttl=62 time=11.5 ms
64 bytes from x.x.x.x: icmp_seq=23 ttl=62 time=11.9 ms
64 bytes from x.x.x.x: icmp_seq=24 ttl=62 time=15.8 ms
64 bytes from x.x.x.x: icmp_seq=25 ttl=62 time=9.01 ms
I did the old power off power on. This did not fix any of my spikes in latency. By the way I game so i feel every spike in latency especailly when they happen about every minute or two and go up to about 2000-3000ms.
Reply from 204.244.94.1: bytes=64 time=39ms TTL=255
Reply from 204.244.94.1: bytes=64 time=2424ms TTL=255
Reply from 204.244.94.1: bytes=64 time=169ms TTL=255
Reply from 204.244.94.1: bytes=64 time=45ms TTL=255
Request timed out.
Request timed out.
Reply from 204.244.94.1: bytes=64 time=566ms TTL=255
Reply from 204.244.94.1: bytes=64 time=43ms TTL=255
Reply from 204.244.94.1: bytes=64 time=914ms TTL=255
Reply from 204.244.94.1: bytes=64 time=117ms TTL=255
Reply from 204.244.94.1: bytes=64 time=170ms TTL=255
Reply from 204.244.94.1: bytes=64 time=77ms TTL=255
Reply from 204.244.94.1: bytes=64 time=1371ms TTL=255
Reply from 204.244.94.1: bytes=64 time=21ms TTL=255
Reply from 204.244.94.1: bytes=64 time=2190ms TTL=255
Reply from 204.244.94.1: bytes=64 time=4ms TTL=255
Reply from 204.244.94.1: bytes=64 time=73ms TTL=255
Reply from 204.244.94.1: bytes=64 time=2328ms TTL=255
Reply from 204.244.94.1: bytes=64 time=21ms TTL=255
Reply from 204.244.94.1: bytes=64 time=357ms TTL=255
Reply from 204.244.94.1: bytes=64 time=1105ms TTL=255
Reply from 204.244.94.1: bytes=64 time=26ms TTL=255
Reply from 204.244.94.1: bytes=64 time=1018ms TTL=255
Reply from 204.244.94.1: bytes=64 time=13ms TTL=255
Reply from 204.244.94.1: bytes=64 time=127ms TTL=255
Reply from 204.244.94.1: bytes=64 time=19ms TTL=255
Reply from 204.244.94.1: bytes=64 time=15ms TTL=255
Reply from 204.244.94.1: bytes=64 time=7ms TTL=255
Reply from 204.244.94.1: bytes=64 time=186ms TTL=255
Reply from 204.244.94.1: bytes=64 time=52ms TTL=255
Reply from 204.244.94.1: bytes=64 time=22ms TTL=255
Reply from 204.244.94.1: bytes=64 time=3874ms TTL=255
Reply from 204.244.94.1: bytes=64 time=9ms TTL=255
Reply from 204.244.94.1: bytes=64 time=29ms TTL=255
Reply from 204.244.94.1: bytes=64 time=21ms TTL=255
Reply from 204.244.94.1: bytes=64 time=24ms TTL=255
Reply from 204.244.94.1: bytes=64 time=157ms TTL=255
Reply from 204.244.94.1: bytes=64 time=28ms TTL=255
Reply from 204.244.94.1: bytes=64 time=7ms TTL=255
Reply from 204.244.94.1: bytes=64 time=49ms TTL=255
Reply from 204.244.94.1: bytes=64 time=10ms TTL=255
Reply from 204.244.94.1: bytes=64 time=11ms TTL=255
Reply from 204.244.94.1: bytes=64 time=22ms TTL=255
Reply from 204.244.94.1: bytes=64 time=7ms TTL=255
Reply from 204.244.94.1: bytes=64 time=21ms TTL=255
Reply from 204.244.94.1: bytes=64 time=45ms TTL=255
Reply from 204.244.94.1: bytes=64 time=26ms TTL=255
Reply from 204.244.94.1: bytes=64 time=7ms TTL=255
Reply from 204.244.94.1: bytes=64 time=10ms TTL=255
Reply from 204.244.94.1: bytes=64 time=13ms TTL=255
is some of what’s going on.
You stated the RSSI and jitter values earlier.
675 on the RSSI?
What is the dB level on the SM side? The provider also needs to look at the dB level on the AP side.
I’d also like to ask if the link is in 2x mode (although I doubt this with an RSSI value of 675).
How far are you from the tower?
Just as an example:
I have a customer at 19.6 miles from the 900MHz AP. His dB at the AP is -75dB, with a jitter of 3. At the SM it is -75 with a jitter of 3. With that said, the RSSI value is ~1300 on both sides.
Your connection must be really in the mud for the rssi to be 675.
If I were to stop here and form an opinion…
1) Signal strengths are far too low for operation
2) Service should never have been installed
3) There might be something (trees, building, hillsides) in the way between your radio and the AP.
The provider may be able to fix the signal strength issue by putting a higher gain antenna on the SM. A higher gain antenna will not fix the issue due to hills, buildings, etc being in the way. Depending on the distance from the AP if there are trees in the way it may or may not help.
Just my opinions.
I’m trying to get the tech from the provider on these forums to answer alot of the questions and help him find out what’s going on and how to fix it.
There is no objects between me and the tower. i spent 75 dollars getting a stand to put it on the peak of my house so that i would have no issues with line of sight.
For the other questions my provider tech will come on here and answer hopefuly.
I believe i’m 12 miles from the mountain but don’t quote me on that.
12 miles and absolutely NOTHING in the way?
It is possible you are on the outer edge of the antenna radiation lobe.
Really only the provider can answer that question.
What is the IP your are pinging? 204.244.94.1?