Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
...
I do not understand yet the portability problem of TSC values, but
the inconsistency issue on SMP systems was new to me and make your
choice a bit more comprehensible. Does moving to nanoseconds really
solve the problem? The clocks used in aperiodic mode will not run
synchronised nor will they be started at (almost) the same time,
will they? So, all absolute times (taken on CPU A and applied on CPU
B) might still be inconsistent.
We hold per-cpu timer lists, so TSC bases are never mixed, even if
timers can be migrated explicitely, but in such a case, they are
always re-inited. IOW, outstanding timers don't migrate.
Ok, you handle different relative times in a SMP-safe way, I'm convinced.
What about the absolute meaning of time stamps? We once measured a few
10 us drift per second between the TSCs of a Pentium II (400 MHz) and a
Pentium I (133 MHz). Maybe new hardware with almost identical CPUs can
provide slightly better results, but there will be an absolute drift
over the time which make time stamps taken on one CPU uncomparable with
those taken on others. Are there any re-synchronisation mechanisms in
fusion? Or has the user (of rt_timer_read e.g.) tell the different clock
sources apart?
Nope.
Then the way the Linux kernel does it might be of some help. It is
sychronising the TSC offset each periodic timer event.
Jan
