[squeakland] Re: Tick Rate not accurate

[Bert Freudenberg]

Hi Steve,

I'm taking the discussion from the tracker to the mailing list ...

>> URL: http://tracker.squeakland.org/browse/SQ-708
>> Reporter: Stephen Thomas
>>  
>> Saw problems with Tick Rate while running random number tests. Created a simple project (see attached)
>> to check tick rate by having a script to increment a counter and another to start it and then stop it after N seconds.  Below are some of the results
>> Tick Rate - Counter Value After 10 seconds
>> 1 - 10
>> 2 - 20
>> 5 - 50
>> 8 - 72
>> 10 - 98
>> 25 - 230
>> 50 - 384-405
>> 100 - 500
>> Also ran at tick rate of 100/sec for 100 seconds and got counter values of 4975 to 5000
> 
> Etoys is not a real-time system. The ticking rate is the desired number of script executions per second. The actual number can be lower depending on how much else is going on. Faster machines will run closer to the desired number of ticks, slower machines less so.

To expand on this:

The default rate is set to only 8 ticks per second to allow more objects to be animated at that rate. This is not "smooth", but then, the major purpose of Etoys is not pretty animation, but learning how things work (*).

Etoys is limited to a rate of 50 frames per second by default (we developers call that "world cycles"). That means it checks at most 50 times per seconds if scripts should be run. If it finds any that are due, it executes those scripts, and then redraws the screen. This may take well more than 20 ms, so there will be less than 50 world cycles per second.

That's the reason you don't get more than 500 ticks in 10 seconds no matter the tick rate.

Just for fun, look at the current frame rate by dragging out a "FrameRate" counter from the Object Catalog's "Just For Fun" category. This lets you see how various operations affect the frame rate. E.g., make a big object rotate, and then duplicate it a few times.

Enabling the "higherPerformance" preference removes the 50 fps cap. This basically has no effect on e.g. the OLPC XO-1 (except for draining the battery even more), because it can barely keep up even 50 fps. On faster machines you'll see the frame rate go up to hundreds of fps. If the system load is otherwise low, you'll get pretty accurate ticking, but again because sampling is involved, it's not guaranteed to be accurate. Having the 50 fps cap in place makes the timings actually more consistent over a wider range of machines.

So, long story short, you cannot use the tickings for accurate timing. If you let us know what you actually need this for, I'm sure we can find a way to help you :)

- Bert -

(*) I tend to forget that myself. E.g. my cars-on-an-intersection project works really nicely on my home machine, but rather poorly on slower machines - the cars don't even make it across the intersection in one light cycle:
http://squeakland.org/showcase/project.jsp?id=9655
That's because I increased the tick rate of the cars to get smoother animation. Not a good idea in this case. The light ticks independently of the cars, so on slower machines you get many less car ticks per light tick than on a fast machine. The light advances when the car has barely reached the middle of the intersection.
This could be worked around by having only a single ticking script in the world that would trigger all other scripts at appropriate intervals. That would guarantee much more reproducible behavior independent of the computer speed.