[squeakland] Re: Tick Rate not accurate

[Steve Thomas]

Bert, thanks for the explanation.

So if the default max Tick Rate is 50, should remove 100 from the list of
selectable tick rates?

"Other..." still makes sense (especially 0.1 for ticking every 10 seconds),
but we should have some warning so folks know the limitations. The warning
could be when you select Other in the dialog box that pops up. ex: "Max Rate
is 50 per second, can change in preferences").

My major purpose for using Etoys is playing around ;) no specific need at
this point in time. I noticed the problem when running Randy's Dice Roll
project and was simply trying to figure out how things worked.

Stephen

On Wed, Jun 2, 2010 at 6:46 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> 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._______________________________________________
> squeakland mailing list
> squeakland at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/squeakland
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakland.org/pipermail/squeakland/attachments/20100602/d689b75c/attachment.html