RTEMS | Specify limits of CLOCK_MONOTONIC (uptime) (#5538)

[Sebastian Huber (@sebhub)]

Sebastian Huber created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5538

Assignee: Sebastian Huber

It needs to be specified what the limits of `CLOCK_MONOTONIC` should be and what happens if the limit is reached if it can be reached. This clock is also known as the *uptime*.

This issue is related to https://users.rtems.org/t/rtems-time-representation-limits-or-rtems-end-of-time/483 which talks about `CLOCK_REALTIME`.

The `CLOCK_MONOTONIC` is a clock provided by RTEMS which measures the time since an unspecified starting point. In contrast to `CLOCK_REALTIME`, this clock cannot be set. It may be affected by incremental adjustments for example carried out by the NTP or the use of a PPS signal. The current starting point is one second:
```c
static struct timehands th0 = {
	/* ... */
	.th_scale = (uint64_t)-1 / 1000000,
	.th_offset = { .sec = 1 },
	/* ... */
};
```
Due to performance reasons, a snapshot is also available through this object:
```c
#define	time_uptime _Timecounter_Time_uptime
volatile time_t time_uptime = 1;
```
Declared as:
```c
/**
 * @brief The uptime in seconds.
 *
 * For compatibility with the FreeBSD network stack the initial value is one
 * second.
 */
extern volatile time_t _Timecounter_Time_uptime;
```
This used to be a 32-bit signed integer for performance reasons, however, it was changed to address a code analysis finding here: #5204.

It needs to be clarified what the limits of `CLOCK_MONOTONIC` should be:
1. With a signed 32-bit integer, the uptime is limited to about 68 years. If the system reaches this limit, then the uptime overflows and yields a negative number. In this case, the calculations involving time values are undefined or implementation-defined in C.
2. With an unsigned 32-bit integer, the uptime is limited to about 136 years. If the limit is reached, then modulo arithmetic applies. There are issues, if the time value is assigned to 32-bit singed integer. The libbsd network stack requires a signed integer for `time_uptime`.
3. With a 64-bit integer there are not practical limits. 32-bit targets may have performance issues. 32-bit targets may have correctness issues in the instant the time *t* changes from any time which satisfies `t % (UINT32MAX + 1) == UINT32MAX` to the next value.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5538
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260331/771c9330/attachment-0001.htm>