How to figure out if low WISP speeds are due to traffic shaping orsomething 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
http://www.dslreports.com/stest --> 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?

On Wed, 15 Feb 2012 08:07:04 +0000 (UTC), Chuck Banshee
<chuckbanshee@private.com> wrote:

>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.

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.

>The WISP is responsive but only when I call him.

Do you want him to call you instead?

>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).

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:
<http://www.metageek.net>
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.

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

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.
--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

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.

On Wed, 15 Feb 2012 15:05:38 -0800, miso <miso@sushi.com> wrote:

>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.

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:
<http://www.cwnp.com/bbpress/topic.php?id=836>
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.

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

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.

>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.

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.

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558
# http://802.11junk.com jeffl@cruzio.com
# http://www.LearnByDestroying.com AE6KS

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.

In <s21pj79p4p3157mnhv6b3nr3clrh2p02cu@4ax.com> Jeff Liebermann <jeffl@cruzio.com> writes:

>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.

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.


--
__________________________________________________ ___
Knowledge may be power, but communications is the key
dannyb@panix.com
[to foil spammers, my address has been double rot-13 encoded]

On Thu, 16 Feb 2012 15:14:58 +0000 (UTC), danny burstein
<dannyb@panix.com> wrote:

>In <s21pj79p4p3157mnhv6b3nr3clrh2p02cu@4ax.com> Jeff Liebermann <jeffl@cruzio.com> writes:
>
>>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.
>
>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.

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:
<http://books.google.com/books?id=87m0xveYMvQC&pg=PA294&lpg=PA294>
Microwave oven interference:
<http://archive.devx.com/wireless/articles/bluetooth/whitepapers/1a6900.pdf>


[1] My guess because I'm too lazy to look it up in the O'Reilly
802.11 book.
--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558