time drift (again)

Brian Smith BSmith at lyrix.com
Thu Jan 30 08:54:01 CST 2003

Hi Andy,

As a suggestion, if you are using OMSA to monitor your systems, shut it
down and disable it.  I did a little test last week on a PE2650 chassis.  I
disabled NTP on the chassis during the test.  I let OMSA run for a few days
and averaged 7 minutes of time loss per day.  Then I disabled OMSA (by
running "service dellomsa stop" and "chkconfig dellomsa off") and only
averaged 3 to 4 seconds of time loss per day.  Note that the esm.o OMSA
driver module was still loaded in memory, but was never accessed.  While
not as bad, I think 4 seconds of loss per day is still pretty bad, even for
a PC.  I am now convinced the OMSA (or esm.o driver module) is the culprit
to most of the time loss when OMSA is enabled.  Dell has acknowledged this
and they are working on it.  However I believe there is also a minor clock
problem with the Dell PowerEdge series (specifically the PE1650, PE2650,
and PE2600 which are the only in-production chassis I have any experience
with).  The PE2500 (now discontinued) is much better at keeping time in my

As for your NTP trouble, if I understand your question correctly, I would
suggest creating a static route in the kernel route table for the NTP
server's address with the gateway IP of the network interface you wish to
use.  Example:

route add -host <ntp_server_ip> gw <network_interface_ip>

where <ntp_server_ip> is the IP address of your NTP server
and <network_interface_ip> is the IP address of the network interface
(network card) where you want the packets to come out of so your NAT works
its magic.

- Brian

                    Andy Stubbs                                                                                             
                    <andrew.stubbs at activeh        To:     <Linux-PowerEdge at dell.com>                                        
                    otels.com>                    cc:                                                                       
                    Sent by:                      Subject:     time drift (again)                                           
                    01/30/03 09:00 AM                                                                                       

Hash: SHA1


A few people on this list have been mentioning having problems with time
drift. I've also been experiencing varying degrees of drift on each of our
9 different machines: slowing from a second or so to 20 mins per day.
Trawling the archives, I've seen it mentioned that some people may think
this is kernel-related (and not perhaps dell overclocking the servers ;) -
although, I suppose they would have to be underclocked to lose time...).

So, I'm trying to come up with a sensible solution to this rather irksome
problem by syncing to the hwclock each night and running ntp to try and
keep this drift at bay. Unfortunately, due to some cunning NAT that we use
on our routers I need to specify which source IP address ntp uses; ntp
seems determined to use the default route, which is no good - I might be
able to reconfigure our routers to get around it, but I'd rather not...).

I suppose my questions boil down to

(a) does anybody understand this time-drift problem and how I can make it
stop or manage it better. I have 6 dual P 3 machines, 2 up Xeon machines
(with ht enabled) - all running 2.4.18-10smp, and one up P3 machine
running 2.4.18-10. It's one of the Xeons (a PE2600) which is the worst

or, alternatively

(b) does anybody know how to specify an interface and/or a source IP
address for ntp transmit udp packets on/from?



- --
Andy Stubbs, B.A., Ph.D.
Network Manager, Active Hotels Ltd.
+44 1223 578106

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


Linux-PowerEdge mailing list
Linux-PowerEdge at dell.com
Please read the FAQ at http://lists.us.dell.com/faq or search the list
archives at http://lists.us.dell.com/htdig/

More information about the Linux-PowerEdge mailing list