os-x carbon
  a SortedCollection(830->10 149->11 13->1 6->12 1->13 1->14)

well but it depends on the unix code to do things and that's a bit  
fuzzy at time, mind Andreas example below led to many sleepless
hours...  If you peek at the mac code it did at one time do this which  
gave 99.9% accuracy.

     err = pthread_mutex_lock(&gSleepLock);
     err =  
pthread_cond_timedwait_relative_np 
(&gSleepLockCondition,&gSleepLock,&tspec);	
     err = pthread_mutex_unlock(&gSleepLock);

But then someone reported dropped socket accepts because the  
pthread_cond_timedwait_relative_np would fail to service the
Socket requests and I had to revert to Ian's unix code, which on os-x  
is less accurate but better than some unix machines.

 From emails from 2002 Ian said.

NetBSD ppc:
a SortedCollection(950->20 19->19 19->21 3->18 3->22 2->30 1->25 1->8
1->10 1->14)

Linux 386:
a SortedCollection(294->1 213->2 146->3 100->4 84->5 55->6 33->7 33->8
11->10 9->11 8->9 6->13 5->12 1->14 1->17 1->18)

I noted
3.2.7b4 Mac VM gives
a SortedCollection(533->2 278->3 46->23 31->24 24->22 21->1 15->4 11- 
 >21 8->5 6->25 4->26 3->27 2->6 2->14 2->18 2->28 2->35 2->42 2->43 1- 
 >12 1->15 1->20 1->29 1->41 1->47)



On Feb 27, 2008, at 9:37 PM, Andreas Raab wrote:

> Robert F. Scheer wrote:
>> Is this behavior well-known and understood or is there something  
>> wrong
>> with my install?
>
> This is a very well known issue. Different operating systems have  
> very different minimal timer resolutions. Generally speaking, on  
> Windows and Mac OS the timer resolution is very close to 1ms whereas  
> most Linux kernels have *awful* timer resolutions. I have been told  
> that you can recompile your kernel to fix it but I'm not sure how.  
> The classic benchmark to verify your timer accuracy is to do  
> something like here:
>
> 	delay := Delay forMilliseconds: 1.
> 	bag := Bag new.
> 	1000 timesRepeat:[bag add: [delay wait] timeToRun].
> 	bag sortedCounts
>
> On my box it yields "a SortedCollection(941->1 51->2 8->3)" which  
> means that 94.1% of the delays are true 1msec delays.
>
> Cheers,
>  - Andreas
>

--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================