> Sent: Thursday, November 30, 2017 at 11:27 AM > From: "Thiago Macieira" <thiago.macie...@intel.com> > To: interest@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 ;-) _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
