Internet Upload Speed

[dennisgorelik]

About one week ago we noticed that upload from my computer to remote servers became quite slow.
Speed test indicates that while upload speed is good (80 - 90 Mbps), download speed is getting worse on remote servers.

My computer is in Jacksonville area and upload speed to Orlando servers is quite fast:
http://www.speedtest.net/my-result/5837858780
Orlando, FL
Ping: 21 ms
Download speed: 90.13 Mbps
Upload speed: 9.55 Mbps

That is close to 10 Mbps upload speed that Comcast claims to have for my account.

However the further away the server is - the longer is ping time and the worse is upload speed:
http://www.speedtest.net/my-result/5837865645
Dallas, TX
Ping: 47 ms
Download speed: 90.12 Mbps
Upload speed: 5.14 Mbps

http://www.speedtest.net/my-result/5837843259
Remote server: Seattle, WA
Ping: 83 ms
Download speed: 90.13 Mbps
Upload speed: 3.12 Mbps

http://www.speedtest.net/my-result/5837868925
London, UK
Ping: 115 ms
Download speed: 87.99 Mbps
Upload speed: 2.31 Mbps

http://www.speedtest.net/my-result/5837874972
Chelyabinsk, Russia
Ping: 188 ms
Download speed: 86.41 Mbps
Upload speed: 1.52 Mbps


Why does upload speed deteriorate proportionally to the ping to the remote server (but download speed stays the same)?
My hypothesis is that network protocol waits after every chunk of data for the response from the remote server (instead of continuing sending new chunks of data).
By why?
Comcast technician came today and found that there was some network issues with upload frequency. Lost packets during upload may initiate resynchronization waits that would drag upload speed down on connections with slower ping.

Comcast technician promised that within couple of days, Comcast network crew should fix the issues.
We'll see how that would change my upload speed.

Update (thanks to anspa recommendation):
PingPlotter shows a lot of Packet Loss with my Internet connection:

Comments

[sab123.livejournal.com]

1) No, a different kind of data. Basically, you can get the actual window size used for sending on each packet (and also see the round-trip time between the packet and the ACK for it), and the packet retransmits that cause the window to collapse. Well, you'll only see the window size advertised from the receiving side directly but you can compute the send size by subtracting the last ack's sequence from the last data's sequence.

BTW, the easy way to see the retransmit is to use the plain old command-line FTP with the hash printing enabled (it will print "#" for each block of data sent). You'll see these hashes printed fast when the data flows nicely, and hiccuping when a packet gets lost.

But PingPlotter's data is useful too. Traceroute ("tracert" on Windows) would probably give the approximately same information. It looks like Comcast has some kind of issues where their network connects to another provider, with the delays and packet loss.

2) The network card in your computer. BTW, the other side also has its settings for the maximal windows sizes, and the smallest of the two gets actually used. So your increasing the setting on your side might not help at all if the other side already has the lower limits.