[squeak-dev] Delay time question

> I compared with Jon Hylands and discovered a big difference between my
>  Ubuntu and his Windows results.
>
>  Time millisecondsToRun: [10 timesRepeat: [(Delay forMilliseconds: 1000)
>  wait]] 10015
>
>  Time millisecondsToRun: [100 timesRepeat: [(Delay forMilliseconds: 100)
>  wait]]  10015
>
>  Time millisecondsToRun: [1000 timesRepeat: [(Delay forMilliseconds: 10)
>  wait]]  13405
>
>  Time millisecondsToRun: [10000 timesRepeat: [(Delay forMilliseconds: 1)
>  wait]]  45728
>
>  He did the third test and got something like 10250 instead of my 13405.
>
>  Is this behavior well-known and understood or is there something wrong
>  with my install?
>
>  Thanks for any help.  It's a big problem for my robot (and therefore me)
>  at the moment.
>

> On Feb 27, 2008, at 9:50 PM, Robert F. Scheer wrote:
>
> > Time millisecondsToRun: [1000 timesRepeat: [(Delay forMilliseconds:  
> > 10)
> > wait]]  13405
> >
> > Time millisecondsToRun: [10000 timesRepeat: [(Delay forMilliseconds:  
> > 1)
> > wait]]  45728
>
> For the curious the os-x carbon vm does
>
> Time millisecondsToRun: [1000 timesRepeat: [(Delay forMilliseconds:  
> 10) wait]]  10196
>
> Time millisecondsToRun: [10000 timesRepeat: [(Delay forMilliseconds:  
> 1) wait]]  100916
>
> The place you need to look at is your platform's
>
> int ioRelinquishProcessorForMicroseconds(int microSeconds) {
> /* This operation is platform dependent. */
>
>
> Yes very platform dependent, and VM flavour dependent.
>
> When you do the code above you really are saying gee let's sleep alot.  
> Then ioRelinquishProcessorForMicroseconds
> runs to judge when next best to wake up to service the end of the  
> Delay.  Also on unix if  the operating system says the increment for  
> process switch
> is oh 10 milliseconds then why you cannot actually sleep for 1 ms.
>
> Time to break out the debugger and your source code reader and  
> carefully examine what ioRelinquishProcessorForMicroseconds()
> is doing.
>
> In the far past we would just put the VM to sleep for 10 ms or 1 ms,  
> but a few years back I changed that to put the vm to sleep upto the  
> next point where it needed to wake up (we know that because we know at  
> what time delays will trigger in the future). Tempering that is code  
> that aborts the sleep if a keyboard/file handle/someting interrupt  
> comes in, so  that can be serviced right away.
>
> --
> =
> =
> =
> ========================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>

> 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
>
>

> 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.
>

> 2008/2/28 Andreas Raab <[hidden email]>:
> > 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.
> >
> Here the numbers for HydraVM.
>  a SortedCollection(895->2 91->1 14->3)

>
> It can't be so precise as old VM, because delay timeouts are signaled
> in separate thread as event, which is then
> consumed by Interpreter as soon as possible, but it takes a little
> more time (switching threads e.t.c).
> Things can be more precise on multicore system.
>
> I had a hard time fighting with delays lately.. what i can say.. this
> is one of the weakest and critical points in VM and language side.
>
> >  Cheers,
> >    - Andreas
> >
>

> 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
>

>
>  On Thu, 2008-02-28 at 07:59 +0200, Igor Stasenko wrote:
>  > 2008/2/28 Andreas Raab <[hidden email]>:
>  > > 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.
>  > >
>  > Here the numbers for HydraVM.
>  >  a SortedCollection(895->2 91->1 14->3)
>
>  How does this compare to standard VM on your OS?
>

>      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.
>

> 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 <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> =
> =
> =
> ========================================================================
>
>
>
>

> Robert F. Scheer wrote:
> > 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.
>
> I am not sure why your architecture has to change dramatically as a
> result. If your main problem is to make sure that that a loop is done
> every 20msecs and you need to adjust for statistical delay variations,
> you can simply compute the actual time the wait took and do something like:
>
>   nextDesiredTick := Time millisecondClockValue + 20.
>   [true] whileTrue:[
>     self doControl.
>     "note: for very, very long doControl the waitTime could be negative.
>      you have to decide whether it's better to skip or to run an extra
>      doControl in this case."
>     waitTime := nextDesiredTick - Time millisecondClockValue.
>     (Delay forMilliseconds: waitTime) wait.
>     "Next desired tick is twenty msecs from last one"
>     nextDesiredTick := nextDesiredTick + 20.
>   ].
>
> Not only will this adjust to statistical variations in delay but it will
> also take into account the amount of time spent in doControl, including
> eventual time spent in other processes due to preemption. In other
> words, the above is as close to 20msecs as it possibly gets.
>

> Picture 5 serial lines.  Each has a packet of a few to a few dozen bytes
> arriving every 20ms although they are not synchronous.  The data arrives
> on time within a few microseconds every cycle and it must be captured.  
>
> I was trying to use delays of around 15ms to prevent the Squeak i/o
> processes from continuously tying up compute cycles trying to read the
> serial lines when no data was expected.  Read a packet, delay 15ms, then
> go into a tighter loop trying every 1ms until the packet was read.  
>
> Now, I know this is a bad scheme.  Even a 1ms programmed delay could
> become longer than 20ms sometimes.  So let's get rid of all programmed
> delays inside the serial i/o loops.