TTimer implementation

ROOT
1

Hi,

I have been using TTimer on win32/win32gdk (CINT), and it seems that they are not very precise (about 10-20 % error); my Timer.Notify() takes 1-5 % of the waiting time.

It’s running on a slow computer (Pentium I). Search the Root Talk has not showed me a way to correct this.

Do you know how to correct the clock drift ?

Thanks,

Denis Rosset

2

Hi Denis,
TTimers “are running” in TApplication::Run event loop,
so they are “not independent”. The timer resolution is 10 ms.
We are going to improve a timers under win32gdk.
One of the solutions would be adapting “old win32” approach,
i.e. creating a separate thread for timers.
BTW, do you see such problem under “old win32” ROOT?
What time resolution is required for your application?

Thanks. Regards. Valeriy

3

Hi Valery,

I don’t need really a great resolution each timer tick, but an average interval between that is close enough to the timer interval.

I didn’t check the behavior with the old win32 version though.

Thanks,

Denis Rosset

4

Hi
This problem is related to
//root.cern.ch/phpBB2/viewtopic.php?t=259&highlight=
WIN32 implementation use the "dedicated thread to implement TTimer using WIN32 API. This way the timer event is delivered to the ROOT regardless of the state of the ROOT GUI event loop (and albeit GUI thread status). It doesn’t interfere with the non-tread safe CINT code becuase WIN32 implementation of the ROOT TTimer generates another internal message to the dedicated CINT thread. Following this approach we always “safe”, because it does cause that no piece of the CINT to work concurrently in the different thread.

5

Hi Valeri,
we have decision to reimplemet TWinNTSystem
to provide better timers and introduce sockets. Be done.

Regards. Valeriy

6

Hi Denis,

I made CVS commitment yesterday. Here is citation:
" I rewrote TWinNTSystem::DispatchOneEvent.

  • rudimentary code inherited from “old win32” and TUnixSystem was removed

  • TWinNTSystem::DispatchOneEvent has the same “logic” as TUnixSystem::DispatchOneEvent,
    i.e. keep priority for different types of events:

    1. handle GUI events (gui input, gui refreshing)
    2. handle signal handlers
    3. handle syncronous timers
    4. handle file handlers (e.g. sockets)

    I’d like to point on few important things specific to win32gdk implementation:

    1. it doesn’t contain blocking (like MsgWaitForMultipleObjects or select under unix).
      To prevent from 100% CPU time occupation ::SleepEx(1, 1) is used on return.
    2. masking file descriptors is not implemented, i.e. we process all file descriptors"

I’d like to change priority of handling events to following to
improve timers:
1. handle GUI input
2. handle signal handlers
3. handle syncronous timers
4. handle GUI refreshing
5. handle file handlers (e.g. sockets)

I need a “testing facility” for that. Do you have some code
which demonstrates “clock drift”? Of cause I can do it by myself,
but I’m under pressure with other activity.

Thanks. Regards. Valeriy

7

Hi Valeri, I hope you did all above for GDK only?

8

Of cause