On Mon, 11 Mar 2002, Andreas Raab wrote:

> Check the millisecond accuracy. Question 1 is what do you get when run
> something like:
> 
> | bag time |
> bag := Bag new.
> time := Time millisecondClockValue.
> 1 to: 1000 do:[:i|
> 	[Time millisecondClockValue = time] whileTrue.
> 	bag add: (Time millisecondClockValue - time).
> 	time := Time millisecondClockValue.
> ].
> bag sortedCounts
> 
> This will give you the "raw" timer accuracy.

On Linux (PIII/600) I get

 (995->1 3->2 1->3 1->4)

which is not too bad, right?

> However, even if you get
> 1msec here that's only the first part of the problem. The second is what
> happens when you run:
> 
> | bag time delay |
> delay := Delay forMilliseconds: 1.
> bag := Bag new.
> 1 to: 1000 do:[:i|
> 	time := Time millisecondClockValue.
> 	delay wait.
> 	bag add: (Time millisecondClockValue - time).
> ].
> bag sortedCounts

But this one gives

 (778->10 110->9 18->7 16->2 15->8 13->13 12->1 10->11 9->5 8->3 7->6 3->4 1->14)

which looks really bad - or is my machine just too slow?

0 tinyBenchmarks '48632218 bytecodes/sec; 1671345 sends/sec'

> I noticed that even after fixing the raw timer accuracy, the second one
> still lagged. The solution I found was to use an OS timer callback which
> had to reset the interruptCheckCounter in order to force a check for
> pending delay timeouts. This slightly decreases general performance
> (since you're checking 1000 times/sec) but it was less then 1% and gives
> very exact results. It turns out that after these changes I was able to
> _drastically_ reduce the sound player's buffer size without noticable
> distortion.

Hmm, this might be a desirable option for the Unix VM ...

-- Bert