Comment #2 on issue 389 by [email protected]: internal clock drift from
system time
https://code.google.com/p/memcached/issues/detail?id=389
Hmm, doesn't quite sound that a fix will make it into one of the next
releases :(
Also I'm not sure if smooth correction can even be sanely implemented at an
application
level without hackery (duplicating much of ntpd or reading ntpd's
drift-file to get the
current frequency offset).
From ntp's documentation (cf. http://doc.ntp.org/4.1.1/miscopt.htm ):
driftfile driftfile
This command specifies the name of the file used to record the
frequency offset of
the local clock oscillator. If the file exists, it is read at startup
in order to
set the initial frequency offset and then updated once per hour with
the current
frequency offset computed by the daemon. If the file does not exist or
this command
is not given, the initial frequency offset is assumed zero. In this
case, it may
take some hours for the frequency to stabilize and the residual timing
errors to
subside.
The file format consists of a single line containing a single floating
point number,
which records the frequency offset measured in parts-per-million
(PPM). [...]
What about this idea:
- keep the internal counter (to avoid syscall overhead)
- add a new memcached parameter to enable the following behavior (default
off)
- => sync the internal counter every minute (or so) to the system time
- spew out an error message if there's a big difference (say 30s?)
- document the parameter (list preconditions and possible consequences if
not met)
Some thoughts and conclusions:
- many (especially distributed) systems depend on smooth time correction
anyway
- memcached is about putting unneeded RAM on remote machines to good use
A distributed application that stores keys with validity >30s may assume
all of the
following at once:
- local system time == local memcached time
- local system time == remote memcached time
- remote system time == local memcached time
- remote system time == remote memcached time
- jumping system time is not the application's problem. It's an ops problem
- fix at the system level instead of the application level (don't fix what
isn't broken)
- probably less code to touch
Maybe it does make sense to introduce internal smoothing for non-Linux or
existing users
with broken time syncronisation that would be caught by surprise by an
altered default
behavior of memcached.
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
---
You received this message because you are subscribed to the Google Groups "memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
