Becky and I have both been noticing that our Internet connection slows down whenever a significant amount of output data is moving through the pipe. Officially, our DSL is supposed to be 3000/768 kbps but any time I run a speed test, I get around 2500 kbps down which is acceptable but only get around 165 kbps up. Normally this isn’t a big deal as there isn’t normally much upstream data going on, but when Becky’s mother comes online, my systems start backing up to her system via CrashPlan. Even running "full out" I only get 165 kbps up which is far short from the expected 768 that I should be getting.
In trying to isolate this, I disconnected my entire home setup (eight devices connected via three routers) and hooked a laptop up directly to the modem. A repeat of the test gave me spec’d performance and restoring my setup (after resetting the router) gave me a good test as well, but any subsequent one was poor. I am nearly 100% certain it isn’t due to another device filling the pipe (I monitor all my systems via Cacti). Even if one was, it still is capped out at 165 kbps. I’ll need to repeat a few tests to try and isolate and identify the cause.
Everything else works as expected. I get frustrated with strange problems like this.
Update: Based on Matthew’s comment, I made sure that each of the three inside instances of CrashPlan are throttled (only one was connecting to an outside server). That made no difference. Tonight, I tried swapping out my main router with another Linksys and got the same results. I then connected my laptop directly to the modem which also had the same results. I reset the modem and am having good performance, but as I did that in the past, I’m expecting the outgoing to become poor again based on past tests.
Hi! Any time you “choke” the outgoing pipe, you’re going to experience “slow” internet. The issue is how TCP does flow control.
Basically, as you receive TCP packets, there is a small window of time where you need to tell the server you got it.. If you don’t get back in time, your speed gets cut in half, then half again, and so on.. so even a small delay in acknowledging an inbound packet will cause a severe slowdown.
The solution? Make sure you never fill up the outgoing pipe.
For CrashPlan, make sure it’s not using more than 90% of your available upstream rate. That way, you shouldn’t notice any slowdown.
~Matthew