I'm trying to get a better response time in an alternative tcp/ip stack I've written. It's ready and working except for this "problem";
I note that the difference in the time-stamps given by NPF.SYS and time when PacketReceivePacket() returns >= 1 packets is never below approx. 4 msec. On average it is 10 msec. I also note that the NPF time-stamps have high jitter. The time-diffs are in range 4-20 msec. I think I've setup everything to get lowest possible latency: * Allocated 150kByte for npf.sys buffers. * Call PacketSetFilter() to receive only directed and broadcast traffic. * Call PacketSetReadTimeout(adapter,0) to busy-wait for pkt(s). If I don't do this, the CPU usage is way too high. * Put my capture-thread at high-priority; THREAD_PRIORITY_TIME_CRITICAL. The thread calls PacketReceivePacket() which should return ASAP when a pkt is available. What I understood from the docs, is that calling PacketSetReadTimeout(adapter,0) would cause NPF to return immediately if a packet is ready. "immediately" is IMHO much less than 4 msec. That's 10 million clocks on this 2.2 GHz P4. I need lower lacency. The timestamp routine used in the time-diff is based on GetSystemTimeAsFileTime() with a shift to the Unix epoch. This seems rock solid since I snatched it from Apache. Is there anything else I could try? How about a custom PacketReceivePacket() routine with overlapped I/O? --gv ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe use mailto: [EMAIL PROTECTED] ==================================================================
