[Interest] Packet arrival-time resolution? QUdpSocket

Jason H jhihn at gmx.com
Wed Dec 6 15:49:47 CET 2017



> Sent: Sunday, December 03, 2017 at 12:18 AM
> From: "Zielinski, Mariusz        UTC CCS" <Mariusz.Zielinski at fs.utc.com>
> To: "interest at qt-project.org" <interest at qt-project.org>
> Subject: Re: [Interest] Packet arrival-time resolution? QUdpSocket
>
> Hi,
> > From: Thiago Macieira [mailto:thiago.macieira at intel.com] 
> > On Thursday, 30 November 2017 13:27:16 PST Jason H wrote:
> > > > 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)
> > 
> > Yeah, but note how my speed of light isn't approximate. :-)
> 
> Imperial units are defined using SI units so we may lose precision. SI units are not natural but arbitrary. Why this is important here? :-]
>  
> > > > 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 ;-)
> > 
> > My point is that I couldn't get the monotonic arrival time from most OSes, so I can only give you the old, regular wall-clock time. If your clock suffers a time jump, you have to compensate yourself.
> > 
> > Then again, the only application that cares about time jumps when relating to packet arrival time is the application that performs those time jumps in the first place. It's called "ntpd".
> 
> Jason - can you tell what is the problem you are trying to solve ? You don't want to measure packet travel time for no reason, do you ? :-)
> 
> As this problem is definitely not in Qt scope you'll have better luck for example on stack overflow. My recommendation is to dig into reference implementation NTP code and repeat what they did.
> I trust that NTP is the best you can do without specialized hardware.

Very simply, while NTP is an essential part of the solution, being able to measure packet times between local devices (not relative to a time server) was what I was asking for. Thiago came through and enabled the millisecond packet timestamp for UDP which allows me to obtain additional information which when used in conjunction with other techniques allows me to arrive at a more precise coordinated time ground truth. 



More information about the Interest mailing list