• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSTimer: serious drift in Time (in milliseconds)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSTimer: serious drift in Time (in milliseconds)


  • Subject: Re: NSTimer: serious drift in Time (in milliseconds)
  • From: Alastair Houghton <email@hidden>
  • Date: Fri, 10 Nov 2006 16:18:09 +0000

On 10 Nov 2006, at 15:43, Gilles Celli wrote:

Hello,

My app which acquires data every 5 seconds from a Multimeter (via USB port) seems to work fine.
However I remarked that there is a drift (milliseconds) in time when using NSTimer.


The app starts at a given time say 10:00:30,000 (hh:min:sec, millisec) and after 1 hour it loses about >500 millisec, and
finishes with 10:59:59,412.


What can be done to have an exact 5 second time interval ? Is this even possible with NSTimer ?

Maybe a time check with corrections should be done...but this gets complicated
compared to our UNIX based program which acquires exactly at the given time, by using gettimeofday();

If you're using NSTimer's ticks to measure time, you're misusing it. It's there to generate an event (or a stream of events) separated by *at least* the time given, but the time between events could easily be longer (and indeed usually will be).


If you're using it to periodically sample a value from your multimeter, what you need to do is record the current time (e.g. from gettimeofday()) at the same time as each sample is taken. Don't try to use the NSTimer to update some internal value of time, because it won't work.

If you want to sample at exactly 500ms, the best place to do this is external hardware, if possible; if your hardware supports it, configure it to sample at 500ms intervals and then whenever the timer fires, read-in any buffered data (remembering that you might have more than one sample waiting as the computer won't be exactly in synch.). If that isn't possible, you might be able to get better results using a high-priority thread and a sleep function (e.g. nanosleep()), but it still won't be 100% accurate for various reasons.

Kind regards,

Alastair.

--
http://alastairs-place.net


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >NSTimer: serious drift in Time (in milliseconds) (From: Gilles Celli <email@hidden>)

  • Prev by Date: NSTimer: serious drift in Time (in milliseconds)
  • Next by Date: Re: Creating an NSTimer subclass
  • Previous by thread: NSTimer: serious drift in Time (in milliseconds)
  • Next by thread: Re: NSTimer: serious drift in Time (in milliseconds)
  • Index(es):
    • Date
    • Thread