This project has moved and is read-only. For the latest updates, please go here.

Thread Synchronization & time stamp accuracy

Jul 27, 2011 at 4:56 PM

Hello all,

I'm working on a research project in C# programming platform on simulating PMU & PDC output streams (config, header, data frame). I would be very obliged if any of you fellow programmers (especially the developers of OpenPDC) could help me with this small problem I'm facing right now.

I've almost completely simulated my PMU & PDC. The PMU is configured for sending data at 10 frames per second and am using threading technique to simulate 10 PMUs (at the moment). Now, here's my my algorithm for a cycle of every 100 ms (for 10 frames/sec = 1 frame every 100 ms)

-thread triggered

-generate data frame in string format (time taken = 10 ms)

-transmit data frame (time taken = 1 ms, all time is calculated & recorded using the stopwatch function)

-Using thread.sleep(time) (the thread sleeps for time = (100 - 11) msec before triggering the thread again)


Now, the trouble is with thread.sleep which is apparently a very inaccurate way of idling a thread (as read in my online programming forums) as the time taken for it to wake up is never consistent (I confirmed this using a timer and a while loop & every time it gave me a different result). As a result, the threads are not triggered at the same time & when I test my data stream with PMU connection tester, the dynamic dataframe rate shown at the bottom of the window fluctuates between 9.7 - 10.2 frames per sec. Also the main problem is, because of the un-synchronous manner of the triggering of threads, when all the PMUs are connected to OpenPDC & the output stream of the openPDC is observed in the PMU connection tester, data from most of the PMUs is lost (displayed as NaN in the magnitude & angle field).

I know the openPDC is dicarding the data because of this, which is what it is suppose to do, but could any of the developers please recommend a viable solution? I ask the developers because openPDC itself runs without any GPS sync & has to use its system clock to synchronize its functions and if there is a better alternative to thread.sleep(). I can't use monitor.wait since it does'nt wait for a specific time & I cannot use the while loop as it ramps the CPU usage to 100% & slows down my code. I've been fretting on this issue for quite a while now & would be grateful 


Kunal Dekhane

Virginia Tech

Jul 27, 2011 at 5:08 PM

You've happened onto on one of Windows secrets - precise timing is not a OS priority. However, apps that need synchronization like MIDI seem to work - how is that?

It's the Windows Multimedia timer API that allows applications to handle precsision timing, down to the millisecond. To get any higher resolution you would need to max out a core using a while loop like you mentioned.

The openPDC has to use this for a good heartbeat in transmissions, which can be up 120 frames per second which is well under the ~15 ms rough timing window you mention. The PMU Connection Tester includes a setting to use the precision timer as well to help with simlulated playback from a file (see settings tab).

If you want to use the precision timer in your own code from .NET, you can just use the TVA.PrecisionTimer class in the TVA code library (i.e., the TVA.Core.dll) - usage should be fairly simple - very similar to a standard timer, but you get precision down to the millisecond. Search through the openPDC source code for the precision timer to see how it used. Otherwise check the Windows API docs for the multimedia timer API if you are developing in C++.

Make sure to cooperate with setting the system's lowest desired timer resolution - e.g., 1 millisecond - since this is a shared OS setting.

Hope that helps a little!