have you tried a download accelerator? axel is an example for linux. not sure what is out for windows.
A wget replacement won't fix the problem for other TCP connections such as video streaming. :)
i think you'll find that it's consistent low grade packet loss causing issues.
Yes, the impressive thing is that it doesn't affect UDP traffic, and limits sockets to the rate they would achieve at that ping without the large window extension. That indicates that it is intentional behaviour of the network. We've diagnosed it as a problem with Reach, Telstra Clear's upstream provider. :)
the easiest solution is to bounce your traffic through a server in los angeles to your remote destination. with tcp. you can setup something like redir with a firewall only allowing connections to your ip...
not sure if there is an easy way to do it transparently with vpn. but i think you'll find vpn on it's own doesn't help.
Well, since LA is the wrong side of Reach, we still won't see any performance benefits, which is why you want a socket to a VPN provider here in NZ that uses a different international traffic provider, or else a VPN that uses UDP or load balanced TCP. :) You could even implement some of Google's proposed TCP changes (quick start/etc) to reduce the number of round trips to the remote VPN endpoint. :)
I'd like my 10mbps per socket please!
interesting that it doesn't happen on udp. i assumed tcp was reacting worse to the small amount of packet drops seen in udp.
you've done iperf testing with udp i take it?
what are you using to measure tcp/ip losses? i'd be keen to try doing some testing of my own.
the thing about LA, is partially that it's closer.
wtf... i just tried to one of my LA hosts.. and it's going even worse than normal..
ok... my other LA host appears to be working fine through telstraclear... http://arp.meh.net.nz:24/10m
10mb test download.. peered with reach at equnix.
then another test that's slow
peered with reach at any2ix.
the alternative port will bypass any port 80 transparent proxies