On Wed, 30 Jun 2004 11:22:50 +1000 Zenaan Harkness <zen@freedbms.net> wrote: > Hi, I am trying to synchronize the time between two boxes. I'm playing > with ntp*. > > * If you know of any digital X-based clock program that displays in > deci-seconds (or finer) resolution, I would very much like to know. > > * The problem below had me totally off-track for literally the last few > weeks, to my (right this moment) great frustration: gkrellmd has a > sycnhronization/ wraparound display problem with the clock. > > This is what happens: every so many, eg. 15, seconds, the clock pauses > for a second. Then it some time (eg. 15 seconds) later it skips forward > two seconds instead of one. > > I've tried setting the update frequency on the gkrellm client and server > to be the same, and tried both low (3Hz) and high (20Hz) frequencies. > They all display essentially the same problem. > > Here's an obvious solution that would be satisfactory, within the > tolerance of (most people's) human vision: > > * have an option to display tenths-of-a-second (ie. an extra order of > precision - deci-seconds or whatever they're called), and perhaps also > have a recommendation in the README for gkrellmd that for reasonably > accurate time keeping, use "deci-seconds + 10Hz update frequency" > (assuming of course that this actually works :). > > If there is any hope of getting such a feature added, I will send you a > triple-smiley and lots of appreciation. > > If there is a hope, or a better GUI way to monitor my servers, please > let me know. I see it's a time sampling beating effect caused by the clock seconds display being updated only once per second regardless of any update interval settings. If you can compile a new gkrellm (you don't need to install a new gkrellmd server), try the attached patch which is against gkrellm 2.2.1. If you need a patch for another version, let me know. With the patch, the sample beating drift will be reduced to the gkrellmd update sub second interval. So if the gkrellmd update interval is 3, there can be a 1/3 second periodic drift on the client displayed seconds. So to get the accuracy you want now should just take adjusting the update intervals. Thanks for the bug report. Bill -------- http://gkrellm.net
Attachment:
gkrellm-clock-patch
Description: Binary data