[Interest] Packet arrival-time resolution? QUdpSocket

[Jason H]

> Sent: Wednesday, November 29, 2017 at 11:05 AM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: interest at qt-project.org
> Subject: Re: [Interest] Packet arrival-time resolution? QUdpSocket
>
> On Wednesday, 29 November 2017 01:34:05 PST Konrad Rosenbaum wrote:
> > Any software working on a scale below 10ms needs to be realtime. Qt is not
> > realtime. Sorry.
> 
> That's why the API I'm creating will give you a QDateTime, which only has 
> millisecond resolution.
> 
> I thought briefly about using QDeadlineTimer (which has nanosecond), but gave 
> up since it wasn't necessary and I couldn't get the monotonic timer on most 
> OSes.

Consolidated reply,
The speed of light is ~1ft per ns, and your clock is running at ~0.33-1 ns. There's plenty of factors to prevent absolute best performance, not even including that the speed of light in a wire is about 1ft per 3ns, due to inductance (multi-layer PCBs also slow it down). Meanwhile the speed of sound is ~1.1ft per ms at STP. If I can get reliable 1 ms packet resolution and accuracy I'll be fine. I can alter the data and node configuration to support some jitter. As long as the hosts accurately record the event on local clock time, and I know the offsets of each clock, can calculate the true event time. If they are all sub ms deviation, then I can take it as-is and know I'll be within 13 inches.   

I don't think you can say that Qt is not real-time. That's more of a kernel issue than a software library issue. 

So definitely I need to use P2P for usec sync of the clocks.

But I think as networks and CPU clocks get faster, that 1 ms will seem like an eternity. I seem to be working just at that ms/usec boundary...


Thanks for all your help!