Bandwidth saturation is an issue that is commonly misdiagnosed as a performance issue on the DSL line. Keep in mind that saturating the downstream side of the link, will use up most of the upstream with TCP/IP acknowledgements, and that saturation the upstream will limit the download speed as the computer will be waiting for the acknowledgements from the other side.
There can be many causes, but there is usually one simple way to identify this as an issue: while the issue is occurring, remove devices one at a time from the network. If removing a single device restores service to normal levels, you have found the culprit.
Effects of Bandwidth Congestion on Latency
If you suspect upload saturation is occurring, the most direct method of identifying the source of the upload is to run a continuous ping test and remove devices from the network one at a time until ping responses go down to a reasonable level. Compare the following two ping test results:
$ ping 50.X.X.X PING 50.X.X.X (50.X.X.X) 56(84) bytes of data. 64 bytes from 50.X.X.X: icmp_seq=1 ttl=57 time=1135 ms 64 bytes from 50.X.X.X: icmp_seq=2 ttl=57 time=1106 ms 64 bytes from 50.X.X.X: icmp_seq=3 ttl=57 time=1161 ms 64 bytes from 50.X.X.X: icmp_seq=4 ttl=57 time=1115 ms 64 bytes from 50.X.X.X: icmp_seq=5 ttl=57 time=1096 ms 64 bytes from 50.X.X.X: icmp_seq=6 ttl=57 time=1108 ms 64 bytes from 50.X.X.X: icmp_seq=7 ttl=57 time=1144 ms 64 bytes from 50.X.X.X: icmp_seq=8 ttl=57 time=1131 ms --- 50.X.X.X ping statistics --- 10 packets transmitted, 8 received, 20% packet loss, time 9118ms
Extremely high latency response times are one of the hallmarks of bandwidth congestion. Note that in addition to response times of over 1000ms (or one full second, an eternity in computational terms), that the above example is also losing packets due to time-outs.
$ ping 50.X.X.X PING 50.X.X.X (50.X.X.X) 56(84) bytes of data. 64 bytes from 50.X.X.X: icmp_seq=1 ttl=57 time=23.7 ms 64 bytes from 50.X.X.X: icmp_seq=2 ttl=57 time=23.4 ms 64 bytes from 50.X.X.X: icmp_seq=3 ttl=57 time=24.3 ms 64 bytes from 50.X.X.X: icmp_seq=4 ttl=57 time=63.1 ms 64 bytes from 50.X.X.X: icmp_seq=5 ttl=57 time=23.6 ms 64 bytes from 50.X.X.X: icmp_seq=6 ttl=57 time=22.9 ms 64 bytes from 50.X.X.X: icmp_seq=7 ttl=57 time=25.3 ms 64 bytes from 50.X.X.X: icmp_seq=8 ttl=57 time=25.9 ms 64 bytes from 50.X.X.X: icmp_seq=9 ttl=57 time=33.8 ms 64 bytes from 50.X.X.X: icmp_seq=10 ttl=57 time=23.3 ms --- 50.X.X.X ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9077ms
In this second example, we see the same circuit after the upload has been stopped. Response times are back to normal, and we are no longer seeing packet loss.
File sharing program
File sharing programs are usually a fairly obvious generator of traffic on a DSL line. What many customers are unaware of is that some of these programs do not fully close when you close the program. Some of these programs keep their shared folder open and continue to allow others to have access, using up bandwidth on the DSL line. If the customer uses any file sharing programs, have them take a look through the icons in their task bar. You should find the culprit there if it is causing the issue.
Virus or Worm
Computers infected with internet worms can generate an incredible amount of traffic. A virus does not usually cause a huge amount of traffic on its own, but many spammers use email viruses to create a zombie spam relay, and nothing chokes a connection quite like a hundred thousand emails sent every minute.
Open wireless connection
An open wireless connection can be an invitation for unwanted guests. If you have an unsecured wireless router, or any wireless router, try removing it from the picture and see how it affects the speed conditions on the line.
Sonic Fusion DSL customers can actually view their connectivity graphs via Member Tools -> Labs -> Fusion Line Profile -> View Graphs. As can be seen in the above example, this is what will show for periods where a line's upstream bandwidth is being intermittently saturated. In this instance, the circuit was hitting the maximum 1.2Mbps upload sync rate for extended periods of time, resulting in poor performance during these periods.
Network Resource Management Utilities
These resource management tools can also help diagnose if a specific program is the culprit behind upload saturation by checking Sent/Received Packets/Bytes.
The Windows Resource Monitor can be found by typing "perfmon /res" (no quotes) in Windows Search.
The Macintosh Activity Monitor is located in Applications > Utilities, or by searching in Finder for "Activity Monitor".