<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">OS X does timer coalescing to improve battery life. Sleep(1) is not guaranteed to be one second on battery.<div><br></div><div><a href="http://www.apple.com/osx/advanced-technologies/">http://www.apple.com/osx/advanced-technologies/</a></div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Greg</div><div><br><div><div>On Jan 1, 2014, at 3:57 AM, Rainer Joswig <<a href="mailto:joswig@lisp.de">joswig@lisp.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Btw., my Macbook Air ran on battery for these tests.<div><br></div><div><br><div><div>Am 01.01.2014 um 12:55 schrieb Jeff Caldwell <<a href="mailto:jcaldwell@clozure.com">jcaldwell@clozure.com</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">I ran your dotimes example on a 2011 MacBook Pro running 10.9.1 and CCL Version 1.10-dev-r15974M-trunk (DarwinX8664). The average run time was around 100.07 seconds, ranging from 100.05 to 100.09 seconds. I had CCL running in an Emacs window in tmux and was connected to CCL via slime-connect in Emacs for OS X. Neither Emacs window was on display during most of the run.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 1, 2014 at 6:36 AM, Rainer Joswig <span dir="ltr"><<a href="mailto:joswig@lisp.de" target="_blank">joswig@lisp.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">This is what I see on my 2012 Macbook Air with Mac OS X 10.9.1. iTunes was running in the background. Most of the time CCL was not the front application and its windows were hidden behind Apple Mail.<div>
<br></div><div><br></div><div><div>Welcome to Clozure Common Lisp Version 1.8-store-r15418 (DarwinX8664)!</div><div class="im"><div>? (dotimes (i 5)</div><div>(time (dotimes (i 100)</div><div> (sleep 1))))</div><div>
(DOTIMES (I 100) (SLEEP 1))</div></div><div>took 100,110,658 microseconds (100.110660 seconds) to run.</div><div class="im">During that period, and with 4 available CPU cores,</div><div> 149,869 microseconds ( 0.149869 seconds) were spent in user mode</div>
<div> 48,910 microseconds ( 0.048910 seconds) were spent in system mode</div><div> 1,066 minor page faults, 5 major page faults, 0 swaps.</div><div class="im">(DOTIMES (I 100) (SLEEP 1))</div><div>took <b>130,075,484</b> microseconds (130.075490 seconds) to run.</div>
<div class="im">During that period, and with 4 available CPU cores,</div><div> 67,339 microseconds ( 0.067339 seconds) were spent in user mode</div><div> 32,443 microseconds ( 0.032443 seconds) were spent in system mode</div>
<div> 1,335 minor page faults, 3 major page faults, 0 swaps.</div><div class="im">(DOTIMES (I 100) (SLEEP 1))</div><div>took <b>131,043,588 </b>microseconds (131.043580 seconds) to run.</div><div class="im">
During that period, and with 4 available CPU cores,</div><div> 76,666 microseconds ( 0.076666 seconds) were spent in user mode</div><div> 32,517 microseconds ( 0.032517 seconds) were spent in system mode</div>
<div> 1,076 minor page faults, 3 major page faults, 0 swaps.</div><div class="im">(DOTIMES (I 100) (SLEEP 1))</div><div>took <b>137,310,368</b> microseconds (137.310360 seconds) to run.</div><div class="im">
During that period, and with 4 available CPU cores,</div><div> 109,781 microseconds ( 0.109781 seconds) were spent in user mode</div><div> 40,377 microseconds ( 0.040377 seconds) were spent in system mode</div>
<div> 588 minor page faults, 3 major page faults, 0 swaps.</div><div class="im">(DOTIMES (I 100) (SLEEP 1))</div><div>took 100,122,436 microseconds (100.122430 seconds) to run.</div><div class="im"><div>During that period, and with 4 available CPU cores,</div>
</div><div> 93,868 microseconds ( 0.093868 seconds) were spent in user mode</div><div> 36,627 microseconds ( 0.036627 seconds) were spent in system mode</div><div> 577 minor page faults, 3 major page faults, 0 swaps.</div>
<div>NIL</div><div><br></div><div><br></div><div><br></div><div><div>Am 01.01.2014 um 01:59 schrieb Gary Byers <<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>>:</div><div><div class="h5"><br><blockquote type="cite">
I can't reproduce this on a fairly recent version of the CCL trunk and<br>OSX 10.9.0; I haven't yet "upgraded" to 10.9.1. I find that (SLEEP 1) takes<br>very slightly more than 1 second; I've seen TIME claim that (SLEEP 10) takes<br>
very slightly less than 10 seconds, but I assume that the small discrepancy<br>there has to do with slight differences between clock sources. I tried this<br>both running CCL in the shell and running under the Cocoa IDE; I got essentially<br>
the same results in both cases and don't remember any recent CCL change that<br>would explain the results that you're seeing.<br><br>There's usually some latency involved: the calling thread can wake up after<br>
having slept for the specified time interval, but it may be a little while<br>before the OS actually wakes it up. If there's a very heavy load on the system<br>(lots of other threads running) this latency will be higher than it would be<br>
otherwise, but if system load was causing the results that you're seeing you'd<br>likely be very aware of that (everything would have slowed to a dead crawl.)<br><br>On Unix-based systems, SLEEP is implemented in terms of the #_nanosleep system<br>
call; the OSX implementation of #_nanosleep has had a bug off and on since OSX<br>10.5, and (until around 2 years ago) CCL's attempts to work around that bug<br>sometimes made things worse. (If #_nanosleep is interrupted by a signal before<br>
the timeout is reached, it's supposed to return a value indicating that that<br>had happened and optionally another value which indicated how much time was remaining; on OSX, if #_nanosleep was interrupted after the scheduled<br>
deadline, it claimed that it was interrupted and that a small negative<br>amount of time remained. The field in the data structure was unsigned,<br>so the "small negative remaining time" was interpreted as a very large<br>
positive remaining time, and retrying the #_nanosleep effectively slept<br>forever.) I don't think that that's been present in the last few OSX<br>releases and I think that current versions of CCL work around it correctly.<br>
<br>So: it took me a while to say it, but I can't reproduce the problem and don't<br>have a good guess as to what it might be.<br><br><br><br>On Tue, 31 Dec 2013, Park SungMin wrote:<br><br><blockquote type="cite">
in Mavericks(OS X 10.9)? I call sleep function..(in CCL IDE and slime(require ?cocoa))<br>(sleep 1)? sometime sleep to over 10 seconds,?<br>?also, NSTimer sometime have long interval in repeats.<br><br>so I tested it?. is it bug? Thanks.<br>
<br><br>Welcome to Clozure Common Lisp Version 1.10-dev-r15993M-trunk (DarwinX8664)!<br>? (dotimes (i 5)<br>(time (dotimes (i 100)<br> (sleep 1))))<br><br>(DOTIMES (I 100) (SLEEP 1))<br>took 310,040,206 microseconds (310.040200 seconds) to run.<br>
During that period, and with 4 available CPU cores,<br> 121,045 microseconds ( 0.121045 seconds) were spent in user mode<br> 40,618 microseconds ( 0.040618 seconds) were spent in system mode<br>2,119 minor page faults, 3 major page faults, 0 swaps.<br>
<br>(DOTIMES (I 100) (SLEEP 1))<br>took 297,074,248 microseconds (297.074250 seconds) to run.<br>During that period, and with 4 available CPU cores,<br> 95,682 microseconds ( 0.095682 seconds) were spent in user mode<br>
32,199 microseconds ( 0.032199 seconds) were spent in system mode<br>2,327 minor page faults, 6 major page faults, 0 swaps.<br><br>(DOTIMES (I 100) (SLEEP 1))<br>took 450,511,262 microseconds (450.511260 seconds) to run.<br>
During that period, and with 4 available CPU cores,<br> 85,223 microseconds ( 0.085223 seconds) were spent in user mode<br> 32,064 microseconds ( 0.032064 seconds) were spent in system mode<br>2,588 minor page faults, 9 major page faults, 0 swaps.<br>
<br>(DOTIMES (I 100) (SLEEP 1))<br>took 361,880,357 microseconds (361.880340 seconds) to run.<br>During that period, and with 4 available CPU cores,<br> 83,736 microseconds ( 0.083736 seconds) were spent in user mode<br>
24,041 microseconds ( 0.024041 seconds) were spent in system mode<br>1,110 minor page faults, 4 major page faults, 0 swaps.<br><br>(DOTIMES (I 100) (SLEEP 1))<br>took 453,001,014 microseconds (453.001040 seconds) to run.<br>
During that period, and with 4 available CPU cores,<br> 103,395 microseconds ( 0.103395 seconds) were spent in user mode<br> 24,570 microseconds ( 0.024570 seconds) were spent in system mode<br>958 minor page faults, 1 major page faults, 0 swaps.<br>
<br><br><br>_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com" target="_blank">Openmcl-devel@clozure.com</a><br><a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br>
<br><br></blockquote>_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com" target="_blank">Openmcl-devel@clozure.com</a><br><a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br>
</blockquote></div></div></div><br></div></div><br>_______________________________________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/listinfo/openmcl-devel</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div>_______________________________________________<br>Openmcl-devel mailing list<br><a href="mailto:Openmcl-devel@clozure.com">Openmcl-devel@clozure.com</a><br>http://clozure.com/mailman/listinfo/openmcl-devel<br></blockquote></div><br></div></body></html>