[Interest] Packet arrival-time resolution? QUdpSocket

[Jason H]

> Sent: Thursday, November 30, 2017 at 11:27 AM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: interest at qt-project.org
> Subject: Re: [Interest] Packet arrival-time resolution? QUdpSocket
>
> On quinta-feira, 30 de novembro de 2017 07:49:15 PST Jason H wrote:
> > The speed of light is ~1ft per ns, and your clock is running at ~0.33-1 ns.
> 
> Uh... that's not the same clock.
> 
> You're mistaking the CPU cycle clock with the timestamp counter and the real-
> time clock. They're not the same. Neither runs at 1 ns resolution (the RTC 
> runs MUCH slower). The TSC on modern Intel platforms runs at a constant rate 
> and is the same in all cores and processors, but that's not a guarantee on 
> other platforms.
> 
> > 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. 
> 
> In more usual units:
> 	speed of light = 299 792 458 m/s = 299.792458 mm/ns
> 	speed of sound at STP = ~340 m/s = ~340 mm/ms

Heh, yeah, "usual" for you. but the 1ft/ns or 1ft/msec makes it 1) easy to remember and 2) seem that nature prefers imperial. (totally coincidence and joking) 

> > 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.
> 
> Unless the wall-clock suffers a time jump. That's where I thought the 
> monotonic time would have been useful. You could convert it to wall-clock at 
> your leisure.

Yes, that's an option too. I'll figure it out ;-)