v1 UUID's are deterministically unique across both space and time. Random UUID's are random. There is an (infinitesimally small chance of a duplicate). To my knowledge, the reason random uuid's exist and are part of the RFC is that they are bone simple to implement, whereas v1 and v3/v5 involve all kinds of non-obvious supporting facilities such as a monotonic clock or message-digest algorithm.
V1 UUID's are uniquified in three different ways: a unique 6 byte node id is computed (the details are interesting, but refer to the source for more). It is combined with a thread-safe, concurrent monotonic timestamp that is guaranteed to generate always increasing values regardless of clock precision or degree of concurrency. Finally, a 2-byte "clock-seq" value is randomly seeded at load-time and incorporated into the calculation. So, even if the system is restarted on the exact same node with the hardware clock for some reason adjusted backwards and it is attempted to generate another UUID at the exact "same" millisecond as one which had been generated prior, there is only a 1 in 65536 chance of issuing a duplicate. We do not use the MAC address actually. clj-uuid/node.clj at master · danlentz/clj-uuid <https://github.com/danlentz/clj-uuid/blob/master/src/clj_uuid/node.clj> has more detail, but this topic is specifically addressed by the RFC. the following excerpt describes the node address calculation: ;; "A better solution is to obtain a 47-bit cryptographic quality random ;; number and use it as the low 47-bits of the Node-ID, with the least ;; significant bit of the first octet of the Node-ID set to one. This ;; bit is the unicast/multicast bit, which will never be set in IEEE 802 ;; addresses obtained from network cards. Hence, there can never be a ;; conflict between UUID's generated by machines with and without network ;; cards." ;; . . . ;; . . . ;; "In addition, items such as the computer's name and the name of the ;; operating system, while not strictly speaking random, will help ;; differentiate the results from those obtained by other systems... ;; ... A generic approach... IS TO ACCUMULATE AS MANY SOURCES AS POSSIBLE ;; INTO A BUFFER, USE A MESSAGE DIGEST SUCH AS MD5 OR SHA1, TAKE AN ;; ARBITRARY 6 BYTES FROM THE HASH VALUE, AND SET THE MULTICAST BIT ;; AS DESCRIBED ABOVE." ;; ;; -- [RFC4122:4.5 "Node IDs that do not Identify the Host"] If there are any good reasons why one should pay 10 times the cost to generate a UUID randomly, I'd like to hear them. On Tuesday, March 3, 2015 at 3:11:23 PM UTC-5, Colin Yates wrote: > > Are v1 as "unique" as randomUUID()? > On 3 Mar 2015 20:08, "danl...@gmail.com <javascript:>" <danl...@gmail.com > <javascript:>> wrote: > >> PS. We are now TEN TIMES faster, so it is a lot easier to compute that >> percentage: >> >> #'uuid/v1: 201 nanoseconds >> #'java.util.UUID/randomUUID: 2012 nanoseconds >> >> >> Best, >> Dan >> >> >> On Tuesday, March 3, 2015 at 3:06:35 PM UTC-5, danl...@gmail.com wrote: >>> >>> I invoked "engineer's privilege" to quote the number very >>> conservatively. In one of the later episodes, didn't Scotty confide that >>> the Enterprise actually went up to warp 11, he just never told anyone? :) >>> >>> Actually, you are right -- I noticed it after I hit "send". As you can >>> tell, the relative performance number has been a little bit of a moving >>> target as things improved quickly and I grabbed the number from a little >>> too far back in the REPL. >>> >>> Thanks Jacob. I really do hope this is a library that people will find >>> modestly useful. >>> >>> >>> >>> On Tuesday, March 3, 2015 at 2:45:38 PM UTC-5, Jacob Strength wrote: >>>> >>>> That is pretty amazing, I'll have to remember this library next time I >>>> need to use UUID's. >>>> Also I think you meant 450% faster. >>>> >>>> On Sunday, March 1, 2015 at 5:35:16 PM UTC-7, danl...@gmail.com wrote: >>>>> >>>>> Ok, for anyone following my adventures optimizing clj-uuid, I've >>>>> gotten another substantial win. >>>>> Check it out: http://danlentz.github.io/clj-uuid >>>>> >>>>> #'uuid/v1: 443 nanoseconds >>>>> #'java.util.UUID/randomUUID: 2012 nanoseconds >>>>> >>>>> Also, the test suite has much greater coverage with individual tests >>>>> for each v1, v,3, v4, v5 uuid version. >>>>> And, finally, there more interesting notes about some of the esoteric >>>>> details of the node-id representation >>>>> and the way it is calculated to disambiguate it from any legal 802 MAC >>>>> hardware address. And more.... ;) >>>>> >>>>> >>>>> ====================================================================== >>>>> >>>>> user> (criterium/bench (uuid/v1)) >>>>> >>>>> Evaluation count: 139356300 in 60 samples of 2322605 calls. >>>>> Execution time mean: 443.707611 ns >>>>> >>>>> >>>>> user> (criterium/bench (java.util.UUID/randomUUID)) >>>>> >>>>> Evaluation count : 30850980 in 60 samples of 514183 calls. >>>>> Execution time mean : 2.012861 µs >>>>> >>>>> >>>>> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
