Britain Deploys Quantum Clocks for Military Systems

More from the article...

... There was a time when atomic clocks looked like pretty hot stuff. By measuring time based on the frequency of cesium-133 atoms, it was possible to build a clock that would only gain or lose a single second in 300 million years. However, compared to a quantum clock, atomic clocks are as accurate as a one-dollar antique pocket watch that's been whacked several times with a coal hammer.

By measuring how atoms jump between specific energy states, a quantum clock can reach an accuracy of gaining or losing one second in 30 billion years. That's a billion with a 'b."

It's a technology that has a lot of potential and the British military is keen to exploit it as soon as possible because it can set modern warfare on a timetable measured in nanoseconds. ...

... Physicists imagine a day when they will be able to design a clock that's so precise, it can detect dark matter.

Physicists imagine a day when they will be able to design a clock that's so precise, it will be used to detect subtle disturbances in space-time or to find the elusive dark matter that tugs on everything yet emits no light. The ticking of this clock will be almost perfect.

That dream may not be far off: A group of researchers has created a clock that, with some tweaks, could be four to five times more precise than the world's best clocks. To put that into perspective, if today's most precise clocks started ticking at the birth of the universe, they would be off by only half a second today; with more improvements, this new clock has the potential to be off by only 0.1 second.

"Atomic clocks are by far the most precise instruments mankind has ever made by many orders of magnitude," said Vladan Vuleti, a professor of physics at MIT and senior author of a recent paper describing the work. Now, "we are pushing this boundary" further, he added. ...

@#3 ... When I read things like this I wonder what the accuracy is compared to, the clock will not gain or lose the relative to what? ...

That is a great point to raise.

To explain my view, allow me to take a step back and bore you with a true story from a prior life of mine ...

OK, I was responsible for the engineering aspect of IT in a company I worked for. As such, i had many conversations with the manager in charge of the IT operations and also the techs in IT who toiled to keep things running.

One time I was trying to track down an anomaly that seemed to occur with three different servers in the computer room.

As I tried to trace the ~event~ among those servers, one of the first things I noticed was that the timestamps on the system logs were, I'll be kind, not in agreement.

Stated differently, an event that I knew occurred at the same time on three servers was presented in the logs of those servers as occurring a couple minutes apart.

So, I asked a question ... how are the clocks on those servers set. The answer was, when the server is started, the tech inserts the time from their watch.

That ain't good. When trying to trace events across multiple servers, the time clocks of those servers need to agree within a needed resolution.

So, I raised an issue, and the IT manager then put into place a substantial NTP infrastructure for the servers in the company.

The company servers were now all within milliseconds of each other, which made trouble-shooting so much easier. Because I could then look at the log files and see how things occurred relative to other events. (kudos to you if you are still hanging in here)

OK, that is a long way around to saying a simple thing, if you want to look at what is happening concurrently, the clock you use must provide the resolution you need to attain that goal.

ponsible for the engineering aspect of IT in a company I worked for. As such, I had many conversations with the manager in charge of the IT operations and also the techs in IT who toiled to keep things running.

One time I was trying to track down an anomaly that seemed to occur with three different servers in the computer room.

As I tried to trace the ~event~ among those servers, one of the first things I noticed was that the timestamps on the system logs were, I'll be kind, not in agreement.

Stated differently, an event that I knew occurred at the same time on two servers was presented in the logs of those two servers as occurring a couple minutes apart.

So, I asked a question ... how are the clocks on those servers set. The answer was, when the server is started, the tech inserts the time from their watch.

I raised an issue, and the IT manager then put into place a substantial NTP infrastructure for the servers on the company. They were now all within milliseconds of each other, which made trouble-shooting so much easier. Because I could then look at the log files and see how things occurred relative to other events. (kudos to you if you are still hanging in here)

OK, that is a long way around to saying a simple thing, if you want to look at what is happening concurrently, the clock you use must provide the resolution you need to attain that goal.

@#4

Wow, I messed up the cut 'n' paste on that one.

Ignore or enjoy everything after... "OK, that is a long way around to saying a simple thing, if you want to look at what is happening concurrently, the clock you use must provide the resolution you need to attain that goal."

That additional stuff was off-screen when I chose to submit the comment.

Apologies.