Hi. I am using clock to achieve a kind of sychronization. The problem is that after some minutes the sychronization is lost, probably because clock returns huge numbers. Is there a way I can "restart" the clock function?
Printable View
Hi. I am using clock to achieve a kind of sychronization. The problem is that after some minutes the sychronization is lost, probably because clock returns huge numbers. Is there a way I can "restart" the clock function?
Why would huge numbers be a problem?
You cannot reset clock.
Because clock returns msecs, an error of some micro-secs may occure, so after some million msecs this error is getting very large.Quote:
Originally posted by CornedBee
Why would huge numbers be a problem?
Actually clock()'s unit is 1/CLOCKS_PER_SEC.
1/1000th of a second on Windows, and I doubt how accurate this actually is.
You can use time(time_t*), it has second resolution. But that's probably too inaccurate.
For high numbers, but with great accuracy, you can use QueryPerformanceCounter, only available in Windows.
thanx a lot.
Well...may I ask which kind of synchronization you want to reach by using 'clock()'?
Quote:
Originally posted by CornedBee
Actually clock()'s unit is 1/CLOCKS_PER_SEC.
1/1000th of a second on Windows, and I doubt how accurate this actually is.
You can use time(time_t*), it has second resolution. But that's probably too inaccurate.
For high numbers, but with great accuracy, you can use QueryPerformanceCounter, only available in Windows.
Probably Clock (time.h) is the only portable way in C /C++
Reset is not possible. Though there is no chance of over flow since it is unsigned long afaik
Regards
Even 4 billions might overflow...
*For windows*
long int = 32 bits
therefore for overflow
2^32/1000 seconds
/3600 hrs
Which comes around 1000+ hrs!!!
and thats in months
Regards
My file server's longest uptime was ~14 months...
hmmm .
for such long periods, normally date time functions suffice the accuracy needs.
Though it is rare to calculate timings for such applications.(since it is almost always possible to decompose)
And for synchronisation IMO Overflow should not cause problems.
Regards
I have developed 2 algorithms working on 2 different computers: one is for data acquisition from microphones and the 2nd for sound enchancement and sound playback. This is done real-time, and because block-processing is used, the processes have to be synchronized. More specific, the 2nd peoccess send data to the sound card and after that WAITS for the next block, for a specific time (here comes clock()).Quote:
Originally posted by Andreas Masur
Well...may I ask which kind of synchronization you want to reach by using 'clock()'?
I know that 2^32 msecs is a long time but not long enough:
1200 hours = 50 days.
Thank you. My point of asking this was, that using 'clock()' as a synchronization method would not come to my mind in the first place (except for getting the same time over several PC's for logging etc.).Quote:
Originally posted by yiannakop
I have developed 2 algorithms working on 2 different computers: one is for data acquisition from microphones and the 2nd for sound enchancement and sound playback. This is done real-time, and because block-processing is used, the processes have to be synchronized. More specific, the 2nd peoccess send data to the sound card and after that WAITS for the next block, for a specific time (here comes clock()).
I have not been talking to a soundcard yet, thus, I guess I cannot help here much. What operating system is that for? I would assume if you need such a high resolution, you would rather go down on the hardware level (multimedia timers etc.).
The programs run under win2k and Xp. The acquisition program runs only under windows cause it uses some DirectX commands, but the 2nd program (which uses clock()) is ANSI C, so it could run also in unix.Quote:
Originally posted by Andreas Masur
I have not been talking to a soundcard yet, thus, I guess I cannot help here much. What operating system is that for? I would assume if you need such a high resolution, you would rather go down on the hardware level (multimedia timers etc.).
So are the two programs then going to run on different computers? Is that part of your requirement that one will run on Windows and the other *nix?
well, outside of the windows world it appears that CLOCKS_PER_SEC=1000000L, so the counter overflows in little more than one hour. and no, there's nothing (portable) you can do about it.Quote:
Originally posted by CornedBee
Actually clock()'s unit is 1/CLOCKS_PER_SEC.
1/1000th of a second on Windows, and I doubt how accurate this actually is.
You can use time(time_t*), it has second resolution. But that's probably too inaccurate.
For high numbers, but with great accuracy, you can use QueryPerformanceCounter, only available in Windows.
Ok, you did say that you wanted to synchronize two different computers! (sorry I didn't see that before). I happen to work with embeded systems at my job and am familliar with this area. I strongly recommend that you do NOT rely on timers. Even if the computers you have have good oscillators, there will still be a little bit of drift between the different clocks. (BTW, clock() is a very bad method to use for other reasons -- it measures the amount of time spent in the current process, not the difference of between two times). The only way to synchronize correctly is to have one computer send a signal to the second computer -- perhaps through a TCP/IP port. Anyway, good luck!
- Kevin