time drift (again)

Andy Stubbs andrew.stubbs at activehotels.com
Thu Jan 30 09:19:01 CST 2003

Hash: SHA1

Hi Brian,

Thanks for your suggestions. Yes, I have a couple of 2500s and they're not
too bad compared to the 2600s and the 1650s, or at least that's my
perception.  I'll see how my mileage varies if I turn omsa off. 4 seconds
is as you say, still a lot though (imagine my incredulity at 20 minutes!).
I'd rather have omsa on though, if only so I can generate a lovely 3
dimensional model of the temperature gradients in our racks (just kidding,
but now I think of it...)

As to the solution for ntp, yes that should do the trick! D'Oh! Can't see 
the wood for the trees.

Thanks again,


On Thu, 30 Jan 2003, Brian Smith wrote:

> 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
> experience.
> 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)                                           
>                     linux-poweredge-admin@                                                                                  
>                     dell.com                                                                                                
>                     01/30/03 09:00 AM                                                                                       
> Hash: SHA1
> Hi,
> 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
> offender.
> or, alternatively
> (b) does anybody know how to specify an interface and/or a source IP
> address for ntp transmit udp packets on/from?
> Regards,
> Andy
> - --
> 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
> kVuv81AeK1fB7P2R/k4/FKg=
> =ydQA
> _______________________________________________
> Linux-PowerEdge mailing list
> Linux-PowerEdge at dell.com
> http://lists.us.dell.com/mailman/listinfo/linux-poweredge
> Please read the FAQ at http://lists.us.dell.com/faq or search the list
> archives at http://lists.us.dell.com/htdig/

- -- 
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


More information about the Linux-PowerEdge mailing list