I have a codebase from linux that I am migrating to Windows. It uses raw sockets to send/receive ethernet packets using a custom EtherType. Obviously the WDK ndisprot sample is a model for how to send/receive packets at this level, but it uses ReadFile/WriteFile as the interface. Is there any way to implement an NDIS driver such that it would be wired up to user mode sockets instead? The real gap from using ReadFile/WriteFile in user mode is the codebase is heavily dependent on select() calls that use microsecond resolution timeouts (e.g. 10us). The TIMEVAL struct allows this to be specified with select(), but I’m not seeing any way to get such resolution with overlapped IO, completion ports, etc.
That said, does the select() API actually achieve these resolutions or is this just smoke and mirrors such that your 10us request may actually round up to 15ms? I could use the performance counters and spin of course, but ideally, I’d like to be able to block. I’m trying to understand, architecturally, how (or if) select() is able to achieve this given the resolution limitations of Sleep, WaitForSingleObject and the rest of the win32 native APIs.
Open to any other “plan B” approaches as well…
Thanks!
No, select cannot actually achieve sub-millisecond resolution. When the timer expires, the process becomes ELIGIBLE to be scheduled, but it won’t actually be scheduled until the next scheduler interval.
Windows is not a real-time operating system.
Thanks, Tim. Of course I realized that Windows is not a real-time OS, but that is a different question from timer resolution. I knew the OS had added higher resolution timers for multimedia purposes so I was allowing for the possibility that they were doing something bespoke for socket waits. But, in disassembling mwsock.dll I see that it is simply using NtWaitForSingleObject and in testing any timeval > 0 is jumping immediately to the 15ms delay of the timeslice.
First, select loops have terrible performance. Even on *NIX they suck
next, there is no way to ‘block’ for any time less than the scheduler granularity. Usually 10-15 MS. When the multimedia timers are enabled, that may be reduced substantially. But once a thread has yielded or been preempted, there is an unbounded delay until it is scheduled again even if it is not waiting.
you may have few choices, but the best design is to pend many read operations on the socket and let them complete as the packets actually arrive.