[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