Philippe Gerum wrote: > Jan Kiszka wrote: >> ... >> On the other hand, the advantage of TSC-based synchronised inter-tick >> timestamps is that you can do things like >> >> sleep_until(rt_timer_ns2ticks(rtdm_clock_read() + 1000000)) >> >> without risking an error beyond +/- 1 tick (+jitter). With current >> jiffies vs. TSC in periodic mode, this is not easily possible. You have >> to sync in the application, creating another error source when the delay >> between acquiring the TSC and sync'ing the TSC on jiffies is too long. >> > > The proper way to solve this is rather to emulate the periodic mode over > the oneshot machinery, so that we stop having this +/- 1 tick error > margin. The periodic mode as it is now is purely a x86 legacy; even on > some ppc boards where the auto-reload feature is available from the > decrementer, Xeno doesn't use it. > > The more I think of the x86 situation, the more I find it quite silly. I > mean, picking the periodic mode means that 1) all delays can be > expressed as multiples of a given constant interval, 2) the constant > interval must be large enough so that you don't put your board on its > knees, by processing useless ticks most of the time. What one saves here > - using periodic mode - is a couple of outb's per tick on the ISA bus, > since the PIT handles this automatically without software intervention > once set up properly. We already know that the programming overhead > (i.e. introduced by those outb's) is perfectly bearable even for high > frequency sampling like 10Khz loops in aperiodic mode. So why on earth > do we care about saving two outb's and get a lousy timing accuracy in > the same move, for constant interval delays which are necessarily going > to be much larger than those already supported by the aperiodic mode? Er... > > This is a shift in the underlying logic of the periodic mode we are > discussing here actually. It used to be a mode where timing accuracy was > only approximate, mostly to deal with timeouts, in the watchdog sense. > Now, it is becoming a way to rely on a constant interval unit, while > still keeping a high timing accuracy. I'm ok with this, since we don't > rely on true PIT (except for x86, which is fixable) when running in > periodic mode, so I see no problem in raising the level of timing > accuracy of such mode. Existing stuff would not break because of such > change, but improve instead for people who care for exact durations in > periodic mode.
Yep, getting rid of as much periodic mode limitations as reasonable in a transparent way sounds very good to me. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
