|Home||Reviews||Tools||Forums||FAQs||Find Service||ISP News||Maps||About|
how-to block ads
AT&T Speedtest and others are great for measuring the average or aggregate throughput speed over a period of time. NetMeter is good for showing the big picture of real-time, streaming speed changes averaged over 10-second intervals.
To measure throughput speeds on the individual TCP/IP packets, to analyse just how those speeds change over time, and to try to infer what might be causing slowdowns, you need to use the Wireshark program (formerly know as Ethereal and WinPCap). Wireshark is the world's foremost network protocol analyzer and can do much more that just throughput speed measurements, but the scope of this FAQ is limited to this small aspect of the program's capabilities.
1. Download and install the latest build for Wireshark and WinPCap (WinPCap, a helper program, is now built into the Wireshark download and installs as part of the whole package). If you have an older Ethereal and WinPCap version, the procedures presented in this FAQ will probably work, but with the program improvements to this network protocol analyzer, you should really consider upgrading.
2. Then you must decide which network interface you will use to capture packets. Select the Capture choice from the menu bar and then choose Interfaces. If you are lucky, you have a limited number of choices. This FAQ is intended for tests using wired connections, but wireless connections may also be tested. If you are confused by which one of multiple choices in the Wireshark: Capture Interfaces window to use, normally the interface your computer is connected to will be showing live packet traffic. Also the Details buttons can help you decide which NIC to use.
3. Once you decide on the NIC, you can set it to be the default NIC for the program by selecting it in the Capture -> Options -> Interface: choice box.
4. Start a packet capture, by selecting Capture -> Start which launches a packet capture window that shows real-time, capture activity on various packet types. This window can be minimized after it is launched.
5. Then while the packet capture window is running, you must start a download or upload from or to a high speed site. One good site to test with is the Optimum Online 16 MB FTP download test.
6. Once the download or upload test is finished, terminate the packet capture window with the Stop button, and Wireshark will display a listing of all packets captured.
7. If you have captured packets from an FTP download or upload, scroll through the packet list until you find a line that has FTP-DATA listed under the Protocol column and highlight it by single clicking on the line.
8. Then from the menu bar select Statistics -> TCP Stream Graph -> Throughput graph to generate a graph of the data's throughput speeds. There is a separate graph control window that will be opened behind the graph. Each individual "+" mark is a single packet of data. Note: The throughput speeds are measured in bytes/second.
9. Wireshark doesn't have a built in image capture function to export the graphs to a file. You must either use an image capture program or hit the CTRL-PRT SCR buttons simultaneously. Then open the Paint program, paste the screen image into it, and use Paint's cut-and-paste to edit the image to just a shot of the throughput graph inside the window borders. Whichever method you use, save the image in PNG format for an attachment to a thread.
10. Save the Wireshark data file. Other tests can be run on the data at a later time.
Some examples of Wireshark throughput graphs collected on Elite (6016/768) speed lines with various conditions.
1. This is a normal test with no throughput problems. This level of "fuzziness" of the throughput speed distribution is normal and may reflect slight timing inaccuracies in the computer's clock. If the graph is zoomed in, the "fuzziness" will resolve into several jittery speed bands.
2. A packet delay (RTT increase) over the internet backbone from the OOL FTP speed test site interrupted the transmission. The resumption of the normal RTT caused the packets to have the characteristic curved ramp (recovery curve) back up to the full speed baseline after the sharp speed dip.
3. Test data captured during an evening peak usage, "exhausted" router slowdown. Throughput speeds were probably in the 3500-4000 kbps range at the time of this test. The distinctive feature during the slowdowns were the vertical "dripping" pattern of the successive packets slowing to even slower speeds. Note that there also appears to have been at least one packet delay or RTT increase that would have added to the throughput slowdown.
4. A test of a line syncing at 6016/768 kbps, but its aggregation or gateway router (BRAS or redback) was incorrectly set to the 3000 kbps profile. This throttling in the gateway router reduces the average throughput on the line to about 2550 kbps, but the throughput speeds have periodic "drips" below and "spikes" above that "baseline" speed every second or so. This maybe caused by the gateway router's buffer first filling and then emptying out over that drip-spike cycle time. Normally a Wireshark throughput test wouldn't have to be run to identify this particular problem of mismatched DSLAM and gateway speeds as it is well understood and widely known. This particular test was run to examine the action of the gateway router's buffers.
5. This is a test on a line with a defective DSLAM port card. The chart has the appearance of repeated packet delays and/or packet losses that are normally caused by TCP/IP layer problems. Ping test times on the line were normal and ping packet losses were 3% or less, but download throughput speeds were less than 20 kbps at times. An FTP download throughput speed test on this line was only about 2800 kbps. This problem was cured when the card was replaced. Notice how the line periodically manages to get up to the full speed baseline about every 12 - 15 seconds or so. This periodicity may be a clue to the problem cause.
6. Numerous packet interruptions were caused by intensive CRC error activity in this test. These CRCs are believed to have occurred when the ATM traffic rate was set faster than the ADSL rate causing ATM cells to be dropped. This then corrupts the AAL5 logical packets. See: »www.cisco.com/univercd/cc/td/doc···nfig.htm . This unusual CRC activity only occurred while using a non-AT&T supplied modem and the errors were not caused by impulse noise. Note the anomalously high speed "spikes". Maybe a buffer within the modem was emptying to give these +16000 kbps "spike" speeds?
7. A self-induced, throughput slowdown caused by saturating the upload stream on an obsolete modem, the 5360 Speedstream, which doesn't have ACK prioritization. The download speeds are throttled back due to ACK starvation which occurs when download packets have to be re-sent after the modem fails to ACK the FTP server in time. These download throughput speeds were only about 700-800 kbps during the upload duration and this is typical for a modem without any degree of ACK prioritization.
Primarily what you should be doing here is pattern matching your throughput graph to the example graphs that have been associated with known problems. Interpretation of these throughput graphs is a dark art and the understanding of them is evolving! It can be seen from some of the examples that different problems can cause similar looking graphs. Probably no graph by itself is conclusive proof of a particular problem, but the graphs should be used with other data to help narrow down the causes of a throughput problem.
Thanks to mktanamachi and tsarath for contributing charts with throughput problems.
Something to note: you may get these problems if your upstream noise margins are having problems as the upstream is "challenged". Explained here: https://secure.dslreports.com/forum/r26294575-