Slow upload on a NATed Windows XPSP3 guest

[alt236]

Hello!

I am having some problems with a Guest XP SP3 VM.

Even though the download speed on the NATed interface is reasonably high, but the upload speed seems to be capped at about ~50Kb/sec, works in bursts and eventually hangs. It seems to be worse when FTPing a large number of files in succession.

I've tried the same VM under a MacOS and a Linux host with the same results.

The moment I switch from NAT to a bridged interface, the upload speed returns to a reasonable level.

I disabled the QoS scheduler from the Guest's network interface with no results. I also tuned the TCP buffer with no effect.

There have been some similar problems in the past (not sure if they are related): ​https://forums.virtualbox.org/viewtopic.php?f=2&p=154844

https://www.virtualbox.org/ticket/1656

https://www.virtualbox.org/ticket/3400

Many thanks! Alex

[vasily Levchenko]

Could you please upload the log file? Do you I understand you right, you have installed ftp server(which server do you use?) on winXP guest and try to upload files via ftp?

[jdpurcell]

Wireshark Screenshot

[jdpurcell]

I'm having the same problem with a Windows host and Windows guest. It happens not only over FTP but also large HTTP POSTs and probably any other upload. I examined a Wireshark capture and I believe the problem is as follows: after a fair amount of data has been transmitted by the guest, I guess there's a buffer in VirtualBox that starts to fill up and the ACKs that it sends back to the guest have smaller window sizes. Occasionally one of those window sizes will be less than the MSS, and because of Windows' (the guest) Silly Window Syndrome avoidance, it will stop transmitting packets to avoid sending one smaller than the MSS until a 5 second timeout has passed. So the transfer ends up going in burts, with 5 second delays interspersed.

The workaround of increasing one of the NAT TCP/IP buffers helps, specifically the last number:

VBoxManage modifyvm <vm> --natsettings1 1500,64,64,64,1024

Although it reduces the frequency of the delays and greatly improves the transfer speed, it does not fully eliminate the problem.

[vasily Levchenko]

Replying to jdpurcell:

I'm having the same problem with a Windows host and Windows guest. It happens not only over FTP but also large HTTP POSTs and probably any other upload. I examined a Wireshark capture and I believe the problem is as follows: after a fair amount of data has been transmitted by the guest, I guess there's a buffer in VirtualBox that starts to fill up and the ACKs that it sends back to the guest have smaller window sizes. Occasionally one of those window sizes will be less than the MSS, and because of Windows' (the guest) Silly Window Syndrome avoidance, it will stop transmitting packets to avoid sending one smaller than the MSS until a 5 second timeout has passed. So the transfer ends up going in burts, with 5 second delays interspersed.

Thank you for investigation and summary. Could you please clarify a bit your environment? For Virtualbox settings you may attach your log file. Do I understand right that you have got web server on the guest?

The workaround of increasing one of the NAT TCP/IP buffers helps, specifically the last number:

VBoxManage modifyvm <vm> --natsettings1 1500,64,64,64,1024

Although it reduces the frequency of the delays and greatly improves the transfer speed, it does not fully eliminate the problem.

Could you describe what you "see" in this case? Perhaps attaching or sending your pcap files could help with clarification.

[jdpurcell]

I have reproduced it in 2 environments:
1) Windows Server 2008 host, Windows 7 guest, VirtualBox 4.1.14
2) Windows Server 2003 host, Windows XP guest, VirtualBox 4.1.8

The web server is remote (across the internet), not on the guest. The guest was POSTing a large amount of data (several megabytes) to the remote web server. I also reproduced the same thing by uploading a file to a remote FTP server.

I will attach a log from the 2nd environment and a CSV of the Wireshark capture in the guest. This was a FTP upload and I followed just the data stream. I can't provide the full pcap right now as there's sensitive data in it. NAT buffer settings were default.

After adjusting the NAT buffer settings the capture pretty much looks the same, except that more packets are transmitted in between the delays.

[jdpurcell]

Wireshark export of FTP data upload

[vasily Levchenko]

Replying to jdpurcell:

I have reproduced it in 2 environments:
1) Windows Server 2008 host, Windows 7 guest, VirtualBox 4.1.14
2) Windows Server 2003 host, Windows XP guest, VirtualBox 4.1.8

The web server is remote (across the internet), not on the guest. The guest was POSTing a large amount of data (several megabytes) to the remote web server. I also reproduced the same thing by uploading a file to a remote FTP server.

I will attach a log from the 2nd environment and a CSV of the Wireshark capture in the guest. This was a FTP upload and I followed just the data stream. I can't provide the full pcap right now as there's sensitive data in it. NAT buffer settings were default.

After adjusting the NAT buffer settings the capture pretty much looks the same, except that more packets are transmitted in between the delays.

Thanks for pcap file and clarification.

[cheoppy]

I have this problem too when Dropbox tries to upload a larger file (over 1MiB) to their servers. It can upload smaller files (some KiBs), but stalls when a large file is being uploaded. I was able to work around this problem with the

VBoxManage modifyvm <vm> --natsettings1 1500,64,64,64,1024

setting.

Host: Ubuntu 12.04.2 64bit
Guest: Windows 7 32bit

What other information should I provide to help fixing this bug?

[Frank Mehnert]

You are modifying the TCP receive space from 64K to 1024K, all other parameters are default (AFAICS). So do I understand correct that changing this setting makes your problem go away?

[Valery Ushakov]

It looks like NAT doesn't send window updates to the guest when it forwards data to the real destination. Since guest is directly connected to NAT engine, it can fill its receive buffers very fast. When the window closes and no window update comes from NAT, guest stops sending until its persist timer fires and prompts it to do window probe. It gets back fully opened window and can send the next burst of data, after which the problem repeats itself.

[Frank Mehnert]

Fix is part of VBox 4.3.14. Please reopen if necessary.