Re: after ids (Helmut Giese)

[Helmut Giese]

>Donal K. Fellows wrote
>While I could always see how to do it with single sets of timers, I
>could never work out how to do it reliably with multiple event
>sequences on different scales (e.g. a 13ms interval and a 1s interval)
>where the event processing takes an appreciable time w.r.t. the
>shorter intervals. Which happens for sure when using, say, Tk; redraws
>are quite expensive. With each pending timer event assigned an
>absolute time at which it becomes eligible for execution, it's pretty
>simple to handle. But without it...

Could well be, that I am way off of what is discussed here, but what I
understood seems rather easy to realize (at least on PC hardware).
Here's the idea:
Any reasonably recent PC hardware has a free running 64 bit timer
(sometimes called the Multi Media Timer) - since Pentium 1 IIRC.
There are 2 system calls:
- Query this timer's frequency (QueryPerformanceFrequency) and
- get its current count (QueryPerformanceCounter).

On startup Tcl would ask for the frequency and would once calculate the
number of timer ticks to a millisecond.
Now someone comes along and wants to be notified after 10 msec. Ok,
Tcl gets the current timer value, adds the appropriate value for 10 ms and
puts the timeout value into a list.
1 msec later someone else comes around and asks for a delay of 3 msec.
Tcl does the same and (this would be a micro-optimisation) orders the list, so
that the new event is placed _before_ the one from step 1.

At any moment when Tcl wants to check if any timer event has expired, it walks
the list and notifies any caller whose time has expired (stopping at the
first time
which is still in the future, if the list is ordered).

There would be no dependency on wall clock time - and one could probably
even expect a finer grained control than 1 msec - non-GUI apps, of course - on
my (somewhat dated PC) this timer runs at 1.8 GHz.

Ok, I apologise if I am off topic - but it sounded strangely familiar with
something
I just did with an embedded controller.
Best regards
Helmut Giese


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Alexandre Ferrieux]

On 7/5/08, Helmut Giese <hgiese@...> wrote:

>
> >Donal K. Fellows wrote
> >While I could always see how to do it with single sets of timers, I
> >could never work out how to do it reliably with multiple event
> >sequences on different scales (e.g. a 13ms interval and a 1s interval)
> >where the event processing takes an appreciable time w.r.t. the
> >shorter intervals. Which happens for sure when using, say, Tk; redraws
> >are quite expensive. With each pending timer event assigned an
> >absolute time at which it becomes eligible for execution, it's pretty
> >simple to handle. But without it...
>
> Could well be, that I am way off of what is discussed here, but what I
> understood seems rather easy to realize (at least on PC hardware).
> Here's the idea:
> Any reasonably recent PC hardware has a free running 64 bit timer
> (sometimes called the Multi Media Timer) - since Pentium 1 IIRC.
> There are 2 system calls:
> - Query this timer's frequency (QueryPerformanceFrequency) and
> - get its current count (QueryPerformanceCounter).
>
> On startup Tcl would ask for the frequency and would once calculate the
> number of timer ticks to a millisecond.
> Now someone comes along and wants to be notified after 10 msec. Ok,
> Tcl gets the current timer value, adds the appropriate value for 10 ms and
> puts the timeout value into a list.
> 1 msec later someone else comes around and asks for a delay of 3 msec.
> Tcl does the same and (this would be a micro-optimisation) orders the list, so
> that the new event is placed _before_ the one from step 1.
>
> At any moment when Tcl wants to check if any timer event has expired, it walks
> the list and notifies any caller whose time has expired (stopping at the
> first time
> which is still in the future, if the list is ordered).
>
> There would be no dependency on wall clock time - and one could probably
> even expect a finer grained control than 1 msec - non-GUI apps, of course - on
> my (somewhat dated PC) this timer runs at 1.8 GHz.
>
> Ok, I apologise if I am off topic - but it sounded strangely familiar with
> something
> I just did with an embedded controller.
> Best regards
> Helmut Giese

Thanks for the idea, but isn't QueryPerfCounter a Windows thing ?
In that case, there's no problem since GetTickCount() is OK for the job.
Am I missing something ?

-Alex

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[Kevin Kenny-3]

Helmut Giese wrote:
>> Any reasonably recent PC hardware has a free running 64 bit timer
> (sometimes called the Multi Media Timer) - since Pentium 1 IIRC.
> There are 2 system calls:
> - Query this timer's frequency (QueryPerformanceFrequency) and
> - get its current count (QueryPerformanceCounter).

The performance counter and the multimedia timer are different
beasts.  The multimedia timer clicks with at best millisecond
granualiry, and mostly is used by games and video players to get
interrupts at frame rate.

> On startup Tcl would ask for the frequency and would once calculate the
> number of timer ticks to a millisecond.
> Now someone comes along and wants to be notified after 10 msec. Ok,
> Tcl gets the current timer value, adds the appropriate value for 10 ms and
> puts the timeout value into a list.
> 1 msec later someone else comes around and asks for a delay of 3 msec.
> Tcl does the same and (this would be a micro-optimisation) orders the list, so
> that the new event is placed _before_ the one from step 1.

This is what we do.

> At any moment when Tcl wants to check if any timer event has expired, it walks
> the list and notifies any caller whose time has expired (stopping at the
> first time
> which is still in the future, if the list is ordered).

This is also what we do.  The issue, though, is that we do more than
*check* for whether a timer has expired.  We also get to the point
where Tcl has nothing to do but wait for the next timer, I/O completion,
mouse click, or whatever.  At that point we need to *wait* until
a given time.  I'm sure that you don't want your Tcl apps all busy
waiting and using 100% CPU when they're idle, so we need to use the
OS facilities to wait.  There is no facility to wait for a particular
value of the performance counter, so we have to us the kernel
facilities, and we're back to at best millisecond granuarity.
We also then need to keep the performance-counter-based notion of
time in sync with the kernel time. That gets tricky - I've seen
perf counters that were 200 ppm off-frequency with respect to
their stated rates, and they vary with temperature, and on laptops
they also vary as the processor clock is slowed down to save
the battery.

> There would be no dependency on wall clock time - and one could probably
> even expect a finer grained control than 1 msec - non-GUI apps, of course - on
> my (somewhat dated PC) this timer runs at 1.8 GHz.

You have a multicore system then. On single-core machines the
perf counter ticks over at 1.8 or 3.57 MHz, not GHz.

In any case, read tclWinTime.c -- virtually all of what you suggest
is already there.  Much more on how it was built can be gleaned
from http://tip.tcl.tk/7

--
73 de ke9tv/2, Kevin


-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Tcl-Core mailing list
Tcl-Core@...
https://lists.sourceforge.net/lists/listinfo/tcl-core