Recently my VMware Server disks were converted to VirtualBox 3.0.4 running on Ubuntu 9.0.4. The guest operating system is Windows Server 2003 and one application which is a network monitoring software has trouble keeping up. It's sampling outside routers to get SNMP data at the rate of 1 sample per second.
When comparing the ping time to the outside routers between VMware and Virtualbox it was noticed that the VMware averaged 1ms while the Virtualbox was more dispersed and fluctuated between 1ms and 5ms. That was sufficient to leave some gaps in the network monitoring graphs display.
Both VMs use the default NAT settings and as the disks were converted one from the other and they ran in parallel in the same host, the environment was mostly identical.
I would appreciate any suggestion on tweaking the Virtualbox network setup to reduce any delay in its response so that the monitoring graphs display correctly.
How to reduce network delay
-
Perryg
- Site Moderator
- Posts: 34369
- Joined: 6. Sep 2008, 22:55
- Primary OS: Linux other
- VBox Version: OSE self-compiled
- Guest OSses: *NIX
Re: How to reduce network delay
Most network timing delays are tracked back to the Virtual Network Adapter. I find that the IntelPro/1000 T Server works without issue for me. Try to change it and stay with the Intel series in the guest settings section.
-
Viet
- Posts: 3
- Joined: 19. Aug 2009, 06:05
- Primary OS: Ubuntu other
- VBox Version: OSE Debian
- Guest OSses: Windows Server 2003
Re: How to reduce network delay
Dear Perryg,
Thank you for your reply and the tip. I went ahead and tried the other NICs but didn't notice any obvious improvement.
Below is the output of the ping, the fluctuations were even more pronounced than previously reported. I verified that the VM was idle (network monitoring software was turned off) and that the other VMware pinging still returned 1-2ms in that same time period.
Pinging 10.4.4.1 with 32 bytes of data:
Reply from 10.4.4.1: bytes=32 time=1ms TTL=127
Reply from 10.4.4.1: bytes=32 time=513ms TTL=127
Reply from 10.4.4.1: bytes=32 time=13ms TTL=127
Reply from 10.4.4.1: bytes=32 time=7ms TTL=127
Reply from 10.4.4.1: bytes=32 time=462ms TTL=127
Reply from 10.4.4.1: bytes=32 time=10ms TTL=127
Reply from 10.4.4.1: bytes=32 time=503ms TTL=127
Reply from 10.4.4.1: bytes=32 time=11ms TTL=127
Reply from 10.4.4.1: bytes=32 time=2ms TTL=127
Reply from 10.4.4.1: bytes=32 time=505ms TTL=127
Reply from 10.4.4.1: bytes=32 time=529ms TTL=127
Another piece of data that may be relevant: for this swapping of NICs the VM was stopped and restarted a few times, and sometimes after a restart the pinging could not occur (entirely timing out) even though the IP address was acquired. I had to ipconfig /release and /renew to have the NIC becoming live again.
The Advanced configuration of the network cards were also checked into, they still had the default values for MTU, Full Duplex etc.
Any other suggestion?
Thank you for your reply and the tip. I went ahead and tried the other NICs but didn't notice any obvious improvement.
Below is the output of the ping, the fluctuations were even more pronounced than previously reported. I verified that the VM was idle (network monitoring software was turned off) and that the other VMware pinging still returned 1-2ms in that same time period.
Pinging 10.4.4.1 with 32 bytes of data:
Reply from 10.4.4.1: bytes=32 time=1ms TTL=127
Reply from 10.4.4.1: bytes=32 time=513ms TTL=127
Reply from 10.4.4.1: bytes=32 time=13ms TTL=127
Reply from 10.4.4.1: bytes=32 time=7ms TTL=127
Reply from 10.4.4.1: bytes=32 time=462ms TTL=127
Reply from 10.4.4.1: bytes=32 time=10ms TTL=127
Reply from 10.4.4.1: bytes=32 time=503ms TTL=127
Reply from 10.4.4.1: bytes=32 time=11ms TTL=127
Reply from 10.4.4.1: bytes=32 time=2ms TTL=127
Reply from 10.4.4.1: bytes=32 time=505ms TTL=127
Reply from 10.4.4.1: bytes=32 time=529ms TTL=127
Another piece of data that may be relevant: for this swapping of NICs the VM was stopped and restarted a few times, and sometimes after a restart the pinging could not occur (entirely timing out) even though the IP address was acquired. I had to ipconfig /release and /renew to have the NIC becoming live again.
The Advanced configuration of the network cards were also checked into, they still had the default values for MTU, Full Duplex etc.
Any other suggestion?
-
Perryg
- Site Moderator
- Posts: 34369
- Joined: 6. Sep 2008, 22:55
- Primary OS: Linux other
- VBox Version: OSE self-compiled
- Guest OSses: *NIX
Re: How to reduce network delay
So as to eliminate this being a conversion problem can you use a different OS and see what happens?
Live CD running through VBox or better yet install something set it up the same way and try?
Only reason I suggest this is very few people have reported this kind of behavior give all of the people that use VBox, and I don't see this issue either.
Also you said that you converted this from VMware I believe. Did you remember to remove the VMware additions first?
Live CD running through VBox or better yet install something set it up the same way and try?
Only reason I suggest this is very few people have reported this kind of behavior give all of the people that use VBox, and I don't see this issue either.
Also you said that you converted this from VMware I believe. Did you remember to remove the VMware additions first?
-
Viet
- Posts: 3
- Joined: 19. Aug 2009, 06:05
- Primary OS: Ubuntu other
- VBox Version: OSE Debian
- Guest OSses: Windows Server 2003
Re: How to reduce network delay
Dear Perryg,
Got it on the additional things to try out.
A fresh install of XP Pro was done and on this platform different NICs were again tried. Still no joy.
The VMware disk was converted again this time without the VMware additions (they could not be
un-installed directly on the converted disk, error "failed to determine which VMware product this virtual machine is running on."). No change on the resulting VM.
At this point I just keep that network intensive application running under VMware while the other applications get migrated over to VirtualBox.
Thanks for your review of this problem, at least I now know that the subject has been explored and it can now be filed for future resolution if needed.
Got it on the additional things to try out.
A fresh install of XP Pro was done and on this platform different NICs were again tried. Still no joy.
The VMware disk was converted again this time without the VMware additions (they could not be
un-installed directly on the converted disk, error "failed to determine which VMware product this virtual machine is running on."). No change on the resulting VM.
At this point I just keep that network intensive application running under VMware while the other applications get migrated over to VirtualBox.
Thanks for your review of this problem, at least I now know that the subject has been explored and it can now be filed for future resolution if needed.