[time-nuts] Win XP and NIST time

[Dan Kemppainen]

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 
frequency.

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...


Dan




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
> hardest