Hello, I'm trying to figure out a way to get the network latency on the Win32 Tap interface as low as possible since it's required for the application I'm working on. I'm testing it by simply using ping.
Right now the bottleneck is the fact that the Tap thread has the wait for service from the QEMU main thread to shuffle incoming data into the virtual machine. On my machine that equals a range of 1-18ms pings with an average of 9ms. This is way beyond acceptable for my needs. Example: 1. tap_win32_thread_entry() Read incoming data from the Tap interface and puts it in a buffer queue. 2. tap_win32_thread_entry() signals a semaphore that QEMU's main_loop_wait () periodically polls to see if service is required. 3. QEMU's main thread then executes the callback that grabs the incoming data and calls the network client's read callback (e.g. ne2000's ne2000_receive()) 4. The data is processed in the network clients code in the context of this thread and, yay, the virtual machine has it's data. The problem is that there can be a lot of latency between the 'polling' passes made by the main thread. On my system, I've verified that that is the big bottleneck. Other sources of latency 1. WaitForMultipleEvents() seems to add enough overhead to make a difference. When I added the qemu tap callback to the polling queue instead of the wait_object queue, latency decreased. 2. tap_win32_thread_entry() blocking that occurs when the QEMU main thread is accessing the buffer queue that contains the data. -------------------------------------------------------------------------------- I've actually tried removing all interaction with the QEMU main thread by calling the network client's callback directly via qemu_send_packet() from the context of tap_win32_thread_entry(). This had amazing results, reducing latency to nil. Seemed to work fine too. Hehe Pings had <1ms latency without any blips at all. Of course this violates synchronization checks since the network client's callback isn't thread safe. I could start adding some Win32 CRITICAL_SECTION protections to try and correct that. However, this would mean that the main QEMU thread would block there occasionally. Anyone have any insights/ideas on my train of thought? I could use some since I'm treading unknown waters. -------------------------------------------------------------------------------- Ely Soto ----------------------------------------- Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged and exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. This communication may also contain data subject to U.S. export laws. If so, that data subject to the International Traffic in Arms Regulation cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, absent the express prior approval of the U.S. Department of State. If you have received this communication in error, please notify the sender by reply e-mail and destroy the e-mail message and any physical copies made of the communication. Thank you.
