On 02.07.2012 00:09, Mark Karpeles wrote:
> Hi,
>
> Many systems still generate v1 uuids
> (
http://en.wikipedia.org/wiki/Universally_unique_identifier#Version_1_.28MAC_address.29
-
> for example still used by MySQL by default ) and seeing how most OSes
> are handling the leap second is kind of worrying me, since it greatly
> increases the risk of seeing the same UUID generate twice (since the
> same unix timestamp happens twice).
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
> Anyway before we go and modify the code in Linux implementation of the
> leap second, I'd like to open a discussion to find the best way to
> handle leap seconds, and here might be a good idea to start with. One
> thing I could think about and which shouldn't be too complex is to have
> the microtime part (tv_usec) go twice as slow, which would ensure the
> same time does not happen twice.
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).
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.
Regards,
Martin
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
