On 2013/07/26, at 22:06, Ken Thomases <[email protected]> wrote:

> On Jul 25, 2013, at 11:37 PM, [email protected] wrote:
> 
>> On Jul 26, 2013, at 12:09 PM, Ken Thomases <[email protected]> wrote:
>> 
>>> Also, the above code doesn't adjust the timer to fire on the second as Rick 
>>> suggested.  You're asking it to fire every so many seconds (delayInSeconds) 
>>> but you aren't specifying when during the second to fire.  Rather than 
>>> passing 0 as the second parameter of dispatch_walltime(), you should 
>>> compute an adjustment to try to get close to a whole second.  Since 
>>> dispatch_walltime() uses gettimeofday() when you pass NULL for the first 
>>> parameter, I'd use that same call to fill in a timeval structure and then 
>>> pass NSEC_PER_SEC - (tp.tv_usec * NSEC_PER_USEC) as the second parameter.
>>> 
>>> Regards,
>>> Ken
>> Thanks Ken, no I hadn't yet bothered to do this, as dispatch_walltime() was 
>> initially close enough to work on the other bits of the app.
>> It would make a difference to reduce some lag.
>> What is the part in the second parameter your are doing there…
>>> NSEC_PER_SEC - (tp.tv_usec * NSEC_PER_USEC)
>> Looks like something to adust it but what is tp.tv_usec ?
> 
> I hypothesized a struct timeval variable named "tp" that you passed to 
> gettimeofday().  Then you would use the sub-second part (the tv_usec field) 
> to figure out roughly how far off of a whole second dispatch_walltime() would 
> be when passed NULL for the first parameter, since it will also use 
> gettimeofday().
> 
> Regards,
> Ken
> 
Ok so I went and looked at sys/time.h and friends and the man page for 
gettimeofday()
And now understand how this struct works. 
It's literally the same as the NSDate method timeIntervalSince1970
The only difference is NSTimeInterval is representing the values if these 
struct fields as the respective sides of the decimal point. 
I grok this. 
If I want to fire my timer at the second, just supply a tp with tp.tv_usec as 
zero.
If I could verify any consistent lag under load I could offset my timer to fire 
slightly early to compensate for the lag. 
I get it. Awesome. 
But with that in mind, if I care or if the lag becomes significant enough per 
analog clock displayed for given time zones , then I will measure how the lag 
increases per additional displayed clock I add. 
I'll get the rest if the thing built now the way I want it and save this 
optimization for last. 

Thanks Ken, you set me on the right track. 
_______________________________________________

Cocoa-dev mailing list ([email protected])

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to