Update 21/12/09: This is now sorted. See below for solution.

Ah, the agony of invisible Operating System behaviours! I noticed my browser experience slowing down. After running a gamut of tests, the cause seemed to be a slow ping time, but it didn't seem to affect all my computers. Ping times seemed fine until I ran Dropbox (v0.6.557) on Windows 7 (build 7600).

Ping to google.com
Reply from 66.102.9.105: bytes=32 time=18ms TTL=54
Reply from 66.102.9.105: bytes=32 time=25ms TTL=54
Reply from 66.102.9.105: bytes=32 time=20ms TTL=54
Reply from 66.102.9.105: bytes=32 time=20ms TTL=54
Reply from 66.102.9.105: bytes=32 time=17ms TTL=54
Reply from 66.102.9.105: bytes=32 time=19ms TTL=54
>> DropBox status 'Initialising'
Reply from 66.102.9.105: bytes=32 time=18ms TTL=54
Reply from 66.102.9.105: bytes=32 time=20ms TTL=54
Reply from 66.102.9.105: bytes=32 time=18ms TTL=54
Reply from 66.102.9.105: bytes=32 time=21ms TTL=54
Reply from 66.102.9.105: bytes=32 time=22ms TTL=54
Reply from 66.102.9.105: bytes=32 time=20ms TTL=54
Reply from 66.102.9.105: bytes=32 time=29ms TTL=54
Reply from 66.102.9.105: bytes=32 time=31ms TTL=54
>> Dropbox status 'Uploading 3 files'
Reply from 66.102.9.105: bytes=32 time=644ms TTL=54
Reply from 66.102.9.105: bytes=32 time=996ms TTL=54
Reply from 66.102.9.105: bytes=32 time=1620ms TTL=54
Reply from 66.102.9.105: bytes=32 time=2047ms TTL=54
Reply from 66.102.9.105: bytes=32 time=3375ms TTL=54
Request timed out.
Request timed out.

The problem seems to be related to upload activity. When one of my applications (such as Dropbox) is uploading, my ping times explode. Further testing indicates that this may be peculiar to Dropbox/HTTP, as WinSCP can upload over SSH without replicating the problem.

The behaviour is consistent across different adaptors (Dell D620, Broadcom NetXtreme 57xx Gigabit Ethernet, Intel PRO Wireless 3945ABG) connections (Zen home broadband, external WiFi), operating system versions (Windows 7 Business 32 bit and 64 bit) and machines (Quad-core 6600, Gigabyte P35C-DS3R, Corsair 2GB 1066Mhz DDR, WD Raptor 150GB and Dell Latitude D620
).

Dropbox also shows a meaningless progress report, but I think that's unrelated:

dropbox status

Have found some recommendations at Windows Seven Forums and Computing Forums but nothing to restore balance to my network connections. I tried:

netsh interface tcp set global autotuning=disabled
netsh interface tcp set global autotuninglevel=disabled

but ping times were unaffected. I then restored those settings to their default with:

netsh interface tcp set global autotuning=normal
netsh interface tcp set global autotuninglevel=normal

Other posts
I've posted this problem up on a few fora. I'll advise on how I get on:

Update: this problem is worsening. Not only do ping times increase drastically, but upload efficiency drops off a cliff. Dropbox has been trying to upload a 12MB file for several hours and it's consumed over 400MB of upload bandwidth (according to Windows' Local Area Connection status). I have a capped Broadband connection and this kind of waste is expensive!

C:\Users\alex>netstat -o

Active Connections

Proto Local Address Foreign Address State PID
TCP 10.12.1.120:49808 a92-122-208-201:http TIME_WAIT 0
TCP 10.12.1.120:49811 a92-122-208-248:http TIME_WAIT 0
TCP 10.12.1.120:49852 174:https CLOSE_WAIT 5876
TCP 10.12.1.120:49853 174:https CLOSE_WAIT 5876
TCP 10.12.1.120:49854 208:http ESTABLISHED 5876
TCP 10.12.1.120:49855 174:https CLOSE_WAIT 5876
TCP 10.12.1.120:49856 ec2-75-101-145-128:https ESTABLISHED 5876
TCP 10.12.1.120:49857 ec2-75-101-145-128:https ESTABLISHED 5876
TCP 127.0.0.1:49750 leo:49751 ESTABLISHED 5832
TCP 127.0.0.1:49751 leo:49750 ESTABLISHED 5832
TCP 127.0.0.1:49752 leo:49753 ESTABLISHED 5832
TCP 127.0.0.1:49753 leo:49752 ESTABLISHED 5832

The problem seems to be related to the HTTPS upload threads. Dropbox [PID 5876] uses Amazon's ec2, hence ec2-75-101-145-180.

The problem appears to be unaffected by upgrading to the latest current version of Dropbox (v0.6.570). Ping times still rocket (500-2000ms). I have tested on a 1MB upload normal service was restored quite quickly (about 15 to 20s). Unfortunately this isn't true once the connection beds in: a 13MB file still presents with high ping times when uploading and consumes >90MB upload data.

I'm not certain this is a Dropbox problem. I get the same symptoms when uploading video to YouTube. I suspect it's a Windows 7 HTTP/HTTPS upload problem, as WinSCP was unaffected (SSH).

Update 19/12/09
I had a reply from Dropbox suggesting it might be a conflict with my antivirus software (NOD32). I found this reference:

http://www.wilderssecurity.com/showthread.php?t=247163

I've disabled HTTP checking as described and so far things seem better. I need to do some more robust tests.

Update 21/12/09
This is sorted. I've just uploaded a 14MB file to Dropbox within efficiency bounds. Ping times fluctuated (two example periods below):

(lower)
Reply from 216.239.59.103: bytes=32 time=89ms TTL=52
Reply from 216.239.59.103: bytes=32 time=77ms TTL=52
Reply from 216.239.59.103: bytes=32 time=66ms TTL=52
Reply from 216.239.59.103: bytes=32 time=66ms TTL=52
(higher)
Reply from 216.239.59.103: bytes=32 time=517ms TTL=52
Reply from 216.239.59.103: bytes=32 time=549ms TTL=52
Reply from 216.239.59.103: bytes=32 time=329ms TTL=52
Reply from 216.239.59.103: bytes=32 time=310ms TTL=52

Similarly it took roughly 18Mb of net traffic to upload the 14.5MB (15.8Mb) file, which is ok.

Problem: bug in ESET NOD32 Antivirus version 4.0.467.0
Build versions:
Virus signature database: 4706 (20091221)
Update module: 1031 (20091029)
Antivirus and antispyware scanner module: 1253 (20091214)
Advanced heuristics module: 1099 (20091030)
Archive support module: 1105 (20091029)
Cleaner module: 1048 (20091123)
Anti-Stealth support module: 1012 (20090526)
SysInspector module: 1213 (20090902)
Self-defense support module : 1009 (20090917)

Solution: Open NOD32 "Advanced setup" from the quicktray menu. Uncheck "Enable HTTP checking" in "Web access protection -> HTTP, HTTPS".

In summary this was a horrible problem and it took many hours to resolve. It all comes down to the integration between software components. A feature in ESET's NOD32, which was designed to protect me from viri ended up behaving like a virus and wasting GB of net traffic, conflicted with Windows 7 and was triggered by legitimate behaviour in Dropbox. No one party will take responsibility, though I wish ESET would.

AttachmentSize
dropbox_zero_status.gif11.45 KB