NSTimer question: How to fire at second 00, 05, 10 etc ?

  • Hi,

    I've a question about NSTimer:

    I've already set up a Cocoa program to get data from a Multimeter
    every 5 seconds but what I really want
    is to acquire data at second: 00, 05, 10, 15, 20, etc.

    Any ideas ?

    And has anyone any idea about the accuracy (in milliseconds) of
    NSTimer ?
    Are there any alternatives ?

    Thanks,

    Gilles Celli
  • On Oct 25, 2006, at 8:39 AM, Gilles Celli wrote:

    > Hi,
    >
    > I've a question about NSTimer:
    >
    > I've already set up a Cocoa program to get data from a Multimeter
    > every 5 seconds but what I really want
    > is to acquire data at second: 00, 05, 10, 15, 20, etc.
    >
    > Any ideas ?

    Just use one of the variants that takes a start date for the first
    firing, and compute the first fire date by taking the current time
    interval (since reference date), add small fudge factor (so it's not
    "too soon" in the future), round up to the next multiple of 5.0, and
    make a date from that.  Use that as the first fire date and an
    interval of 5.0.

    > And has anyone any idea about the accuracy (in milliseconds) of
    > NSTimer ?
    > Are there any alternatives ?

    Well if the program or system is busy doing something else when the
    fire date comes around, the firing will be delayed until the timer can
    be serviced by the run loop (in the program) and the thread can get
    onto a processor.  Also keep in mind that the computer's clock is a
    simulation of actual time: the computer has to guesstimate how long 5
    seconds actually is from its internal interval timers/etc, and outside
    forces like NTP can be adjusting the clock to make it change faster or
    slower than "normal".  For example, the computer can think that 5.0
    seconds have passed when only 4.9 seconds (measured by an accurate
    outside clock) have passed.  Those extra-NSTimer effects could end up
    being more interesting.

    Otherwise, just write a little test program that just prints the
    current time (probably as the reference time interval double, not as a
    date object, for more accuracy) in a method fired by an NSTimer, and
    see what happens.

    Chris Kane
    Cocoa Frameworks, Apple
  • On 10/25/06, Gilles Celli <gilles.celli...> wrote:

    > And has anyone any idea about the accuracy (in milliseconds) of
    > NSTimer ?

    In general you are looking at millisecond accuracy to 10s of
    millisecond accuracy but that can be affected by countless factors
    including how much work you are doing in your own application that may
    hold off the servicing of a timer when it fires.

    > Are there any alternatives ?

    What kind of accuracy are you looking for?

    -Shawn
  • On Oct 25, 2006, at 7:35 PM, Shawn Erickson wrote:

    > On 10/25/06, Gilles Celli <gilles.celli...> wrote:
    >
    >> And has anyone any idea about the accuracy (in milliseconds) of
    >> NSTimer ?
    >
    > In general you are looking at millisecond accuracy to 10s of
    > millisecond accuracy but that can be affected by countless factors
    > including how much work you are doing in your own application that may
    > hold off the servicing of a timer when it fires.
    >
    >> Are there any alternatives ?
    >
    > What kind of accuracy are you looking for?

    Perhaps a better question is, what are you trying to do?  There are
    various different reasons why you might want a periodic timer of this
    type, and some of them have additional requirements (e.g. latency,
    whether events *must* happen or whether they can be merged).  Also,
    for some uses of a periodic timer you can do a bit of the work up
    front to give yourself a latency buffer (this is the kind of thing
    you'd do for audio or video, for instance).

    For some tasks, you don't actually need great accuracy, since you can
    still use a measure of real time to calculate e.g. where an animation
    should be.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • > What kind of accuracy are you looking for?

    Well Real-Time (but I think it's not possible on Mac OS X) or Soft-
    RealTime (like SRT on Linux).

    On Oct 25, 2006, at 8:35 PM, Shawn Erickson wrote:

    > On 10/25/06, Gilles Celli <gilles.celli...> wrote:
    >
    >> And has anyone any idea about the accuracy (in milliseconds) of
    >> NSTimer ?
    >
    > In general you are looking at millisecond accuracy to 10s of
    > millisecond accuracy but that can be affected by countless factors
    > including how much work you are doing in your own application that may
    > hold off the servicing of a timer when it fires.
    >
    >> Are there any alternatives ?
    >
    > What kind of accuracy are you looking for?
    >
    > -Shawn
    >
  • On 10/25/06, Gilles Celli <gilles.celli...> wrote:
    >> What kind of accuracy are you looking for?
    >
    > Well Real-Time (but I think it's not possible on Mac OS X) or Soft-
    > RealTime (like SRT on Linux).

    Mac OS X has support for such things (THREAD_TIME_CONSTRAINT_POLICY)
    and the Mac OS X schedular can provide one of the more consistent low
    latency scheduling available on any desktop grade operating system
    that exist today. For example it is one of the reason the Core Audio
    can provide audio processing that you can use in a live (on stage)
    situations.

    With that said do you really need to go to this level of things? What
    is the sampling frequency of the capture device you are interfacing
    with?

    -Shawn
  • On 25-Oct-06, at 1:03 PM, Shawn Erickson wrote:

    >
    > Mac OS X has support for such things (THREAD_TIME_CONSTRAINT_POLICY)
    > and the Mac OS X schedular can provide one of the more consistent low
    > latency scheduling available on any desktop grade operating system
    > that exist today. For example it is one of the reason the Core Audio
    > can provide audio processing that you can use in a live (on stage)
    > situations.

    I don't believe it - I get stuttery audio all the time with Core
    Audio/iTunes/Etc on a loaded system...

    --jeffk++
  • > With that said do you really need to go to this level of things? What
    > is the sampling frequency of the capture device you are interfacing
    > with?
    >
    Maximum t=0.5 seconds (for another acquisition system)...

    On Oct 25, 2006, at 10:03 PM, Shawn Erickson wrote:

    > On 10/25/06, Gilles Celli <gilles.celli...> wrote:
    >>> What kind of accuracy are you looking for?
    >>
    >> Well Real-Time (but I think it's not possible on Mac OS X) or Soft-
    >> RealTime (like SRT on Linux).
    >
    > Mac OS X has support for such things (THREAD_TIME_CONSTRAINT_POLICY)
    > and the Mac OS X schedular can provide one of the more consistent low
    > latency scheduling available on any desktop grade operating system
    > that exist today. For example it is one of the reason the Core Audio
    > can provide audio processing that you can use in a live (on stage)
    > situations.
    >
    > With that said do you really need to go to this level of things? What
    > is the sampling frequency of the capture device you are interfacing
    > with?
    >
    > -Shawn
    >
  • On Oct 25, 2006, at 1:37 PM, Jeff Koftinoff wrote:

    > On 25-Oct-06, at 1:03 PM, Shawn Erickson wrote:
    >
    >>
    >> Mac OS X has support for such things (THREAD_TIME_CONSTRAINT_POLICY)
    >> and the Mac OS X schedular can provide one of the more consistent low
    >> latency scheduling available on any desktop grade operating system
    >> that exist today. For example it is one of the reason the Core Audio
    >> can provide audio processing that you can use in a live (on stage)
    >> situations.
    >
    > I don't believe it - I get stuttery audio all the time with Core
    > Audio/iTunes/Etc on a loaded system...

    Well, I don't think OS X provides a completely bulletproof solution
    to real-time threads. If you want something that absolutely cannot
    miss its schedule, no matter the load, you may not find it on OS X.
  • > Just use one of the variants that takes a start date for the first
    > firing, and compute the first fire date by taking the current time
    > interval (since reference date), add small fudge factor (so it's
    > not "too soon" in the future), round up to the next multiple of
    > 5.0, and make a date from that.  Use that as the first fire date
    > and an interval of 5.0.

    Thanks for the reply...but actually (as a newbie Cocoa-programmer) I
    tried it but couldn't figure it out (using NSDate ?)...if you have an
    example it would be great.

    Or what are the advantages to use NSTimer instad of checking the
    internal time and launch a requested method (it's what we do actually
    with
    our C-based UNIX program in the Terminal).

    On Oct 25, 2006, at 8:30 PM, Chris Kane wrote:

    > On Oct 25, 2006, at 8:39 AM, Gilles Celli wrote:
    >
    >> Hi,
    >>
    >> I've a question about NSTimer:
    >>
    >> I've already set up a Cocoa program to get data from a Multimeter
    >> every 5 seconds but what I really want
    >> is to acquire data at second: 00, 05, 10, 15, 20, etc.
    >>
    >> Any ideas ?
    >
    >
    > Just use one of the variants that takes a start date for the first
    > firing, and compute the first fire date by taking the current time
    > interval (since reference date), add small fudge factor (so it's
    > not "too soon" in the future), round up to the next multiple of
    > 5.0, and make a date from that.  Use that as the first fire date
    > and an interval of 5.0.
    >
    >> And has anyone any idea about the accuracy (in milliseconds) of
    >> NSTimer ?
    >> Are there any alternatives ?
    >
    >
    > Well if the program or system is busy doing something else when the
    > fire date comes around, the firing will be delayed until the timer
    > can be serviced by the run loop (in the program) and the thread can
    > get onto a processor.  Also keep in mind that the computer's clock
    > is a simulation of actual time: the computer has to guesstimate how
    > long 5 seconds actually is from its internal interval timers/etc,
    > and outside forces like NTP can be adjusting the clock to make it
    > change faster or slower than "normal".  For example, the computer
    > can think that 5.0 seconds have passed when only 4.9 seconds
    > (measured by an accurate outside clock) have passed.  Those extra-
    > NSTimer effects could end up being more interesting.
    >
    > Otherwise, just write a little test program that just prints the
    > current time (probably as the reference time interval double, not
    > as a date object, for more accuracy) in a method fired by an
    > NSTimer, and see what happens.
    >
    >
    > Chris Kane
    > Cocoa Frameworks, Apple
    >
    >
  • On Oct 26, 2006, at 2:46 AM, Gilles Celli wrote:

    >> Just use one of the variants that takes a start date for the first
    >> firing, and compute the first fire date by taking the current time
    >> interval (since reference date), add small fudge factor (so it's
    >> not "too soon" in the future), round up to the next multiple of
    >> 5.0, and make a date from that.  Use that as the first fire date
    >> and an interval of 5.0.
    >
    > Thanks for the reply...but actually (as a newbie Cocoa-programmer) I
    > tried it but couldn't figure it out (using NSDate ?)...if you have
    > an example it would be great.

    Here's one:This particular example uses a non-periodic timer to correct for
    skews and drifts due to NTP, computational error, and other factors.
    I changed it to fire at multiples of 5 seconds.

    > Or what are the advantages to use NSTimer instad of checking the
    > internal time and launch a requested method (it's what we do
    > actually with
    > our C-based UNIX program in the Terminal).

    Well you didn't tell the group what the context was, so we couldn't
    say anything about that.  What are you doing when you're not checking
    the time or acquiring the data, for example?

    If you have a UI app (since you mention Cocoa), you should use an
    NSTimer, and that will allow the UI to stay responsive to user input
    events.

    You could also spawn off a thread do a while (1) {sleep(5);
    collect_data();} loop in it, but if you've never used threads before,
    don't do that.  Or find a book on threads to read first.

    Chris Kane
    Cocoa Framework, Apple

    > On Oct 25, 2006, at 8:30 PM, Chris Kane wrote:
    >
    >> On Oct 25, 2006, at 8:39 AM, Gilles Celli wrote:
    >>
    >>> Hi,
    >>>
    >>> I've a question about NSTimer:
    >>>
    >>> I've already set up a Cocoa program to get data from a Multimeter
    >>> every 5 seconds but what I really want
    >>> is to acquire data at second: 00, 05, 10, 15, 20, etc.
    >>>
    >>> Any ideas ?
    >>
    >>
    >> Just use one of the variants that takes a start date for the first
    >> firing, and compute the first fire date by taking the current time
    >> interval (since reference date), add small fudge factor (so it's
    >> not "too soon" in the future), round up to the next multiple of
    >> 5.0, and make a date from that.  Use that as the first fire date
    >> and an interval of 5.0.
    >>
    >>> And has anyone any idea about the accuracy (in milliseconds) of
    >>> NSTimer ?
    >>> Are there any alternatives ?
    >>
    >>
    >> Well if the program or system is busy doing something else when the
    >> fire date comes around, the firing will be delayed until the timer
    >> can be serviced by the run loop (in the program) and the thread can
    >> get onto a processor.  Also keep in mind that the computer's clock
    >> is a simulation of actual time: the computer has to guesstimate how
    >> long 5 seconds actually is from its internal interval timers/etc,
    >> and outside forces like NTP can be adjusting the clock to make it
    >> change faster or slower than "normal".  For example, the computer
    >> can think that 5.0 seconds have passed when only 4.9 seconds
    >> (measured by an accurate outside clock) have passed.  Those extra-
    >> NSTimer effects could end up being more interesting.
    >>
    >> Otherwise, just write a little test program that just prints the
    >> current time (probably as the reference time interval double, not
    >> as a date object, for more accuracy) in a method fired by an
    >> NSTimer, and see what happens.
    >>
    >>
    >> Chris Kane
    >> Cocoa Frameworks, Apple
    >>
    >>
    >
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today