pcap_sendqueue_transmit() accuracy

[Cyril-debug]

Hello,
I am using the function pcap_sendqueue_transmit() to transmit high rate 64 bytes packets (from 600 packets/s to 60000 packets/s).

Depending on the type of test, packet interval can vary from ~1666us to 16us.

In the setup, I am using a ProfiTap 100M to hardware timestamp the traffic.

For 1666us packet interval, min, max is has follow:

For 16us packet interval, min, max is has follow:

I understand that 16us packet rate is very high but with 1666us, I don't understand why the jitter is so important.

I used different computers (with different adapters) to do this type of test but each time, I see the same behavior.
I mean, jitter can be very important and not constant.

I don't think there is a problem with npcap driver. I only want to know if there is something I can do to reduce this jitter.

Tests are made on Windows 11 Version 23H2 Build 22631.3880

---

DiagReport for Npcap ( https://npcap.com )

---

Script Architecture: 64-bit
Script Path: C:\Program Files\Npcap\DiagReport.ps1
Current Time: 08/29/2024 11:15:48
Npcap install path: C:\Program Files\Npcap
Npcap Version: 1.79
PowerShell Version: 5.1.22621.3880

---

CPU Info:

---

Name : Intel(R) Xeon(R) W-2125 CPU @ 4.00GHz
Manufacturer : GenuineIntel
DeviceID : CPU0
NumberOfCores : 4
NumberOfEnabledCore : 4
NumberOfLogicalProcessors : 8
Addresswidth : 64

---

Memory Info:

---

Size: 32495 MB (34073821184 Bytes)

Best regards,
Cyril

[Cyril-debug]

By looking on the source code of NPF_BufferedWrite(), it seems that NdisMSleep() is the source of the jitter.
I suppose that when this function is called for a number of microsecond, this number is not correctly respected by the kernel due to another important thread and a jitter appears.

The documentation of NdisMSleep() at https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ndis/nf-ndis-ndismsleep, NdisStallExecution() can be called directly if IRQL >= DISPATCH_LEVEL.

"An NDIS driver should always call NdisMSleep in preference to the NdisStallExecution function unless the driver is running at IRQL >= DISPATCH_LEVEL.
NdisMSleep can accept a larger delay interval than NdisStallExecution, which should never be called with an interval greater than 50 microseconds. Do not call NdisMSleep with a timeout of more than 30,000,000 microseconds (that is, 30 seconds or half a minute)."

The proposal can be to replace the call of NdisMSleep(i) by a loop calling NdisStallExecution().
This proposal will consume a dedicated core because it will use an active delay.

[Cyril-debug]

I did a test locally by changing the code of the function NPF_BufferedWrite().

This change reduces the jitter a lot but, for sure, it is consuming more resources.

[Cyril-debug]

Can it be possible to have another IOTCL dedicated to hard accuracy production time without the call to NPF_DoTap()?
The goal is to reduce work load during send sync. For example, by using BIOCSENDPACKETSSYNCHARD IOCTL.
For sure, an option (for example) will be necessary to call BIOCSENDPACKETSSYNC or BIOCSENDPACKETSSYNCHARD.