[RTEMS Project] #2230: PowerPC with mpc6xx clock: Nanoseconds extension doesn't compensate for pending clock tick, time may go backwards
RTEMS trac
trac at rtems.org
Wed Jan 28 04:01:08 UTC 2015
#2230: PowerPC with mpc6xx clock: Nanoseconds extension doesn't compensate for
pending clock tick, time may go backwards
-------------------------------------------------+-------------------------
Reporter: nick.withers | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 4.11
Component: bsps | Version: 4.11
Severity: normal | Resolution:
Keywords: clock, time, backwards, race, |
nanoseconds, monotonic |
-------------------------------------------------+-------------------------
Comment (by nick.withers):
Replying to [comment:2 sebastian.huber]:
> I would drop the multiplication by 1000 and use something like this:
Can you guarantee that 2 * Clock_Decrementer_value *
((uint64_t)1000000U<<32)/ (BSP_bus_frequency/BSP_time_base_divisor) won't
overflow / wrap on any supported platform, though?
It happens not to on the MVME3100, where Clock_Decrementer_value is 416660
(assuming a 100 Hz tick), so *personally* I'm happy with that, as it
increases precision.
> static uint32_t lpc_clock_nanoseconds_since_last_tick(void)
> {
> uint64_t k = (1000000000ULL << 32) / time_base_frequency;
I've broken this out into Clock_Decrementer_reference (better name?),
calculated in Clock_initialize(), because otherwise it'd be done at run-
time every time the nanoseconds extension function were called.
> uint64_t c = ticks_since_last_exception();
>
> if ((TSR & DIS) != 0) {
> c = ticks_since_last_exception() + period;
> }
>
> return (uint32_t) ((c * k) >> 32);
> }
>
> I would also do the Book E check only once and install different
extensions instead. If you use the network stack, then this function is
performance critical.
Righto, understood.
--
Ticket URL: <http://devel.rtems.org/ticket/2230#comment:3>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list