Dror Cohen <[EMAIL PROTECTED]> writes:
> Hi all,
> While working on a Linux cluster with kernel version 2.4.27 we've
> encountered a consistent clock drift problem. We have devised a fix
The normal fix is to use NTP.
The clock drift problem on lost ticks is known, but I don't
think your change i
Dror Cohen wrote:
Hi all,
While working on a Linux cluster with kernel version 2.4.27 we've
encountered a consistent clock drift problem. We have devised a fix
for this problem which is based on the Pentium's TSC clock.
Any reason why you can't just use NTP?
Chris
-
To unsubscribe from this list: s
Dror Cohen wrote:
Hi all,
While working on a Linux cluster with kernel version 2.4.27 we've
encountered a consistent clock drift problem. We have devised a fix
for this problem which is based on the Pentium's TSC clock. We'd
appreciate any comments on the validity of the proposed solution and
on wh
---
Time Drift Compensation on Linux Clusters
1. Background
During the operation of the 2.4.27 kernel under intense IO conditions a clock
drift was detected. The system time, as received by gettimeofday() began lagging
behind the wall clock.
All PCs have a battery driven hardware clock. This clock is used
4 matches
Mail list logo
