On Fri, 2005-05-27 at 09:25 -0700, Kevin Baker wrote: > <snip: discussion about time zones> > > No, if the GUIDs are generated from a clock, then this > > won't ensure that > > GUIDs are always increasing. > > > > To reiterate from previous emails: > > > > What if one of the provider's clock runs fast? Runs slow? > > > > What if a GUID occurs from a previous epoch? > > So could you exmplain what you mean by clock running fast > or slow?
Sure :) > If all servers in the cluster are synced with a remote NTP > server periodically I can't see how this would happen. > This could just be a requirement of clustered multi-master > systems. Let's keep it simple. Two machines, one is configured to generate odd sequence numbers and the other to generate even ones. So when one wants to write a message, it picks the timestamp up, discards or sets the ones-bit as necessary, and writes it. A 010 B 011 A 100 B 101 A 110 B 111 Now, these show perfect sync for clocks on "A" and "B". But let's say "B" speeds up by "just a little bit" and we'll see. A 010 B 011 B 101 A 100 Note in this case, "B" got it's message in before "A", but with a higher sequence number. This must be avoided because this breaks RFC2060. Note: even if the clocks are sync'd, maybe one machine is slightly faster, or the network is slow. Any of a dozen reasons can cause a delay in packets. You'll note I don't mention what these clocks are- minutes, seconds, milliseconds, or hours or something else (ticks?). That's because it doesn't matter: Whatever the quantum is, whatever the epoch size is, it's ALWAYS going to be possible for one to just "come in" before the other. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
