[time-nuts] Win XP and NIST time
lists at lazygranch.com
lists at lazygranch.com
Wed Mar 27 13:08:34 EDT 2013
The timing/logging of events can benefit from precise time, even if the processing of such data is not real time. MLAT/TDOA for example. But I believe stock trading uses precise timing in order to queue orders.
On my list of sdr hacks is a radio interferometer. Precise event timing there would be key. (I will have to hack the sdrs to use one time source.)
From: Dan Kemppainen <dan at irtelemetrics.com>
Sender: time-nuts-bounces at febo.com
Date: Wed, 27 Mar 2013 12:46:08
To: <time-nuts at febo.com>
Reply-To: Discussion of precise time and frequency measurement
<time-nuts at febo.com>
Subject: Re: [time-nuts] Win XP and NIST time
Good explanation. I guessed, since the list is "time nuts" I assumed
"real time" in reference to an OS would be understood. :) My bad.
Because windows is not a real time operating system (RTOS), I lack
seeing the purpose in getting the windows clock synchronized to within
microseconds or nanoseconds of anything. Even if you could do it, you
won't get much out of doing so.
I've seen windows regularly stall critical code loops for more than a
second at a time, when the loops would normally take a few milliseconds
to run. If reading data down a USB connection, with limited buffering on
the USB peripheral, data can and will be lost in streaming applications.
(I suspect the SDR mentioned has a good bit of buffering in it!)
As for timing things on windows, check out how to read the performance
counters in windows. I believe these are QueryPerformanceCounter and
QueryPerformanceFrequency in kernel32. In most modern systems these
should give a time stamp from the system start, at the native core clock
Now, using these with interrupts on some sort of input, one should be
able to get some really good resolution on measurements from a PC. If
the CPU clock frequency was locked to a really good source, you could
get quite a system out of it...
On 3/27/2013 12:00 PM, time-nuts-request at febo.com wrote:
> The appearent conflict here is in the definition of "real time".
> For the video capture application we only need to keep up with the
> average data rate and if the system stops reading data for a few tens
> of milliseconds and lets it buffer in the capture hardware then it is
> OK because nothing is lost. The only criteria for success is
> "nothing is lost".
> The SDR application is a little more time critical because it needs to
> play the proceed audio. But again it can be buffered and we'd never
> notice a 50 millisecond lag in audio and for radio a 100 ms lag might
> go unnoticed
> But there is a category of what engineers ca "hard real time". Home
> computer users don't normally use their PCs for hard real time
> applications. This would be things like controlling a walking robot,
> guiding an anti aircraft missile or just about any time a computer is
> inside the feedback loop of a control system. These are all
> engineering and science applications that home users wouldn't see.
> A "harder" real time use that people DO see in home use is music. If
> you try to do multi-track recording in a home music studio with
> windows. This can be done but people have to do thinks like (1)
> remove everything non music related from the PC and disconnect it from
> the network. (2) replace the audio subsystem software with special
> real-time ASIO audio drivers. Then it can work
> So ""real-time" has a wide range of meanings, video capture is about
> the easiest to do and being embedded in a servo control loop the
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
More information about the time-nuts