> On 6 Feb 2017, at 22:59, Peter Uhnak <[email protected]> wrote: > > >>> On Windows (10) (with latest 6 image and VM) `Time microsecondClockValue` >>> returns microseconds, but (presumably the system) cannot give precision >>> beyond 1 second - this will imho need a VM fix; >> >> I find that quite hard to believe and I did not know that. Are you really >> sure ? That would be terrible. A solution might be to use another clock >> primitive. >> >>> I can also generate about 1.2M UUIDs per second (limited by single core I >>> guess), which means that about every 600-1200 consequential UUIDs will have >>> the same clock value. >> >> I can't follow your reasoning here: if the clock precision would be 1 >> second, you would get 1.2M consecutive UUIDs with the same clock value, >> right ? > > Whoops, I meant the precision on a millisecond, not second... thus the ~1000k > consecutive clock values. > The returned value is still in microseconds, but the last 3 digits are fixed > (they are different on startup, but same during execution). > > I faintly remember having the same issue in a different language years ago, > because they had different APIs or some bullshit like that. > > So when I generate e.g. 10 random UUIDs I get: > > > (1 to: 10) collect: [ :i | NeoUUIDGenerator next ]. "an Array( > an UUID('349b2ccc-4404-0d00-a8e7-5c9c0ef2da37') > an UUID('349b2ccc-4404-0d00-a8e8-2f3a0ef2da37') > an UUID('349b2ccc-4404-0d00-a8e9-9e0b0ef2da37') > an UUID('349b2ccc-4404-0d00-a8ea-15520ef2da37') > an UUID('349b2ccc-4404-0d00-a8eb-fa5c0ef2da37') > an UUID('349b2ccc-4404-0d00-a8ec-d25f0ef2da37') > an UUID('349b2ccc-4404-0d00-a8ed-6a590ef2da37') > an UUID('349b2ccc-4404-0d00-a8ee-3a8d0ef2da37') > an UUID('349b2ccc-4404-0d00-a8ef-0ad20ef2da37') > an UUID('349b2ccc-4404-0d00-a8f0-7bda0ef2da37'))"
I don't see any problem here, they are all different. Of course the clock part is the same during the same millisecond. >> In the unit tests this is verified (that the time value goes forward on >> consecutive calls). >> > > testTwo*Generator only tests if they are close, not that one is higher than > the other, > > if I add > > self assert: time2 equals: time1. > > the test will still pass (but that is already obvious from the list above). > > > >>> 9 & 10 bytes are counter, but 9th bit is rewritten with variant, so the >>> counter is actually 0-255 and not 0-65536. >> >> Yes, but more correctly, the top 2 bits are set to 10, making the range 1 to >> 2^14 (16384) (instead of 2^16). > > Welp, I can't do bit math. > >> >>> And finally 11 & 12 are random bits (assuming the seeding isn't broken). >> >> The seeding is one aspect (the quality of the seed), the algorithm is >> another. >> Note that in the current Random class, the seed is initialised using the >> clock as well. > > The problem with Random is not the time-based initialization, but masking of > the initial value (which is mentioned in the originally linked thread on > randomness, which fixes itself upon further generations). > >> >>> So on Windows, the conditional probability that nth and n+256th UUIDs will >>> be identical is imho 1/65536 (assuming they are in the same second, which >>> is easy). >> >> I am pretty/quite sure this is not correct but it would take me much more >> time to come up with a more correct calculation. > > With the actual counter I would have to generate 16384 UUID/milisecond, which > unlike 256/ms I cannot do, so it is safe again. :) (well... until Pharo goes > multicore) > >> >> BTW, you also have to define the context of being the same: the same >> instance of one NeoUUIDGenerator generating the same UUID, or several >> different generator instances, in the same image, in different images, on >> different runs, the same or different machines/networks, ... >> >>> On Linux my understanding is that clash can only happen if NTP adjusts my >>> clock during UUID generation (at which point it is same as Windows). >>> >>> Can UUID clash be achieved on Linux if you deploy copies of the same image >>> and let them all generate UUIDs? (It should be again 1/65536). > > Yeah, across machines the last four bytes behave randomly too. > > Maybe I can get clash if I run two random generators in forks (to fix 14 bits > of counter randomness :) ... but no time for that now. :) > > Peter >
