Live data from Hacker News

Leap second causing Linux server crashes?

serverfault.com

121–122 of 122 posts

Re: Leap second causing Linux server crashes?

#121

Earlier quoted context omitted.

What is time, other than a state in which net entropy within a closed system increases (which is already a definition abstract enough that it almost misses the point)?

That's not really a definition of time, just a way to postulate its direction. Time as a physical unit has been decreed to be the rate of decay of a certain Cesium atom; i.e., a fixed regular interval, whereas the increase of entropy varies from moment to moment. E.g. right now I'm typing and before I wasn't, that doesn't mean time is going ever so slightly faster because of that ...

Decay of nuclei is a completely random process, and you really don't want to use it to define a time-scale.

What you had in mind is the SI-definition of the second, which reads (http://www.bipm.org/en/si/si_brochure/chapter2/2-1/second.ht...):

  """
     The second is the duration of 9 192 631 770 periods
     of the radiation corresponding to the transition
     between the two hyperfine levels of the ground state
     of the caesium 133 atom.
  """
The details of this effect are a little more complicated, but it boils down to the fact that you can measure the "angular momentum" of your nuclei when you have them pass through a non-uniform magnetic field. Particles in the one state are deflected differently than particles in the other state. And when you irradiate a particle beam in the F=0 state with the right frequency (9.2 GHz) you can very efficiently swap many particles over to the F=1 state. By adjusting your frequency sufficiently to find the maximum rate of flips, you can can tune for the exact 9'192'631'770 Hz.

The cesium particles have not decayed, in principle you could run forever on a certain supply of atoms... even though in practice a Cs-beam is produced on one side, at a hot filament, and dumped to the other side of the clock after passed through the apparatus that performs the steps described above. They will be disposed of when the lifetime of the beam-tube is reached (typically 10 years or so with a few grams of cesium inside).

Re: Leap second causing Linux server crashes?

#122
post #45

Earlier quoted context omitted.

How are systems being notified of the leap seconds now, that wouldn't immediately enable them to update their hypothetical leap second table? It seems like we already have a much bigger lead time for notification than we could possibly need. > I can see why people don't relish the idea of requiring similar tables just to keep system time accurate. But the 'solution' we're using now is to make system time less accurat…

"How are systems being notified of the leap seconds now, that wouldn't immediately enable them to update their hypothetical leap second table?" I am not an expert, but as far as I know the most automated solutions are doing it via NTP, which just resets the second, then relies on clock drift to bring everything back into synch. Otherwise, I think your only option is to keep the timezone packages up-to-date (which is…

NTP sends a special message to the kernel (using adjtimex), that boils down to: today you will insert a leap second. This isn't the same as clock drift, which gets smoothed out, it means a minute with a 60th second (in UTC) or with the 59th second happening twice (in POSIX). NTP servers need a leap second table ( http://support.ntp.org/bin/view/Support/ConfiguringNTP#Secti.... ), but most other systems only need to know the current delta between POSIX and TAI, and manage without a leap table.
Post reply on HN