views:

214

answers:

5

I have a file of data Dump, in with different timestamped data available, I get the time from timestamp and sleep my c thread for that time. But the problem is that The actual time difference is 10 second and the data which I receive at the receiving end is almost 14, 15 second delay. I am using window OS. Kindly guide me.

Sorry for my week English.

+3  A: 

The sleep function will sleep for at least as long as the time you specify, but there is no guarantee that it won't sleep for longer.If you need an accurate interval, you will need to use some other mechanism.

anon
Kindly give me some direction for accurate sleep on window OS.
Arman
And given that @Arman is using Windows, it will be difficult to sleep for a precise time interval, since Windows is not a realtime operating system.
John Dibling
+1  A: 

Any modern multitask OS's scheduler will not guarantee any exact timings to any user apps. You can try to assign 'realtime' priority to your app some way, from a windows task manager for instance. And see if it helps.

Another solution is to implement a 'controlled' sleep, i.e. sleep a series of 500ms, checking current timestamp between them. so, if your all will sleep a 1s instead of 500ms at some step - you will notice it and not do additional sleep(500ms).

zed_0xff
A: 

Try out a Multimedia Timer. It is about as accurate as you can get on a Windows system. There is a good article on CodeProject about them.

waffleman
+2  A: 

If I understand well:

  • you have a thread that send data (through network ? what is the source of data ?)
  • you slow down sending rythm using sleep
  • the received data (at the other end of network) can be delayed much more (15 s instead of 10s)

If the above describe what you are doing, your design has several flaws:

  • sleep is very imprecise, it will wait at least n seconds, but it may be more (especially if your system is loaded by other running apps).
  • networks introduce a buffering delay, you have no guarantee that your data will be send immediately on the wire (usually it is not).
  • the trip itself introduce some delay (latency), if your protocol wait for ACK from the receiving end you should take that into account.
  • you should also consider time necessary to read/build/retrieve data to send and really send it over the wire. Depending of what you are doing it can be negligible or take several seconds...

If you give some more details it will be easier to diagnostic the source of the problem. sleep as you believe (it is indeed a really poor timer) or some other part of your system.

If your dump is large, I will bet that the additional time comes from reading data and sending it over the wire. You should mesure time consumed in the sending process (reading time before and after finishing sending).

If this is indeed the source of the additional time, you just have to remove that time from the next time to wait.

Example: Sending the previous block of data took 4s, the next block is 10s later, but as you allready consumed 4s, you just wait for 6s.

sleep is still a quite imprecise timer and obviously the above mechanism won't work if sending time is larger than delay between sendings, but you get the idea.

Correction sleep is not so bad in windows environment as it is in unixes. Accuracy of windows sleep is millisecond, accuracy of unix sleep is second. If you do not need high precision timing (and if network is involved high precision timing is out of reach anyway) sleep should be ok.

kriss
Source of Data is my Dump txt file.
Arman
A: 

Sleep function can take longer than requested, but never less. Use winapi timer functions to get one function called-back in a interval from now.

You could also use the windows task scheduler, but that's going outside programmatic standalone options.

jpinto3912