Lots of possibilities....
First, you need to find a method of testing other than public web test sites
like speedtest.net and speakeasy.net. You will not be able to narrow it down
conclusively, without having control of variables on both sides of a test
path.
Second, we found www.visualware.com (myspeed.visualware.com) to be a helpful
site to gather more data, to identify link problems. Their IT staff was able
to provide us custom reports on various links stats taht were not normal for
a link. (such as grapghs of pause and loss and retransmits and such).
Third, Make sure Flow Control is set correctly on ALL ETHERNET SWITCH
devices inline. Switch to PC is supposed to be FC ON, and Switch to Switch
or Radio to Switch FC is supposed to be OFF. Sometimes this can be set
wrong on the upstream providers switch also. If set wrong, not uncommon to
get 50% degregation of speed or more.
Fourth, Make Sure Duplex is set correctly. MANY CISCO routers do NOT auto
detect correctly with other Switches. OFTEN we recommend hard setting 100mb
FDX (auto neg off) on both the Cisco and the device coonnected to the Cisco.
If this is set wrong, expect to get atleast 50% degregation of speed, and
likely worse speed in one direction.
Fifth, REMEMBER TCP AUTOMATICALLY slows itself down, if it false detects
congestion, pause, or packet loss. REMEMBER the forumla for window size
times latency that equal max transfer rate possible. That means... a 100mb
link with 5ms accross town might do 95mbps, but 100mb link across USA at
70ms might do 5-10mbps. When running TCP at standard Ethernet 1500 byte
packets, you will be harmed by ETHERNET distance (latency) TCP slow down.
Also, Window size issupposed to auto adjust with Windows in most cases, but
it always doesn't. So when runing a test, its important to recogbnize
whether the correct window size gets adjusted during the test. (Inold dats
64kb window was the largest, but now PCs can multiple that by another
number, so window size can be much higher. 64kb x X=widnows size. I can
remember the max but its in the > 700kb range I think.
Anyway two things come out of that...
A) USe a low latency path for your test, to test your circuit, otehrwise you
are testing the Internet transit path.
B) Use a UDP testing tool, to verify whether the capacity is truly there or
not, so TCP slowdown (nagel augorythm?) is bypassed.
IF UDP can do full capacity, then you know its not a capacity issue,
but instead of link quality issue.
C) USe a TCP multiple PArallel stream tests. For example, if you get qty 10
of 10mbps streams it means you have 100mbps of cpaacity, even if teh top
speed you can achieve individually is 10mbps. Again, if the combined speed
of multiple tests is a greater value than the speed of a single stream test,
again, you likely have a link quality issue.
Sixth, IPERF JPERF is your friend. It will help you get the data that you
need. Its supports TCP/UDP/PARALLEL streams/MULTIPLE WINDOW SIZE. Try and
talk your upstream into deploying a Iperf Server. Many carruiers are
starting to standardize on it, for testing ONNet Ethernet circuits.
Seventh- Do NOT trust Mikrotik routing to be able to deliver full 100mbps
speeds. Dependong on your routing configuration, you can get huge limits. In
some cases we've seen the Mikrotik result in speeds as low as 10-15mbps max
transfer when on a 100mbps link, but then a change in routing config allowed
us to get almost 80mbps.
Eighth- Dont tryust your laptops to test full speed just because it has a
Gigbit port. Laptop chipsets can cause delays. Sometimes its a good idea to
test a secnd laptop to see if you get the same results. When its a problem
it usually has something to do with NIC buffers and such, where it may be
effected only in one direction. For example, not enough receive or transmit
buffers. Or poor NIC drivers unable to do DMA transfers and stuff like that.
NINETH, AFter you test yout test tools then you can test your links.
Remember... PAcket loss and delay is accumlative over the whole path. And in
aggregate it may have a worse result. For example, Lets say we have two
Links A and B. If link A has packetloss of 1% and linkB has packetloss of
1%, in combination togeather, the loss might not be 2%. It might be much
worse like 5% in combination. The same thing applies to speed. If link A
tests 50mbps, and linkB tests 50mbps, does NOT MEAN that a PATH COMPRISING
Link A and B in combination will yield 50mbps. The reason is that the loss
can be accumulative accross the agregated path, and exceed some threshold,
that tells TCP's nagel algorythm to slow down. The TCP automatic congestion
control and slow down will be the primary cause of link slow down. Remember
TCP was designed to think that packet loss and delay is caused by
congestion, so if you slow transfers down, the packetloss and delay will go
away, so it is programed to keep slowing down until it is gone. With
Wireless networks, we all know that that is not what happens. If there is
packet loss, it is likely that that percentage of packetloss will be there
regardless of the transmission rate. Also, 802.11A adaptive modulation
changes can inject some delays that can sometime effect transmit speed with
TCP. This is another reasons sometimes Wifi links perform best with the
802.11A radio configured to minimize modulation changes, or hard set to the
best modulation, the highest that does not ever auto adapt out of.
In most case, when an upstream sells you a 100mbps link, it is usually a
100mbps link. There is a bigger chance your testing environment is flawed,
or somewhere in the testing path, or in MULTIPLE aread across the testing
path, there are very small quality (packet loss and delay) issues that in
aggregate slow down TCPIP. In many cases it does not have to be fixed,
depending on what services you typically sell. For example, if you onl;y
sell up to 10mbps speeds, it doesn't really matter if you can test up to
100mbps in one stream, all that matters is taht your custoemrs can test up
to 10mbps, and that you can have 10 customers testing at once successfully,
which will be able to occur if the cpacaity is there, regardless of the
quality.
Lastly, if you are having trouble finding quality issues, you may need to
packet sniff at layer2 and see what you see. If you see retransmissions
alot, or to many acks, it can be a sign of problems on that link.
When testing at speeds above 100mbps, dont trust 1 tool. Use multiple tools
until you are certain that you ahve accurate data.
LAstly again, You must test bypassing your network. Sorta like a laptop
direct to teh circuit. But dont assume that that test will replicate how the
circuit will perform when connecting to your router. The reason is Duplex
mismatches, window size autoadjusts, flow control settings and stuff like
that, might have to be set differently on the upstream provider side
dependant on which type of device that you plug into the circuit. So be
aware of all that, when testing.
Good luck with it.
Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband
----- Original Message -----
From: "Forbes Mercy" <[email protected]>
To: "WISPA General List" <[email protected]>
Sent: Monday, October 25, 2010 4:37 PM
Subject: [WISPA] Can't get my 100MB
>I just took delivery on a 100MB Fiber connection from Charter, we're
> perplexed at the variable speed tests we are getting. Charter's varies
> from 25 to 50MB down, speedtest.net goes to about 20-25MB down and 30
> up, speakeasy doesn't go above 20MB. Charter says the cap is off on our
> 100MB so it should be showing that.
>
> The anatomy of our network is fiber to our head-end, goes to a Charter
> switch then to our Cisco 2811, then to a gig netgear switch. We're
> doing our speed tests on a standard browser (Firefox) in a Windows 2003
> box that has a 10/100 ethernet (about 8 feet) to the gig switch. I'm
> debating if the 2811 is hefty enough to handle the 100MB, any ideas?
>
> Thanks,
> Forbes
>
>
> --------------------------------------------------------------------------------
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> --------------------------------------------------------------------------------
>
> WISPA Wireless List: [email protected]
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
--------------------------------------------------------------------------------
WISPA Wants You! Join today!
http://signup.wispa.org/
--------------------------------------------------------------------------------
WISPA Wireless List: [email protected]
Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless
Archives: http://lists.wispa.org/pipermail/wireless/
