Opened 8 years ago
Last modified 8 years ago
#16605 new defect
Network dropouts in guest since Windows 10 update to 1607 version
Reported by: | boxer01 | Owned by: | |
---|---|---|---|
Component: | network/NAT | Version: | VirtualBox 5.1.18 |
Keywords: | Cc: | ||
Guest type: | Windows | Host type: | Windows |
Description
I got here following situation. I have a Windows 10 x64 guest on the same OS host. Right now I reduced the amount of installed programs in the guest to the minimum to find the culprit. So right now there is an antivirus (latest Nod32), Firefox and MP3 Player (Xmplay) beside the OS itself. I use the last program for Internet radio since XP days, and there were no problem until now, in and outside the VM.
Since guest update to the 1607 I can see following behavior: after 15 or 20 minutes of the streaming player starts to buffer at 70-80 % spontaneously around once in a minute, which breaks a streaming experience. One still can listen to the radio, but this is a little bit annoying. This problem only occurs if the Firefox also running in the guest. Something, I don’t know what, but probably some advertisement or data refresh, loads a little amount of the data over and over again once in nearly a minute. I got some network bandwidth pictures which explain the network flow better. But the problem isn’t a bandwidth itself – I can run a bandwidth test, which would use the whole bandwidth and still there would be no buffering. The problem is a timing, because as one can see we have something like 6 or 8 KB/s from the stream constantly, but once in a while the browser adds some 18-20 KB/s to it. So after a while there are some de-synchronization in the flow, which causes the buffering.
This only happens in the guest and only if the browser running with some sites open. If one turns the browser off, there is no buffering. Also, this can’t be reproduced running same player and stream on the host, neither with Firefox also opened on the host with some sites in it, or with Firefox running in the guest, causing the same traffic shape on the host. First of all a thought that this was a new issue with a new VB version, but I tested this with following versions (5.0.30 - 36, 5.1.6, 5.1.10, 12, 14, 16, 18) and the picture is always the same. Changing network adapter from 82540EM to paravirtualized also brings no cure. I tested it with following version of the network adapter drivers (virtio-win-0.1.110, 112, 113, 117, 118, 126, 134), but it always looks the same. There were also no such problems as I updated the host first, before the guest. The clean install of the guest OS from the scratch also doesn’t change anything in this case, but installing the previous version of Windows 10 (1511) in the guest solves the problem. I think, that the problem caused by some TCP/IP optimization in the new Windows version, as described here, the Initial Congestion Window 10 probably. If this is important – I hear following stream for example, but I think any other stream should also do the job. I would like to debug the network stack in the guest, but I don’t know how.
VM is running in the NAT mode. I hope that my description of the issue is clear, in spite of so much text.
Attachments (2)
Change History (3)
by , 8 years ago
by , 8 years ago
Changing TCP template from client to server one doesn’t help, but the data flow starts to jerk after some time. I couldn’t find any possibility to change the template settings, only the used template itself was changed.
comment:1 by , 8 years ago
Here another URL for the same stream. The results would be of course the same. And one more thing: one can use Firefox itself as an MP3 player, also for those streams. But even in this case the situation is reproducible.
Traffic shape in the guest