On 6 Jan 2000 22:47:06 -0000,
uwe@ohse.de (Uwe Ohse) wrote:
>1003.1 mentions a 32-bit integer time_t at least twice;
>p 377, B2, "General Terms", "Epoch":
> "Since the issue of time_t overflowing a 32-bit integer occurs
> well before that time, both of these will have to be addressed
> in revisions to POSIX.1".
That's all right then, we just wait for POSIX to define the correct
fix. ;)
Seriously though, time_t is a global problem which has to be fixed
everywhere, not just the kernel. But there is another time problem
besides the Y2038 overflow and this is mainly a kernel problem.
gettimeofday() is only accurate to microseconds which makes it
unsuitable for unique timestamps, especially on multiprocessor
configurations. IBM mainframes have already hit this problem, their
Time Of Day (TOD) clock will (a) overflow in September 2042 and (b) did
not have enough precision to guarantee unique timestamps. It used to
be this format
The TOD clock is a binary counter with the format shown in the
following illustration. The bit positions of the clock are numbered
0 to 63, corresponding to the bit positions of a 64-bit unsigned
binary integer (big ENDIAN).
1 microsecond---+
^
+--------------------------------------+
| | | |
+--------------------------------------+
0 51 63
In the basic form, the TOD clock is incremented by adding a one in
bit position 51 every microsecond. In models having a higher or
lower resolution, a different bit position is incremented at such a
frequency that the rate of advancing the clock is the same as if a
one were added in bit position 51 every microsecond.
The new 128 bit Extended TOD has this format
______________________________________________
| | |Programm- |
|Zeros| TOD Clock |able Field|
|_____|_____________________________|__________|
0 8 112 127
The old 64 bit TOD clock is embedded in the new 128 bit ETOD. The
first byte contains carry out from the old TOD bit 0, i.e. it handles
the Y2042 roll over. The accuracy of the clock has been extended from
64 to 104 bits, allowing for clock ticks down to ~ 10**-24 seconds.
The interesting thing is the programmable field. To guarantee unique
timestamps, the old TOD used to wait for one clock tick when two
processors tried to read the clock simultaneously. The extended TOD
avoids this by merging a processor specific programmable field into the
ETOD, this typically contains the cpu number. So even in a multi
processor environment, two cpu's will never read identical ETOD values,
guaranteeing unique event timestamps.
If IBM with its slower processors thinks that this is needed, it is a
good indication that the kernel should start thinking about how to
provide unique event timestamps, especially on multi processor
configurations. gettimeofday() is not going to be able to cut it at
the present level of accuracy.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:08 EST