Nice hat tip to Erlang at the bottom - it automatically runs the clock faster to gracefully account for missing time, say, when a laptop is closed for a few hours. it's pretty useful considering that pretty much every process is running on timers.

In what cases is it better to catch up rather than just discard missed timer events? In the example you give of a laptop being closed for several hours, it seems a lot of possibly-useless work will be performed running, say, an accelerated input loop. Does Erlang let you specify that events should be dropped if they get behind?

This kind of reminds me of farbrausch's kkapture tool for recording demoscene prods. http://www.farb-rausch.de/~fg/kkapture/ It hooks into a bunch of popular ways of getting the current time, and just returns the previous time + some preset delta. Specifically, even if it takes six seconds to render a single frame of a demo, when the program updates its timer to make the next frame, kkapture will tell it that only (say) 1/30 of a second has passed. That way, if you encode each rendered frame to a video, it plays back at a smooth 30 fps even though it took much longer than 1/30 of a second to render each frame.

I always thought that this is exactly the way how ntpd does set the clock. Apart from fact that ntpd does it by interacting with kernel directly without any userspace hacks.

I think ntpd only does it for small deviations (+-128ms by default) and only slews the clock by a small margin. Larger changes are just stepped.

Google's got it cached: http://webcache.googleusercontent.com/search?q=cache:https:/...

What would be the way to fix a too slow server then? Slow down all your other servers clocks until they catch up with the laggard?

Speed the clock up.

Either speed up the clock and the hole in the logs doesn't show up or just set it forward and document the hole.

Could libfaketime be used to speed-rip streaming videos where the rate limiting is done on the client rather than the server?

What program in particular do you have in mind?

Youtube does the rate limiting on the server, it seems: the download starts fast when you seek, but decays to the actual video bitrate over time. In that case, your client can't do much about it.

But in general, you can't trust the client, because you can't trust the client's libraries or OS (or that the "real" client is even running). In this day and age of cheap hardware-assisted virtualization, even the OS can't trust the hardware.

I wasn't thinking of any particular program, but I did consider an alternative use: slowing down Flash to allow frame-synced image capture of video or vector animation. It wouldn't be a speed rip by any means, but you could record the audio in one pass at normal speed, then screen grab the video in another pass at half or slower speed to ensure no frames are dropped. Obviously it would be better if you could write your own fully-compatible Flash replacement that output to .mkv instead of X11.

Edit: sp332 gives a concrete example in this post: http://news.ycombinator.com/item?id=2527380

It seems that it only handles wall clock related functions, not various timers and other timing related functionality, so almost certainly not.