Win10 GetQueuedCompletionStatusEx did not return in real time

[noah-hwang]

When I use the msquic server to send a datagram packet(1024 byte) per 20MS
Then packet capture on win10, winshark packet capture shows that a QUIC packet is received in an average of 20MS
But msquic client callback datagram delay 120ms (accidental appearance)
Analyse msquic client log:
Show that GetQueuedCompletionStatusEx no real-time returned asynchronously, this function blocked about 120 ms,
Then six packets were returned synchronously at once, Result in some packets are delayed 120 ms
How can I improve the timeliness of datagram returns, thanks!

---

(picture is winshark capture)

Log as follows:
[0]18244.18AB0::2024-04-25 20:49:59.879421400 [Microsoft-Quic]CxPlatWorkerThread In Worker 000001969D0C1AA0 NoWorkCount 1
[0]18244.18AB0::2024-04-25 20:49:59.879423100 [Microsoft-Quic]CxPlatRunExecutionContexts In Worker 000001969D0C1AA0 0
[0]18244.18AB0::2024-04-25 20:49:59.879425100 [Microsoft-Quic][wrkr][0x1969D0C3310] IsActive = 0, Arg = 885952527
[0]18244.18AB0::2024-04-25 20:49:59.879425900 [Microsoft-Quic][wrkr][0x1969D0C3310] QueueDelay = 0
[0]18244.18AB0::2024-04-25 20:49:59.879427500 [Microsoft-Quic]CxPlatRunExecutionContexts out Worker 000001969D0C1AA0 9999
[0]18244.18AB0::2024-04-25 20:49:59.879429100 [Microsoft-Quic]CxPlatRunExecutionContexts In Worker 000001969D0C1AA0 9999
[0]18244.18AB0::2024-04-25 20:49:59.879430800 [Microsoft-Quic]CxPlatRunExecutionContexts out Worker 000001969D0C1AA0 9999
[0]18244.18AB0::2024-04-25 20:49:59.879431800 [Microsoft-Quic]CxPlatEventQDequeueBak In 9999
[0]18244.18AB0::2024-04-25 20:50:00.022415200 [Microsoft-Quic]CxPlatEventQDequeueBak 1
[0]18244.18AB0::2024-04-25 20:50:00.022421900 [Microsoft-Quic]CxPlatProcessEvents Worker 000001969D0C1AA0 1 32772
[0]18244.18AB0::2024-04-25 20:50:00.022424300 [Microsoft-Quic]CxPlatDataPathProcessCqe 4 1
[0]18244.18AB0::2024-04-25 20:50:00.022426800 [Microsoft-Quic]CxPlatDataPathSocketProcessReceive In 0
[0]18244.18AB0::2024-04-25 20:50:00.022429300 [Microsoft-Quic]CxPlatDataPathUdpRecvComplete In
[0]18244.18AB0::2024-04-25 20:50:00.022431100 [Microsoft-Quic][data][0x1969D0C8710] Recv 1060 bytes (segment=1060) Src=200.200.180.34:60198 Dst=200.200.180.101:9001
[0]18244.18AB0::2024-04-25 20:50:00.022436000 [Microsoft-Quic][pack][1099511628384] Received
[0]18244.18AB0::2024-04-25 20:50:00.022450000 [Microsoft-Quic][conn][0x1969D0C67B0] Queuing 1 UDP datagrams
[0]18244.18AB0::2024-04-25 20:50:00.022453200 [Microsoft-Quic][conn][0x1969D0C67B0] Scheduling: QUEUED
[0]18244.18AB0::2024-04-25 20:50:00.022456100 [Microsoft-Quic]CxPlatDataPathStartReceive In 0
[0]18244.18AB0::2024-04-25 20:50:00.022459300 [Microsoft-Quic]CxPlatSocketStartWinsockReceive In 0 SyncBytesReceived 0000003288DFF808
[0]18244.18AB0::2024-04-25 20:50:00.022464400 [Microsoft-Quic]WSARecvMsg 0
[0]18244.18AB0::2024-04-25 20:50:00.022466100 [Microsoft-Quic]SyncBytesReceived 1049
[0]18244.18AB0::2024-04-25 20:50:00.022466600 [Microsoft-Quic]CxPlatDataPathUdpRecvComplete In
[0]18244.18AB0::2024-04-25 20:50:00.022467000 [Microsoft-Quic][data][0x1969D0C8710] Recv 1049 bytes (segment=1049) Src=200.200.180.34:60198 Dst=200.200.180.101:9001
[0]18244.18AB0::2024-04-25 20:50:00.022467500 [Microsoft-Quic][pack][1099511628385] Received
[0]18244.18AB0::2024-04-25 20:50:00.022486100 [Microsoft-Quic][conn][0x1969D0C67B0] Queuing 1 UDP datagrams
[0]18244.18AB0::2024-04-25 20:50:00.022487500 [Microsoft-Quic]CxPlatDataPathStartReceive In 0
[0]18244.18AB0::2024-04-25 20:50:00.022490000 [Microsoft-Quic]CxPlatSocketStartWinsockReceive In 0 SyncBytesReceived 0000003288DFF808
[0]18244.18AB0::2024-04-25 20:50:00.022493700 [Microsoft-Quic]WSARecvMsg 0
[0]18244.18AB0::2024-04-25 20:50:00.022495000 [Microsoft-Quic]SyncBytesReceived 1049
[0]18244.18AB0::2024-04-25 20:50:00.022495500 [Microsoft-Quic]CxPlatDataPathUdpRecvComplete In
[0]18244.18AB0::2024-04-25 20:50:00.022496100 [Microsoft-Quic][data][0x1969D0C8710] Recv 1049 bytes (segment=1049) Src=200.200.180.34:60198 Dst=200.200.180.101:9001

[nibanks]

When you're dealing with interrupts and the scheduler there's no way to guarantee real-time. Windows isn't a real-time OS. Lots of other stuff can be on your machine that delays things too. What exactly is the environment (is this Client or Server SKU)? Is this a Debug build? Have you tried any other OS versions?

[noah-hwang]

Thank you for your reply。
1.This is msquic client SKU, i was receiving packets on the client side and found the delay issue.
Version Windows 10 Professional
Version number 22H2
Installation date: ‎2021/‎12/‎30
Internal OS version 19045.4170
Experience Windows Feature Experience Pack 1000.19054.1000.0
2.Msquic client is debug version,There is no difference in real-time performance when calling Windows API between the release version and debug version in my testing.
3.When i use Android as the client to receive data, Data callbacks seem to have the same problem.
Does msquic have configuration parameters that can improve the real-time performance of Windows asynchronous I/O operations?The 120ms delay seems too long.
Thanks!