Dear Sirs,
this is an add on to http://www.osronline.com/showthread.cfm?link=282881 but with some new aspects and I cannot append to this old thread anymore due to its age.
Meanwhile we upgraded to VMware 6.5 and at first glance it looked like the problem didn?t show anymore. Now it reappeared.
If you don?t want to read the previous thread, here?s a short summary of the problem: we?re sending UDP packets (one per millisecond) via a Kernel driver using Winsock Kernel in a virtual machine (VMware, Windows Server R2012) in a 24/7 scenario. About three times per day we are watching (Wireshark) a burst of about 130 packets on the receiver side, with incorrect UDP checksum, while the Wireshark on the sending side sees them going out without burst and without UDP checksum error.
I digged a little deeper and detected that the disturbed payload is always in consequence of the delay of some packets which are then sent as burst. When I send all those UDP packets from a user mode socket, there?s still this delay and the following burst but the payload is not disturbed. The disturbed payload is not just random bytes, but the payload of a packet which is sent later. Now what?s the difference between sending UDP from Usermode and from Winsock Kernel by WskSendTo? Could it be that the packet has actually not been sent, although my IO completion routine for this packet has been called with success, which makes me think I can reuse the WSK_BUF structure and its MDL? So the packet is stuck somewhere below wireshark and when it?s actually going out I?ve already overwritten the byte buffer defined by this WSK_BUF structure? Is the broken payload and even more the preceeding delay of 50-150 millisecs something I could solve, which VMware has to solve or is it on MS side? (remember: Wireshark sees them go out perfectly in terms of time and payload and we never have seen these problems on physical machines)
Thank you very much and best regards,
Johannes F,