Very low speed on outgoing traffic with NAT

[jakobsg]

Description The NAT mode guest interface is truely a great feature, but there are some optimization/scheduling problems on outbound traffic to remote hosts. I have tried this on several hosts (linux and windows) each with different hardware configurations, the result is the same - a throughput less than 500 kbyte/s (on windows hosts less than less than 100 kbyte/s). There is no problem when sending data from the guest to it's host. I have spent days debugging and profiling, but the problem is not a part of my expertees so at last I had to give up.

I have communicated quite a lot with the vbox developers via IRC passing on debug and profiling information - they say the problem is due to low prioritized scheduling on the host side.

Reproduce

1. Install a guest
2. Set up NAT on NIC1
3. Boot up on the guest and send something rather large to a remote host (for instance using scp on a linux guest).

Odd observations

1. Outbound traffic to the host is runs fast (8-10 Mbyte/s on my system)
2. Traffic to remote host on LAN very slow (less than 100 kbyte/s)
3. When I profile VBoxDD.dll outbound traffic speed jumps to 30X speed (more than 3 mbyte/s) (only on LAN)
4. While attempting to do some manual profiling in pcnetAsyncSendThread() (src/VBox/Devices/Network/DevPCNet.cpp) I opened a file for output and closed it again each time. This appearenty up prioritized the thread for transmitting network packets and the speed suddenly went drastically up.

My opinion I think there is a great potential in NAT with port forwarding, because it enables you (in conjunction with VBoxHeadless.exe) to distrubute a virtual machine and run it as a normal service (ie. Windows Service) the only thing missing is outgoing traffic speed :-)

Best regards Jakob Simon-Gaarde

btw: vmware's NAT has the same defect. So this could be a place where VirtualBox can offer a little more :-)

[Frank Mehnert]

VirtualBox uses the slirp engine for NAT. Unfortunately, this engine depends a lot on correct polling frequencies, that is the network card is polled more frequently if there are open connections and less frequently if not. It depends a lot if the network card is polled at the right time if you achieve an acceptable data rate or not. The correct way is to use signalling semaphores as we do with the host interface network. Unfortunately, changing the slirp code to use semaphores is not the trivial. We are aware of this problem but currently there is no fix in sight.

[vasily Levchenko]

duplicate #3400