Hi,
>
>
> I think you have a misconception of a "timestamp happening". It's not
> the case that timestamps normally happen once only. Instead, the
> same time holds for one second. So if you read out gettimeofday multiple
> times in a sequence, you get the same timestamp many many times regularly.
>
> Consider the program
>
> #include <stdio.h>
> #include <sys/time.h>
>
> int main()
> {
> int count = 0;
> struct timeval tv, tv2;
> gettimeofday(&tv, NULL);
> while(1) {
> gettimeofday(&tv2, NULL);
> if (tv.tv_sec != tv2.tv_sec)
> break;
> count++;
> }
> printf("timestamp happened %d times\n", count);
> }
>
> On my system, I get outputs like
>
> timestamp happened 41361855 times
Try to get your program to compare tv_sec and tv_usec too. As seen from a
different task, the same timestamp usually does not happen, and systems
will just increase tv_usec by one if a new call to gettimeofday() returns
the same tv_sec/tv_usec.
However, the 59th second happens twice. If you watch seconds + 1/10th
seconds, you get ... 58.9] [59.0 59.1 59.2 59.3 59.4 59.5 59.6 59.7 59.8
59.9] [59.0 59.1 59.2 59.3 59.4 59.5 59.6 59.7 59.8 59.9] [00.0 ...
> Now, type 1 UUIDs actually use a resolution of 100ns, assuming the
> operating system supports that. So the chances that you get the same
> reading twice are much lower when you really read 100ns (although
> gettimeofday doesn't support that).
>
gettimeofday() supports a resolution of 1µs, which is 1/10th not enough
than the requirement for uuid. This is not however the issue I'm trying to
raise here.
> However, your proposed change doesn't decrease the likelihood of
> collision at all. Currently, each 100ns timestamp value holds for
> a total of 200ns for a leap second (with a delay of 1s between
> two 100ns blocks). With your proposed change (running the clock
> at half speed), the same 100ns timestamp still happens for 200ns,
> but in a single block.
>
The main issue here is that UUID v1 (and other things) relies on an ever
increasing time (ie. it doesn't expect time to go back in time). ntpd, for
example, when adjusting time, will only do that by fractions of seconds
over time rather than brutally, thru ensuring such applications would not
encounter a sudden time change that could be an issue.
However, the handling of this extra second is far from seamless. The same
second happens twice, which can potentially lead to more or less serious
issues.
A program running knows that he could end reading the same timestamp twice,
even with a method to get time at +/- 100ns, and usually is able to
workaround this which usually, since uuids and other actions in need of
ever increasing timestamp do that in bursts, consists into increasing the
value manually by one since last value as long as last value >= current
timestamp.
The way leap second is implemented currently could easily cause such
programs to generate duplicate values where not expected.
This is a very minor issue and chances of it happening are still low, but
much less low than designed.
Mark
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
