Thanks for the most useful responses on this question of delay timing.  

It's clear that the robot program architecture must change drastically
as a result.  Currently, there are perhaps 10 concurrent processes
looping 50 times per second servicing various serial lines carrying
sensor information or actuating motors and so forth.  Although real time
processing isn't required, it is mandatory that all processes and the
main decision loop complete every 20ms, no matter what.

It seems like the best approach is to split the serial handlers outside
of Squeak, which I can do in C without too much hassle.  The question
becomes, if the interfaces with Squeak transform to sockets and all the
concurrent loops in Squeak reduce to one single loop, polling each
socket in turn, would that complete within 20ms no matter what or are
there similar problems with statistical delays involved with sockets?

I'll talk to Jon Hylands tomorrow and hope he'll save the Squeak but at
this point I'm trying to avoid the quick reaction (some might say panic)
that I just need to go back and do it all over in C.

Thanks for your very quick and understanding replies.  This is the most
helpful community I've seen online.  

- Robert

On Wed, 2008-02-27 at 22:13 -0800, John M McIntosh wrote:
> 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
> = 
> = 
> = 
> ========================================================================
> 
> 
> 
>