http://blog.thinkbroadband.com/2013/05/so-how-fast-a...

10% were getting 18.4 Mbps or more on Infinity 2

your speedtest doesnt have the buffering problem.

eg. I get 19mbit upload on your test, yet can only upload to BT cloud at 2.5mbps.

Edited by Chrysalis (Fri 13-Sep-13 15:17:36)

Commercial cloud services tend to have restricted upload speeds. From work I very rarely get more than 3Mbps upload to commercial cloud services yet I can upload at around 40-50Mbps to my own cloud server.

however I can get 20mbit to BT's cloud after some fiddling with the send buffer

Thanks for the advice Chrysalis, that registry key doesn't exist on my server, but Winsock autotuning is enabled.

I suspect the main limit on my upload is Crash Plans servers, and the fact they are in America, the ones I'm backing up to are in Atlanta and speedtest results to Atlanta only reach about 4Mbps.

ronski here is a result of some tests I did with a ftp client.

to one of my servers in america, latency 116ms

note default is just a 4k window size, below tests are single threaded.

with a 16k tcp window size approx 1mbit/sec upload throughput
with a 64k tcp window size approx 4mbit/sec upload throughput
with a 256k tcp window size approx 17mbit/sec upload throughput

my windows setting currently of 512k is probably overkill to EU servers unless heavily interleaved.

Looks interesting, so what exactly would I need to enter on my server to test this, I have around a 6Mbps upload speed.

add the 2 keys I gave you for windows client side.

modern linux is likely to already be preconfigured for large enough tcp windows, if you uploading to the server then its recieve window needs increasing on that if low. they are configured via sysctl and dont need downtime/reboot to apply its instant.

on my testing I left windows at 512k and adjusted the recv window on my bsd server since its far quicker than rebooting windows between each change, although my ftp client allows live adjustments also.

if not check net.ipv4.tcp_rmem and net.ipv4.tcp_wmem rmem is for recv (downstream) wmem is for send (upstream), linux has very good defaults tho and I dont think needs any adjustments, the 3rd figure is the limit.

bsd uses net.inet.tcp.sendspace for upstream and net.inet.tcp.recvspace for downstream, it also has autotuning configurables net.inet.tcp.recvbuf_max which is overriden by net.inet.tcp.recvspace if smaller and net.inet.tcp.sendbuf_max which gets overriden by net.inet.tcp.sendspace if smaller, and net.inet.tcp.sendbuf_auto/net.inet.tcp.recvbuf_auto to toggle the autotuning.