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