In examples and layouts, lengthen the counter to 15 bits for millisecond precision

[sergeyprokhorenko]

In examples and layouts, lengthen the counter to 15 bits for millisecond precision. 12 bits is too small. Here is the proof: #40 (comment)

[broofa]

I don't see a need for this. We need to draw a line somewhere. 12 bits? 15 bits? ... fundamentally the problem is what to do if the clockseq counter rolls over. The RFC specifies this should be treated as an error. #53 proposes to just freeze the counter (a behavior I disagree with). Adding more bits to the sequences is just kicking the can down the road, so (for example purposes) having the counter align on byte boundary is... convenient.

And for exemplary purposes, 12 bits that nicely align on the byte boundary seems like a reasonable choice.

[fabiolimace]

This is yet another layout for comments.

If we move to a new variant 'E', we can use 64 bits for timestamp and counter.

If we use 44 bits for milliseconds, 20 bits lasts for a counter (way too much?).

• 44 bits (11 chars): milliseconds
  • up to the year 2527 A.D., 500 years from now.
• 20 bits (05 chars): counter
  • variant 'E' could generate 1 BILLION UUID-E per second.
  • UUID v1 can generate up to 10 million per second.
• 04 bits (01 chars): variant 'E'
  • variant 'E' uses only 4 bits, instead of 6 bits in variant 2
• 60 bits (15 chars): random
  • good enough, right?

Structure:

|mmmmmmmm-mmmc-cccc-errr-rrrrrrrrrrrr|

m: milliseconds
c: counter
e: variant
r: random

[sergeyprokhorenko]

I don't see a need for this.

It is not a reasonable argument.

We need to draw a line somewhere. 12 bits? 15 bits?

Quite right! The "line" is a morden database performance on SSD (the possible number of inserted records in a database table per millisecond). 15 bits seems enough from this point of view. 2 to the power of 15 is 32768. But 12 bits is definitely not enough.

And for exemplary purposes, 12 bits that nicely align on the byte boundary seems like a reasonable choice.

For exemplary purposes you should demonstrate applicable options, because most people will take these examples as a guide to action. But 12 bit is not an applicable option at all. See the proof: #40 (comment) Nobody needs to align on a byte boundary.

[broofa]

I guess my issue here is that Draft 2 reserves the subsec_a and subsec_b fields for monotonic time data (timestamp + counter). The one example we have that currently fits w/in those fields is the msec clock/12-bit counter example you're asking we change (Figure 3). The other examples, usec and nsec clocks (figures 4 & 5) push the lower-order clock and counter bits into the subsec_seq_node field. I.e. we already have two examples that pretty clearly show how a user might add additional precision to the clock and/or counter.

Part of my resistance here is that it's unclear what exactly you're asking for. Is your issue just with the examples? Or are you asking for a different field layout as @fabiolimace mentions. If the former, then we already have examples that show how the different fields can be used for additional precision, as I said. If the latter, then you would need to flesh this issue out more.

[sergeyprokhorenko]

Is your issue just with the examples?

Yes, it is.

... then we already have examples that show how the different fields can be used for additional precision, as I said.

The managers assigned to apply this standard do not have the flexible minds that you have. They will stupidly copy an example that will not work well.