I'm debugging slow speeds with my WISP connection; so I just ran the new google Network Diagnostic Tool:
formatting link
One output statement from Google NDT I don't understand is: "Network congestion may be limiting the connection."
Does this mean other (i.e., not mine) traffic on my network? Does it mean other computers' traffic on my network? (i.e., my household) Does it mean other people's traffic within the WISP private network? Does it mean a background program is running on my PC?
Q: What does that output statement indicate? Network congestion may be limiting the connection.
Note: I also get that same statement from the UC Santa Cruz NDT server: nitro.ucsc.edu
I can't imagine much network traffic at 5:41AM. That makes me wonder about Jeff microwave oven theory, since you are doing this at what is known as "Oh dark thirty" or "stupid O clock."
Incidentally, I get a message from that diagnostic that about half the time the receiver buffer is causing congestion on my system. There is a program called TCP-Z to adjust the buffer size, but I can't get win 7 to run it due to a certificate issue. Spybot says it is virus free. MS Security essentials says it is hacker software. Well, doh! Of course it is.
Note with Kismet, you can see if other people using the WISP. What you want to do is determine what channel you are using, then "park" on that channel. [I don't have kismet running nearby, so you will have to RTFM. The idea is you don't want Kismet to hop from channel to channel.] This may require running wireshark as well.
My guess is Jeff will read this and do a better reply on detecting if the channel is busy since this is probably fresher in his memory.
Come to think of it, a packet sniffer is mandatory here since there are two scenarios (at least). One, there is some other traffic to your wisp. Two, there is some unrelated wifi traffic on the same frequency. In the boonies, it wouldn't be all that unexpected for somebody to hook up a point to point link (bridge) to share internet service with a buddy that can't see the wisp. So you will have to examine the addresses of the packets. Be sure not to read any clear text.
You are going to be f-ing brilliant when this is all done!
Not today. Jeff has to read and run in order to save the world from broken computahs, bad planning, and inept executive decision processes. Try this:
Ubiquiti also has some kind of scanning tool in their utility collection.
As for congestion management, all sane WISP's use some form of traffic shaping or one user will end up hogging the entire system. Assuming the backhaul is oversubscribed by the usual 10:1, it's likely that whatever the WISP is using for a backhaul might be the limiting factor. My previous rant emphasized that testing the local wireless link has to be done first, or none of the subsquent tests will make any sense. High packet loss and retransmissions on the wireless link will hide any packet loss along the backhaul.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.