• 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: Timing / Scheduling issues / screensaver
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Timing / Scheduling issues / screensaver


  • Subject: Re: Timing / Scheduling issues / screensaver
  • From: Jean Suisse <email@hidden>
  • Date: Tue, 04 Nov 2014 23:19:14 +0100

Now I think about it, OS X may no longer consider the app to be in the foreground when the screensaver kicks in or when the display is put to sleep. That would make sense for AppNap to kick in as soon as the display becomes unavailable in any way. Is that correct?

Jean
-----------
Jean Suisse

Institut de Chimie Moléculaire de l’Université de Bourgogne
(ICMUB) — UMR 6302



On Nov 4, 2014, at 23:16 , Jean Suisse <email@hidden> wrote:

That’s what I thought in the first place, but the documentation states:

An app is considered to be a candidate for sleep if:

• It is not visible—if all of an app’s windows are either hidden by other windows or minimized in a hidden dock, and the app is not in the foreground

[…]

When all of these conditions are met, OS X may put the app to sleep.

In my situation, the app is most definitely in the foreground, running one serial queue and has one window open displaying a large graphic updated on the main thread each time new data points are collected (so, once every second).

I guess I could place a call to beginActivityWithOptions:reason: in applicationDidFinishLaunching: with these options: (NSActivityIdleSystemSleepDisabled | NSActivitySuddenTerminationDisabled | NSActivityAutomaticTerminationDisabled | NSActivityUserInitiated). Do I need a NSActivityLatencyCritical to be on the safe side? The app is the “only one” running on the MAC and there is “no user”. It is purely a data acquisition computer, always connected to a power source.

Jean
-----------
Jean Suisse

Institut de Chimie Moléculaire de l’Université de Bourgogne
(ICMUB) — UMR 6302





On Nov 4, 2014, at 18:42 , Shantonu Sen <email@hidden> wrote:

Sounds like your app is being App Napped

https://developer.apple.com/library/mac/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/AppNap/AppNap.html
https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html#//apple_ref/doc/uid/TP40013207-CH100
https://developer.apple.com/library/ios/releasenotes/Foundation/RN-Foundation/

Shantonu

On Nov 4, 2014, at 9:35 AM, Jean Suisse <email@hidden> wrote:

Dear All,

This is a borderline question, but I figured darwin-kernel was the most suited list. Please feel free to recommend any other list you deem more appropriate.

I just finished upgrading a cocoa data acquisition from non-ARC, C++, Obj-C, OS X 10.8 to ARC, C++, Obj-C, Swift, OS X 10.10.
At the heart of the application are blocks dispatched on a serial queue. Some are short-lived and perform simple tasks like mechanical parts actuation, hardware initialization, etc… other are long-lived (several days / weeks) and perform data acquisition.

Data acquisition consists in interrogating devices connected to a MacBook Pro (mid 2012) through RS-485 (FTDI chip) every second. I have implemented the synchronization this way :

1. Get mach_absolute_time()     (→start)
2. Query all instruments to get the data
3. Get mach_absolute_time()  (→end)
4. usleep() for 1s + start – end

Actual implementation uses nanoseconds or microseconds when appropriate and requires a call to mach_timebase_info(). I am aware there may be “better” options such as using a dispatch source but the accuracy I get this way is more than satisfactory (better than 100 µs) and this design allows me to focus on the “block” design, to build scientific experiments.

The issue I would like to discuss is that after a certain time, my app goes from taking one measurement every second (give or take a maximum of 50 µs) to taking one measurement every 41.000000 seconds exactly.

This happens when the screen saver starts or when the display goes to sleep and only on 10.10, not on 10.8. I can’t test 10.9 for now.
The computer is configured not to sleep (Energy Saver preferences). When either Display sleep (Energy Saver preferences) and/or the screen saver (Desktop & screen saver preferences) are triggered, measurements periods increase from 1 s ± 50 µs  to  21 s ± 50 µs (for about 10-15 s)  then to  41.000000 s for hours with exceptional periods of 600-700 s.

I know that minor “imprecisions” come with using sleep(), but 41 seconds is that’s beyond imprecise. So, what’s different about 10.10? How can I reliably sleep for 500 – 800 ms  without burning the screen (I am planning a 9000 hours long experiment).

Best regards,
Jean
-----------
Jean Suisse

Institut de Chimie Moléculaire de l’Université de Bourgogne
(ICMUB) — UMR 6302




Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Timing / Scheduling issues / screensaver (From: Jean Suisse <email@hidden>)
 >Re: Timing / Scheduling issues / screensaver (From: Shantonu Sen <email@hidden>)
 >Re: Timing / Scheduling issues / screensaver (From: Jean Suisse <email@hidden>)

  • Prev by Date: Re: Timing / Scheduling issues / screensaver
  • Next by Date: file changes content but ContentModificationDate not changing
  • Previous by thread: Re: Timing / Scheduling issues / screensaver
  • Next by thread: Re: Timing / Scheduling issues / screensaver
  • Index(es):
    • Date
    • Thread