I have been tracking down some performance issues in my Win10 Qube and had some questions about how the emulated network driver stack works. I presume, by default, when Win10 is installed, it is using the emulated Realtek adapter passed up from QEMU. However, when QWT is installed with the XenNet and XenVIF drivers, how should it change that stack? Should Win10 still use the emulated Realtek driver, with the Xen network drivers altering the stack at the low level, or do the Xen drivers replace the Realtek driver with a different one?
Right now, even though both Xen drivers are installed, the system is still using the Realtek driver, and I get a LOT of blocking whenever I do a lot of network I/O, which is killing performance and causing sound breakups. LatencyMon complains that ndis.sys (among other things) is the source of a lot of my high latency issues. I do not believe it is ndis.sys itself, but when it calls down to lower-level drivers, and eventually going through the emulated layers to the real drivers managed in the sys-net and sys-firewall qubes. For some reason, it seems like network calls are blocking the OS at a very low level, rather than just using some kind of non-blocking request-callback scheme, like they normally should. I would expect delays in request handling due to all the extra layers, but in no case should they be blocking like this.
So I guess I have two questions: 1) How do the Xen Windows network PV drivers interact with the existing QEMU Realtek driver when installed, and 2) Is there some way to stop the blocking request behavior (or at least identify the cause?)
Thank you in advance for any info!