How to figure out if low WISP speeds are due to traffic shaping or something else

I pay for a certain number of Mbps from my new WISP provider in the Santa Cruz mountains yet I get about half that most of the time. A quarter of the time I get even less than half that. The WISP is responsive but only when I call him.

Then the speeds suddenly jump up to near the advertised speeds.

But, a few days later (sometimes only a day later), they drop down back to lousy. I call him. They jump back up. A few days later, they drop back down to lousy.

I can tell all this simply by using the speed test web sites, e.g., nitro.ucsc.edu --> Point to UC Santa Cruz speedtest.net --> Point to San Jose server speakeasy.net/speedtest --> Point to San Francisco server

formatting link
--> Point to San Francisco server etc.

I 'think' it's all due to the traffic shaping at the access point (the WISP can't traffic shape at my radio/antenna because it's my equipment, not his so he doesn't have the login).

But HOW can I tell WHERE the speed bottleneck is occurring? (it could be my equipment, his traffic shaping, his equipment, or something else altogether).

What tests can I run to pinpoint the reason the speeds are so bad at the times they're so bad?

Reply to
Chuck Banshee
Loading thread data ...

On your way into the valley, you'll notice that there is a freeway called Highway 17. It's a fair analogy of wi-fi, a shared highway. If the freeway were empty, I'm sure you could probably drive at the maximum speed your vehicle offers. However, there are other users on Hwy 17. As more and more of them use the highway, the speeds drop.

However, the analogy doesn't quite work. Freeway drivers can see each other and merge into traffic in an orderly manner. Wi-Fi users are essentially blind, and cannot synchronize with other traffic on the highway. It's literally like driving blind. When you crash into something (packet collision), you back off, and try again. It's the collison avoidance part of CSMA/CA.

When you're at a high altitude, you pickup 2.4GHz junk from everywhere. One leaky microwave oven and everything within miles goes dead. There are literally dozens of other WISP networks, including one that I'm working on which you'll probably see (HSMM-MESH) from your location. The higher you are, the more you'll hear.

However, it isn't just your end that might be a problem. The WISP central access point might have an omni antenna and/or a better view of the world. Interference from other users at the WISP end might be causing problems.

Do you want him to call you instead?

Well, pretend you're driving down Hwy 17 blindfolded. You can tell that you're not going very fast but you have no clue why. What do you do? Well, you try to measure the other traffic on the freeway, which should give you a fair idea of what speed you could expect. Lots of other vehicles means plenty of collisions and slow speeds.

Start here:

InSSIDer might be a good start without spending any money. The problem is that it shows only wi-fi networks, and does not show non-wi-fi sources of interference (RF video links, telemetry, etc). However, to do a thorough job, you really need a real spectrum analyzer and proper antenna (big dish). Interpreting the results are tricky.

Incidentally, the last time I did some sniffing for a customer (last week), the interference source was one of the new and disgusting 40MHz wide MIMO routers, that hogs the entire 2.4GHz band. The neighbors were streaming video with one, over a distance of about 3ft, but clobbering most of the neighborhood because the access point was located in a window.

Ping. Err... fping. Ping the IP address of the WISP wireless access point. That limits the results to only you and the WISP. Use fping instead of Windoze ping so you can get sequence numbers. Linux ping will also work. If it looks like this: C:\ZIP\fping>fping 192.168.1.1 -c Pinging 192.168.1.1 with 32 bytes of data every 1000 ms: Reply[1] from 192.168.1.1: bytes=32 time=1.1 ms TTL=64 Reply[2] from 192.168.1.1: bytes=32 time=1.1 ms TTL=64 Reply[3] from 192.168.1.1: bytes=32 time=1.1 ms TTL=64 Reply[4] from 192.168.1.1: bytes=32 time=1.0 ms TTL=64 Reply[5] from 192.168.1.1: bytes=32 time=1.1 ms TTL=64 Reply[6] from 192.168.1.1: bytes=32 time=1.1 ms TTL=64 where the latency doesn't change much and there are no timeouts or lost packets, you're doing fine.

However, if it looks like this: C:\ZIP\fping>fping 192.168.56.103 -c Reply[1] from 192.168.56.103: bytes=32 time=155 ms TTL=53 Reply[2] from 192.168.56.103: bytes=32 time=5.5 ms TTL=53 Reply[3] from 192.168.56.103: bytes=32 time=15.1 ms TTL=53 Reply[4] from 192.168.56.103: bytes=32 time=61.9 ms TTL=53 Reply[5] from 192.168.56.103: bytes=32 time=5.8 ms TTL=53 Reply[6] from 192.168.56.103: bytes=32 time=177 ms TTL=53 Reply[7] from 192.168.56.103: request timed out Reply[8] from 192.168.56.103: bytes=32 time=16.7 ms TTL=53 you have a problem. From the latency, the minimum time is probably the ideal latency. In this example, it would be about 5msec. Higher number indicate retransmissions. The more retransmission, the slower your downloads will appear.

You can also monitor the connection speed of the wireless. It can be different in each direction. If the access point is set to variable speeds, slower speeds indicate interference or a bad path.

Phone call... gone.

Reply to
Jeff Liebermann

I'm drawing a blank on the term, but isn't there a parameter to request longer packets? The first few search results are talking around the notion of packet length, but not indicating how to set it.

My point being if you ask for long packets, maybe you can hog the network more.

The alternative to wisp is satellite, which is far worse due to latency. I like satellite internet. It is a good source of free dishes when the owner fecal matter cans the gear. I haven't found a good use for the BUC that comes with them. I just scrap the LNB affair and put on a new one.

Reply to
miso

Bigger packets in ping or in 802.11? They're different.

802.11 is nothing more than ethernet encapsulated inside 802.11 frames. For the details as to packet/frame size, see the 2nd posting:

If you try to send smaller than 1500 byte ethernet packets, 802.11 will adjust the frame size to either aggregate, or fragment the contents. You can can control the maximum frame size in the advanced wireless setting on your wireless router. One reason you might want smaller frames is to deal with repetative impulse interference issues. Smaller frames have a better chance of getting past interference, than larger frames. Thruput will suffer with smaller frames, but at least some data will make it through the interference.

Yep. The idea behind using small packets is to not bring the network to a standstill while you're testing. Ping offers no control over the size of the packet. For fping, it's fping target_ip_address -c -s data_size_bytes

65500 is the largest allowed value. Note that this does not magically create jumbo frames.

Yeah. I know how it works. I save the old Wild_Blue or HughesNet systems for the next desperate owner. We have some local areas that can't get DSL, cable, or WISP service, leaving satellite as the only suitable last resort. The recent contract settlement with Comcast requires Comcast to provide service into some of these areas. I expect to see many more dishes and radios at the local recycler shortly.

Reply to
Jeff Liebermann

I meant longer packets for 802.11 use, not ping. Of course, if the connection is flaky, you may just end up getting more packets retransmitted.

The only way I see the dumped satellite internet gear is from the "mountain folk" that have jobs in the flats. These dishes end up in the free section of Craigslist. You can do passable FTA on those elliptical dishes. You need to replace the LNB holder, and hacksaw a bit to get it to fit. But the dishes I've seen are nice Channel Master (Andrews) molded fiberglass.

I've never tried to do wifi over the dish, but that could be an alternative for our person with the WISP issues. In theory, a biquad can paint the dish.

Viasat supposed is going to have a next generation high speed internet out this year. Still it is hard to fight the speed of light. I know someone who has satellite in his motorhome. He skypes his wife, but you have to use the word "over" so the comms are only one way.

Reply to
miso

Methinks someone or another (hi, Jeff) pointed out that this is (was? [a]) exactly the technique used by Apple for their "interference robustness" with their Airports...

[a] not sure if it's still a functional option.
Reply to
danny burstein

It's part of the 802.11 spec. I'm too lazy to lookup the chapter and verse. If the access point is wi-fi compliant, the feature will be found in the wireless router or access point "advanced" wireless settings. Over the years, I've experimented with the fragmentation (and CTS/RTS flow control) mechanism trying to determine if they do anything useful. They don't. The problems with fragmentation is that it's a performance hit and only works with certain types of interference, such as impulse noise and 60/120Hz microwave oven bursts. CTS/RTS flow is problematic because of the "hidden transmitter" problem, where the client radio cannot hear the interfering radio, but the access point can hear both.

In my never humble opinion, slowing down the wireless speed, and fragmenting packets, is not a good solution for interference problem. What I do is INCREASE the connection speed to some higher fixed value. The logic is that it takes less air time to send a high speed packet, than it does to send a low speed packet. I think a 1Mbit/sec packet is about 125msec long, while the same amount of data at 54Mbits/sec is about 2.5msec[1]. In a noise infested environment, a 125msec long packet is sure to get clobbered by a noise burst. A 2.5Msec packet is much less likely if it can sneak in between the bursts.

Some detail:

Microwave oven interference:

[1] My guess because I'm too lazy to look it up in the O'Reilly 802.11 book.
Reply to
Jeff Liebermann

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.