On 27.04.22 15:13, gabriel.moy...@dlr.de wrote:
On 07/04/2022 15:16, Sebastian Huber wrote:
On 07/04/2022 15:10, gabriel.moy...@dlr.de wrote:
Which sequence of function calls and timings cases the problem? This
should be definitely a test case.
The generation is updated every time tc_windup() is called. So it is
more or less a race condition when it happens.

This is not a race condition. The sequence counter is supposed to
ensure a consistent state. You can't simply remove this.

Maybe the PPS support requires that we use two timehands even for the
uniprocessor configuration. For this, we have to understand under
which conditions and use cases the generation change is an issue.

In kern_tc.c there is this comment, which is a result from a discussion on a 
FreeBSD mailing list:

/*
   * In FreeBSD, the timehands count is a tuning option from two to 16.  The
   * tuning option was added since it is inexpensive and some FreeBSD users 
asked
   * for it to play around.  The default value is two.  One system which did not
   * work with two timehands was a system with one processor and a specific PPS
   * device.
   *
   * For RTEMS, in uniprocessor configurations, just use one timehand since the
   * update is done with interrupt disabled.
   *
   * In SMP configurations, use a fixed set of two timehands until someone
   * reports an issue.
   */

We definitely need a test case for this corner case. Adding a second timehand 
has a size impact. On a 32-bit machine there is
sizeof(struct
timehands) == 120.

What do you think about something in the middle between adding a second 
timehand and not adding it at all for non-SMP configurations?
Let me explain better the idea; the pps_event() uses only 3 variables of the 
object timehand: th_offsetcount, th_bintime and th_scale. The values of them 
could be saved instruct  pps_state during pps_capture(). This will only happen 
in case of non-SMP configurations. Then, the verifications need to be adapted 
for SMP or for non-SMP, e.g. the th_generation will be checked at the end of 
pps_capture() for both configurations but only for SMP in pps_event().

I would keep the synchronization as it is in FreeBSD for now and add a test case which fails in non-SMP configurations. This can be used to discuss the trade-offs. We need such a test case anyway.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to