Talk:Clock drift

Code example

The example of "pseudo code" is not, I would suggest, psuedo code. It is more like actual code. I can't tell which language it's from, but it's not that easy to follow if you don't know the particular language. It should be re-cast as true pseudo code. Arcturus 10:40, 29 July 2006 (UTC)

Well, this is Wikipedia. Be bold and fix it! Don't ask others to fix it. And yes, I just typed down the first code that came to mind and focused more on correctness of that code than making it very easy to read. We should probably change the C-style for-loop to a while loop or even plain english or so, as I did with the inner loop. In my first version that inner loop too was a C-style for-loop. I was thinking of writing a description in plain english too, and having the "pseudocode" look more like actual code as it does now. So I think there are several ways to go: Either have a very easy to read pseudocode, or have plain english + a code example in for instance C or perhaps just a code example in C but with very good comments? I haven't done either yet since I need to think about it for some days.

Besides, in a real system we usually do not do the modulo 256 since that would be a waste since the higher bits also contain some randomness. (Especially in the first round since that varies from zero to "average loop value" due to the first round starting anywhere in the middle of a tick.) Instead usually we put the full 32-bit loop values in the array and when finished we hash the whole array downsdsdsdsdswdsdsdsdsd to one 256-bit value. Note that the hash method used need not be a secure one, any "compression function" with a good avalanche effect is good enough. Hash functions just happens to be such compression functions. But I wanted to keep the example as easy as possible so I used modulo instead of hashing.

So there are some thinking and discussion to do about how to best show how to do clock drift measuring.

--David Göthberg 17:29, 29 July 2006 (UTC)

Since someone removed the pseudocode from the article here it is for reference:

The pseudocode below shows a "software random number generator" that produces 256 random bits and that loads the CPU fully for about 1/3 of a second. This assumes the system tick is 100 times per second and a fairly fast modern computer where the number of loops per tick will be high so each loop will vary with at least 8 bits worth of randomness. The measurement is done 32 times (during 32 separate ticks), each time producing 8 bits of randomness.

(* Code for a software random number generator. *)

var  RNGarray: array[0..31] of byte;   (* An array of 32 bytes. *)

(* Do 32 clock drift measurements. *)
for x := 0 to 31 do begin

  tick := clock();

  (* Count loops until the next tick. *)
  loop := 0;
  while clock() = tick do begin
    loop := loop + 1
  end; (* tick loop *)

  (* Use the lower 8 bits since those are the ones that vary wildly. *)
  RNGarray[x] := loop modulo 256

end (* index loop *)

(* The RNGarray now contains 256 random bits. *)

--David Göthberg 13:01, 23 June 2007 (UTC)

Atomic clock drift due to realitivity

I'd like to see some actual data regarding the speed in which the various cessium clocks placed around the globe have been in motion. The argument that "the atomic clocks drift, and they're in motion because they're on earth. Ergo it's the cause is realitivistic time dialation" is simply not enough for me. I want to see a citation of actual test data and how it all coincides with the math behind realitivity. I'm tempted to remove the realitivity section, but I respect Einstein's theories enough to give them the benefit of the doubt. But it pains me to see the cause of physics anamolies being "a wizard did it" and Einsteins theories being cited as "the wizard who did it" without any testing of any sort. I almost feel like the realitivity section amounts to someone with frazzled hair dressed up in a lab coat and welding goggles, pointing dramatically at cessium clocks and shouting "SCIENCE!" with that being all the justification the section needs. 24.254.163.150 (talk) 07:59, 8 January 2008 (UTC)

From International Atomic Time: "In the 1970s, it became clear that the clocks participating in TAI were ticking at different rates due to gravitational time dilation ... this meant that TAI slowed down, by about 10^-12. The former uncorrected time scale continues to be published, under the name EAL." Plugging the Earth numbers in to the non-rotating sphere equation in gravitational_time_dilation gives (as a difference from 1) -3.478e-10 at the equator and -3.490e-10 at the poles. There are going to be other factors from e.g. the earth not being a sphere, and the earth spinning (plugging those numbers in gives -1.197e-12 at the equator). Sure, the section needs improvement, but anyone can do a little WP research and fix it. ⇌Elektron 15:15, 21 December 2008 (UTC)

merge

I suggest merging the section hardware_random_number_generator#Clock_drift into the section clock_drift#Random_number_generators. Both are talking about the same thing, a hardware random number generator based on two or more independent oscillators. I suspect that afterward the merge, we might find we have enough material to split out that section into its own article. What do you think about merging? If we make a new article from that material, what should we call it? "clock drift random number generator" ? "oscillator driven random number generator" ? --68.0.124.33 (talk) 20:23, 5 April 2008 (UTC)

It belongs in the other article. Someone reading about clock drift does not want to read a few paragraphs about RNG techniques. Besides which, this article presents a terrible random number source – oscillator-derived sources rely on being perturbed by random sources. Clock skew/drift between two crystals is largely systematic, measurable, and not very random. ⇌Elektron 15:36, 21 December 2008 (UTC)

Admittedly I know almost nothing about this kind of thing, but it seems that if there are people using clock drift/skew in (pseudo)random number generators such as stated in the section on clock drift in Hardware random number generatorit should at least be mentioned in that article. Colincbn (talk) 12:08, 13 November 2009 (UTC)

Drift vs. skew?

Most reliable sources (e.g. [1]) seem to use "skew" to mean rate of change of offset (i.e. how fast/slow it runs" and "drift" to mean rate of change of skew (i.e. how stable a clock is). It's a pity that this article uses both terms to mean a range of things, and irritating that "clock skew" is used by the semiconductor industry to mean something else. In any case, this article requires cleanup. ⇌Elektron 15:57, 21 December 2008 (UTC)

But if Wikipedia defines skew as a measure for synchronized systems (i.e. clocks), then when one compares two free running clock for precision/accuracy, the term skew should not be applicable unless it pertains to supporting circuitry used in each individual clock (like buffers that skew the clock signal). Shouldn't the definition of skew be revised as well,then? — Preceding unsigned comment added by 140.101.84.1 (talk) 16:02, 2 December 2012 (UTC)