On Sat, Jul 09, 2011 at 07:52:58AM -0400, Nick Holland wrote: >On 07/09/11 03:57, Maurice Janssen wrote: >> Hi, >> >> Is it possible to somehow force a program to run on a single CPU in an >> SMP system? >> The reason I ask that on some SMP-capable architectures, I'm having some >> problems with ntpd. On hppa and sgi, the clock won't sync because ntpd >> sees replies with negative delay: >> >> Jul 9 08:58:19 hppa ntpd[21406]: reply from 192.168.4.12: negative >> delay -0.854615s, next query 3120s >> >> (reported as PR6592) >> >> If I run the bsd.sp kernel, the negative delays are gone and ntpd syncs >> without any problem. I was wondering if the problem would occur if I >> could limit ntpd to a single CPU. Diving into the code is way beyond my >> skills, so I was hoping that there is a utility like nice to achieve this. >> >> Thanks, >> Maurice > >Things aren't that simple. >Time is an illusion. Lunch time, doubly so >(obligatory Hitchhiker's quote) >Time on computers is complicated, doubly so on a multiprocessor system. > >ntpd isn't your problem, it's time on the SMP system. Fiddling with >processor affinity (trying to attach particular tasks to particular >CPUs) wouldn't help if you could (and you can't).
OK, thanks for making that clear. >Is time really drifting (consistently increasing error in one direction) >on these systems? Or is it just "jittering" around proper time? The hppa was about 10 seconds behind proper time since boot (the machine is not powered on anymore). The delay was quite stable. The sgi was close to proper time (within one second) and finally synced the clocked after about 4 hours. But the 'negative delay' lines keep appearing in /var/log/daemon: Jul 9 07:10:40 sgi ntpd[25403]: ntp engine ready Jul 9 07:11:47 sgi ntpd[7566]: set local clock to Sat Jul 9 07:11:47 CEST 2011 (offset 66.702436s) Jul 9 07:11:53 sgi ntpd[25403]: reply from 192.168.4.10: negative delay -0.422241s, next query 3298s Jul 9 07:11:55 sgi ntpd[25403]: reply from 192.168.4.12: negative delay -0.420484s, next query 3071s Jul 9 08:03:06 sgi ntpd[25403]: 0 out of 2 peers valid Jul 9 08:03:06 sgi ntpd[25403]: bad peer ntp.z74.net (192.168.4.10) Jul 9 08:03:06 sgi ntpd[25403]: bad peer ntp2.z74.net (192.168.4.12) Jul 9 08:03:06 sgi ntpd[25403]: reply from 192.168.4.12: negative delay -0.419880s, next query 3052s Jul 9 08:07:02 sgi ntpd[25403]: reply from 192.168.4.10: negative delay -0.422318s, next query 3238s Jul 9 08:53:58 sgi ntpd[25403]: reply from 192.168.4.12: negative delay -0.419919s, next query 3083s Jul 9 09:00:59 sgi ntpd[25403]: peer 192.168.4.10 now valid Jul 9 09:01:22 sgi ntpd[25403]: reply from 192.168.4.10: negative delay -0.422266s, next query 3053s Jul 9 09:45:21 sgi ntpd[25403]: reply from 192.168.4.12: negative delay -0.420109s, next query 3036s Jul 9 09:52:46 sgi ntpd[27014]: adjusting local clock by -0.370742s Jul 9 09:53:17 sgi ntpd[25403]: reply from 192.168.4.10: negative delay -0.415123s, next query 3068s Jul 9 10:36:11 sgi ntpd[25403]: peer 192.168.4.12 now valid Jul 9 10:38:47 sgi ntpd[25403]: reply from 192.168.4.12: negative delay -0.420481s, next query 3214s Jul 9 10:44:24 sgi ntpd[25403]: reply from 192.168.4.10: negative delay -0.422004s, next query 3188s Jul 9 11:32:21 sgi ntpd[25403]: reply from 192.168.4.12: negative delay -0.420039s, next query 3204s Jul 9 11:38:39 sgi ntpd[27014]: adjusting local clock by 0.099333s Jul 9 11:38:38 sgi ntpd[25403]: clock is now synced Jul 9 11:39:09 sgi ntpd[25403]: reply from 192.168.4.10: negative delay -0.422172s, next query 3257s Jul 9 12:25:45 sgi ntpd[25403]: reply from 192.168.4.12: negative delay -0.419923s, next query 3077s and this keeps on going. >If it >is really drifting, you should probably put in a problem report on this. I got an email from Joel Sing, he's going to take a closer look. Thanks, Maurice
