Well they don't strictly require them, but having that capability increases efficiency, robustness and safety.

They need to be accurate because electricity is fast - so a lot of protection schemes need to have a decision made across very long distances (which breaker, at which point on a 100 mile long transmission line should be fliped to isolate faults or stop "bad things" propagation) with minimal impact to the system as a whole.

They also need to be accurate because a good measure of frequency and phasor at geographically disparate points allows system tuning. A tiny change - e.g. speed up one of the 100s of generators could result in a much smoother, overall more-efficient transmission system. Similarly, adjustments to capacitor banks and transformers can provide slight phase adjustments for optimal power flow. But these resources are hundreds of miles apart - e.g the western half of the US and Canada (and parts of Mexico) (except for texas) is one big system.

Being a large, physical system, with feedback, and also being electricity, you get some very interesting effects to try and reason about. There can be very slow (relatively) oscillations in the system, but at the same time you have many, many high frequency noise signals mixed in to the elecrical signal. To find trends and patterns for the slow oscillations you need a very high sample rate to determine what noise to ignore. And these samples need to be time aligned, because even a perfect wave will have different phases at different points along it's propagation.

Anyway - that's an example I'm familiar with. I hope it made sense, seeing as I may not have had quite enough coffee yet.

But to give a practical example. On something like facebook, if you receive two comments on a post within a millisecond, how do you determine the order that they appear in the list? Each request may hit a different datacentre in the world, yet somehow the machines determine the ordering, and every request sees that ordering from then on. You can't just have a single server, because that couldn't handle the load for the entire world. These kinds of things require very strict temporal ordering, which is why time is such an important thing. This leads to the CAP theorem, and distributed systems in general.

The point of Lamport's paper is that time in distributed systems is a partial ordering, not a total ordering. If you are taking values from hardware clocks, you are using a total ordering.

http://en.wikipedia.org/wiki/Spanner_(database)

I thought relativity says there genuinely isn't (but it's close enough we can fudge it...)

http://en.wikipedia.org/wiki/Relativity_of_simultaneity

Let me stop you right there. If you have a highly distributed system, it's design CAN NOT rely on perfectly synchronized clocks among it's components. That's actually the point of the Lamport paper you cited as well as the OP. I actually started writing a detailed rehash of the Lamport's paper but I realize I'd do a poor job of it at best. Instead, I think it's best to just point to excellent and highly readable entire paper here: http://research.microsoft.com/en-us/um/people/lamport/pubs/t...

At a certain level of precision you have to accept that data only travels at the speed of light and there is no way to have a global ordering that shows data consistently and immediately. So you can use an easy non-immediate method like a vector clock.

Clock minutes out of sync: "Here's a temporary security token, I don't think it's expired" "That credential has expired" "This never came up in testing, I think I'll crash"

Clock seconds out of sync: Log files on different servers can't be merged reliably. Different requests went to different load-balanced servers and now you can't tell what order the logged events happened in.

I need to have an accurate clock to within a few seconds when I sign Amazon S3 files. I have code that gives access to restricted files on S3. To give access, the customer makes a request from my server, I authenticate, sign a new URL and redirect them to the signed S3 URL.

For security reasons, the URL gets a signature that expires after a few seconds. The expiration date is based on X seconds from my servers clock. If my servers time differs from S3 server time then, according to S3, the link could be expired before it's even created.

In theory, a redirect takes a second or less to complete so you'd think an expiration that's 5 seconds in the future would be enough. The reality is, over time, the server clock can differ as much as 1 minute or so from S3's clock. So, I just set the expiration to be 120 seconds into the future and call it a day.

I work in broadcast automation. It's a distributed system and the clocks need to be within a certain tolerance of each other. Historically that's done by having a dedicated piece of timekeeping hardware that dictates the station clock, but recently we've been experimenting with using NTP.

We have one node (A) where you author time-sensitive events, and another node (B) that polls for pages of those events, loops through them and takes some action when they should occur. Without both nodes agreeing somewhat on the time you'll end up missing events.

Or at least that's how I remember my experience managing an unstable (as in ddosed, every irc service in active development, a few in-house bots, etc) IRC network and having read the IRC and IRCv3 specs and unreal's and TS6 server message specs. If I'm wrong I'm sure someone here could correct me.

You can ask for a server's local time, but that is just for information.

There is a recently-added timestamp extension, but that seems to be to correct for delays so clients can record logs correctly. It is not for keeping the IRC network together.

For example, here's a paragraph from the UnrealIRCd server protocol (http://www.unrealircd.com/files/docs/technical/serverprotoco...):

> Unreal is very time-dependant. Users and channels, for example, are timestamped, and if server clocks are not synchronized properly, things can go very wrong very fast. See http://vulnscan.org/UnrealIrcd/faq/#67 for more information on this. Note that there is a slight difference between server time and what is actually reported by the UNIX date command or by the C time() function.

The other major side of IRC server protocol is the TS6 protocol (You can see it by yourself at http://irc-wiki.org/IRCd_Comparison). TS stands for TimeStamp, and you can see how critical timestamps are at https://github.com/avenj/irc-server-pluggable/blob/master/do... and https://github.com/atheme/charybdis/blob/master/doc/technica.... You can see TS are what control almost everything related to nicks, channels and their properties.

Before the implementation of TimeStamps and Services, it was really easy to abuse netsplits to take over channels and people's nicks.

There's a complete explanation at http://codeidol.com/internet/irc/The-IRC-Protocol/Timestamp-... (and of course, a Wikipedia link: http://en.wikipedia.org/wiki/Internet_Relay_Chat#Timestampin...).

I'll say that in about 10 years of working on multi-player games, I've never once put a wall, or other absolute time on the wire for any purpose than just printing server time to the player for informational purposes.

However, if you mean that all multiplayer games are typically played across "clusters of machines" and thus require time-sync then my original point addressed that.

Here's an interesting paper describing the software implementation of certain features that are usually handled by the hardware (well, by software running on the baseband processor): http://people.freebsd.org/~sam/FreeBSD_TDMA-20090921.pdf.