Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Hi, Thank you all for your replies, sorry I have not got back with comments before, got involved in other things at work etc. Having got my hands on another 8 units from production I set them all up in a rack. Of the 8 units 4 of them locked up when first synchronised to ntp, with the drift file being stuck at -500. These 4 units where then left for 48 hours and, they where still in the same condition that was: - -- Drift file read between -495 and -500, there seemed to be a small changes over time but mostly -500 -- Using ntpq -p to monitor the lock, you could see the time initially being within 15ms of the server, then over a few minutes make its way up to an offset of 500ms, when a step change was made and the hole process started all over again. -- The good units where locked to the same time server and where within +/- 15ms or better, the server is local but locked to PPS ntp servers over the internet ... not perfect as the delay and jitter changes through the day as internet usage changes. Have seen then locked to within 2ms when used on a customer's network with a local GPS controlled server. After 48 hours of being in this stuck condition I logged in and stopped the ntp process, cleared the drift file back to 0, used ntpdate to set the system time to that on the server and re-started the ntp process. (The drift file will always start at zero on these systems as they operate from read only flash, the /var directory is constructed in /dev/shm at boot) After 3 hours or so I checked them, and all 8 of the systems where locked to the server, with drift files ranging from about -20 to -75, so all the processor clocks don't see to fare off. Now from this I can only conclude its a problem with the control algorithm in ntp, that under some start conditions gets stuck applying the maximum compensation. If it were a problem with the hardware I would have expected it to still be there after stopping and re-starting the ntp process. If a transient problem at power up with the hardware why still stuck after 48 hours. Looking at the differences between the systems more I found one of them that had initially failed to lock had a completely dead CMOS battery. Apparently production had received a batch of 100 dead batteries, and this was one that slipped through the net. Looking at all the others turned up one other dead battery, but that was form one that locked Ok. All of the Real time clocks in the units where set to some time in December 2008, having never been set, the BIOS was written around then so it seems that's the time they start with then the battery is first fitted. This is in part to do with the way the units are used with a read only file system, they are designed to just be turned off rather than shut down, so the system time never gets written to the RTC, as I understand this is normally done during shutdown. (In normal use these units will be on all the time) I have since tried to reproduce the lockup with these units, returning there flash drive to the production image and starting all over again, with the RTC again set to different times in the past and future. Non of these efforts has so far reproduced the right conditions, they always seem to lock with no problems at all. I have seen one other unit recently that locked up, that was a unit being used by one of the software development engineers, who had been on holiday for two weeks and when he returned and powered his unit up, it failed to lock. Unfortunately I did not get to examine it before he had shut it down and re-booted so don't know the status of the RTC when it was booted, the sundown had set it to the server time. So may be some merit in testing a few more systems that have been off for a while and see what happens? Think my next step is to get the software, or may be just a cron script to a) Set the RTC to the system time once locked to NTP b) If the drift file is -500, stop ntp, set time to the server time, restart ntp with zeroed drift file. PS systems are running Linux version 2.6.22.18-0.2-default (ge...@buildhost) (gcc version 4.2.1 (SUSE Linux)) Dave ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
David Hawkins wrote: (The drift file will always start at zero on these systems as they operate from read only flash, the /var directory is constructed in /dev/shm at boot) The correct cold start condition for the drift file is to be not present at all. This will cause ntpd to do a frequency calibration. If it gets cleared to zero every reboot, it is no use at all. It is valid to clear it to a value calibrated for the specific machine. Now from this I can only conclude its a problem with the control algorithm in ntp, that under some start conditions gets stuck applying the maximum compensation. If it were a problem with the hardware I would have expected On Linux, unless you have disabled it, directly, or indirectly (e.g. by using -x or otherwise overriding the step limit) this code is part of the Linux kernel, not part of ntpd. it to still be there after stopping and re-starting the ntp process. If a transient problem at power up with the hardware why still stuck after 48 hours. system, they are designed to just be turned off rather than shut down, so the system time never gets written to the RTC, as I understand this is normally done during shutdown. (In normal use these units will be on all the time) On Linux, if the system is synchronized and you haven't done anything to disable the kernel discipline, the RTC is updated every 11 minutes. I don't think this updates the hours or higher order digits. This behaviour is somewhat controversial (I think because it introduces RTC errors that are larger than those that could be achieved after correcting for the systematic drift rate of the RTC). ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
David Hawkins david.j.hawk...@btinternet.com writes: Hi, Thank you all for your replies, sorry I have not got back with comments before, got involved in other things at work etc. Having got my hands on another 8 units from production I set them all up in a rack. Of the 8 units 4 of them locked up when first synchronised to ntp, with the drift file being stuck at -500. These 4 units where then left for 48 hours and, they where still in the same condition that was: - -- Drift file read between -495 and -500, there seemed to be a small changes over time but mostly -500 -- Using ntpq -p to monitor the lock, you could see the time initially being within 15ms of the server, then over a few minutes make its way up to an offset of 500ms, when a step change was made and the hole process started all over again. I do not know what a few minutes means -- 10 min, 1000 min. If it is 10 min this would indicate a drift rate of about 1000PPM which ntp certainly cannot fix. -- The good units where locked to the same time server and where within +/- 15ms or better, the server is local but locked to PPS ntp servers over the internet ... not perfect as the delay and jitter changes through the day as internet usage changes. Have seen then locked to within 2ms when used on a customer's network with a local GPS controlled server. After 48 hours of being in this stuck condition I logged in and stopped the ntp process, cleared the drift file back to 0, used ntpdate to set the system time to that on the server and re-started the ntp process. (The drift file will always start at zero on these systems as they operate from read only flash, the /var directory is constructed in /dev/shm at boot) After 3 hours or so I checked them, and all 8 of the systems where locked to the server, with drift files ranging from about -20 to -75, so all the processor clocks don't see to fare off. Now from this I can only conclude its a problem with the control algorithm in ntp, that under some start conditions gets stuck applying the maximum compensation. If it were a problem with the hardware I would have expected it to still be there after stopping and re-starting the ntp process. If a transient problem at power up with the hardware why still stuck after 48 hours. Looking at the differences between the systems more I found one of them that had initially failed to lock had a completely dead CMOS battery. Apparently production had received a batch of 100 dead batteries, and this was one that slipped through the net. Looking at all the others turned up one other dead battery, but that was form one that locked Ok. All of the Real time clocks in the units where set to some time in December 2008, having never been set, the BIOS was written around then so it seems that's the time they start with then the battery is first fitted. This is in part to do with the way the units are used with a read only file system, they are designed to just be turned off rather than shut down, so the system time never gets written to the RTC, as I understand this is normally done during shutdown. (In normal use these units will be on all the time) I have since tried to reproduce the lockup with these units, returning there flash drive to the production image and starting all over again, with the RTC again set to different times in the past and future. Non of these efforts has so far reproduced the right conditions, they always seem to lock with no problems at all. I have seen one other unit recently that locked up, that was a unit being used by one of the software development engineers, who had been on holiday for two weeks and when he returned and powered his unit up, it failed to lock. Unfortunately I did not get to examine it before he had shut it down and re-booted so don't know the status of the RTC when it was booted, the sundown had set it to the server time. So may be some merit in testing a few more systems that have been off for a while and see what happens? Think my next step is to get the software, or may be just a cron script to a) Set the RTC to the system time once locked to NTP b) If the drift file is -500, stop ntp, set time to the server time, restart ntp with zeroed drift file. PS systems are running Linux version 2.6.22.18-0.2-default (ge...@buildhost) (gcc version 4.2.1 (SUSE Linux)) Linux has had some problem with its calibration of the system clock's time and it is possible that this resulted in a clock which was running way out of spec (ie say near 500PPM out). This would of course make it impossible for ntp to sync the clock. You could try to manually set the rate ( adjtimex with the --tick adjustment) to compensate for the anomalous drift rate. Dave ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
In article hb57u6$26...@news.eternal-september.org,
n...@blacklist.anitech-systems.invalid says...
Unruh wrote:
BlackLists writes:
For anyone that cared enough about emissions,
(and not about price) they could always get a
EMSEC / TEMPEST, Level A / 1, PC.
{I've worked on a few TEMPEST PCs (decades in the past),
it often takes 15 minutes of removing shielding panels
just to get to where you can remove the shielded container
a component (e.g. hard drive) is inside.
In one case to make it so that it does not destroy other
people's enjoyment of their system, and the other to make
sure a determined adversary cannot make use of yours.
Different boxes for different folks.
Both are aimed at stopping unintentional emissions.
Sure a TEMPEST PC would far exceed CE EMC / FCC Part 15 B, ...
However weren't a few posts just complaining that those
standards were not strict enough.
TEMPEST is just stricter unintentional emission standards.
In essance yes, but there are other parts of it too, in regards to
trying not to create any likely usable EMI that may leak out...
DJB
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
On Wed, 14 Oct 2009, someone wrote: Both are aimed at stopping unintentional emissions. Sure a TEMPEST PC would far exceed CE EMC / FCC Part 15 B, ... Couldn't the goals of TEMPEST be achieved by a computer that deliberately produces random noise, so as to drown out the unintended signal? The hams sure wouldn't like that. Although it would be unlikely to happen. The military security people are all about verification, and it's easier to verify silence than to verify that noise is random. And at a guess, they probably have a lot more sympathy to radio users than, say, BT Group... Michael Deutschmann mich...@talamasca.ocis.net ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Michael Deutschmann wrote: someone wrote: Both are aimed at stopping unintentional emissions. Sure a TEMPEST PC would far exceed CE EMC / FCC Part 15 B, ... Couldn't the goals of TEMPEST be achieved by a computer that deliberately produces random noise, so as to drown out the unintended signal? The hams sure wouldn't like that. They have emission limits, just like the commercial / consumer rules, just much lower. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
On Wednesday 14 October 2009 06:20:21 Unruh wrote:
E-Mail Sent to this address will be added to the BlackLists
n...@blacklist.anitech-systems.invalid writes:
Rick Jones wrote:
... EMC / EMI, Unintentional / Incidental, Radiators
And/or better educated customers willing and able to
understand the value of a better crafted system when
comparing to the one that didn't spend the pennies.
For anyone that cared enough about emissions, (and not about price)
they could always get a EMSEC / TEMPEST, Level A / 1, PC.
{I've worked on a few TEMPEST PCs (decades in the past),
it often takes 15 minutes of removing shielding panels
just to get to where you can remove the shielded container
a component (e.g. hard drive) is inside.
In one case to make it so that it does not destroy other people's enjoyment
of their system, and the other to make sure a determined adversary cannot
make use of yours. Different boxes for different folks.
Guys, this is seriously drifting off. There is an open question on the
syncrhonisation of NTP. Does anyone want to answer it? I added a response to
the original post, but that part of the thread did not get any more attention,
so I take it that it was no solution.
Best regards,
Frans
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote: Rick Jones wrote: For anyone that cared enough about emissions, (and not about price) they could always get a EMSEC / TEMPEST, Level A / 1, PC. In one case to make it so that it does not destroy other people's enjoyment of their system, and the other to make sure a determined adversary cannot make use of yours. Different boxes for different folks. Tempest is about making sure that insufficient radiation exists to be able to recover a useful signal. Normal PC screening is to prevent sufficient noise from escaping to cause problems to others. If you can recover useful information above the background noise, the machine is definitely compromising any nearby receivers. Tempest isn't about stopping people accessing your computer, although normal EMC screening is, in part, about stopping local radio transmitters upsetting the machine. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote:
BlackLists writes:
For anyone that cared enough about emissions,
(and not about price) they could always get a
EMSEC / TEMPEST, Level A / 1, PC.
{I've worked on a few TEMPEST PCs (decades in the past),
it often takes 15 minutes of removing shielding panels
just to get to where you can remove the shielded container
a component (e.g. hard drive) is inside.
In one case to make it so that it does not destroy other
people's enjoyment of their system, and the other to make
sure a determined adversary cannot make use of yours.
Different boxes for different folks.
Both are aimed at stopping unintentional emissions.
Sure a TEMPEST PC would far exceed CE EMC / FCC Part 15 B, ...
However weren't a few posts just complaining that those
standards were not strict enough.
TEMPEST is just stricter unintentional emission standards.
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh unruh-s...@physics.ubc.ca wrote:
E-Mail Sent to this address will be added to the BlackLists
n...@blacklist.anitech-systems.invalid writes:
Rick Jones wrote:
... EMC / EMI, Unintentional / Incidental, Radiators
And/or better educated customers willing and able to understand
the value of a better crafted system when comparing to the one
that didn't spend the pennies.
For anyone that cared enough about emissions, (and not about
price) they could always get a EMSEC / TEMPEST, Level A / 1, PC.
{I've worked on a few TEMPEST PCs (decades in the past), it often
takes 15 minutes of removing shielding panels just to get to where
you can remove the shielded container a component (e.g. hard
drive) is inside.
In one case to make it so that it does not destroy other people's
enjoyment of their system, and the other to make sure a determined
adversary cannot make use of yours. Different boxes for different
folks.
I resisted mentioning TEMPEST since I figured it would be overkill
when perhaps just TEAPOT would be sufficient (perhaps one could have
an aftermarket to put a TEMPEST in a TEAPOT...)
But the main point I wanted to make was that there are several actors
involved in getting where we are today, and it isn't necessarily
_just_ the people who's emails end in .com or .gov
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
E-Mail Sent to this address will be added to the BlackLists
n...@blacklist.anitech-systems.invalid writes:
Unruh wrote:
BlackLists writes:
For anyone that cared enough about emissions,
(and not about price) they could always get a
EMSEC / TEMPEST, Level A / 1, PC.
{I've worked on a few TEMPEST PCs (decades in the past),
it often takes 15 minutes of removing shielding panels
just to get to where you can remove the shielded container
a component (e.g. hard drive) is inside.
In one case to make it so that it does not destroy other
people's enjoyment of their system, and the other to make
sure a determined adversary cannot make use of yours.
Different boxes for different folks.
Both are aimed at stopping unintentional emissions.
Sure a TEMPEST PC would far exceed CE EMC / FCC Part 15 B, ...
However weren't a few posts just complaining that those
standards were not strict enough.
TEMPEST is just stricter unintentional emission standards.
Of course. That was what I said. But the purpose is different. Tempest
is to make sure that the emissions cannot be used by someone else to
determine what is going on inside your box. The other standards are to
prevent your machine from ruining other people's use of the
electromagnetic spectrum. That is a much more relaxed standard. But the
way the formal regulations are written allow one to continue emitting huge
amounts of
radiation, messing up other people's use of the radiation spectrum, as
long as it is spread around and not all emitted at some specific
frequency. Ie, the standard should probably limit the amount of
radiation emitted, not the amount emitted in some very narrow bandwidth,
or rather it should limit both.
Note that Tempest is where you want to limit the radiation and thus have
a strong incentive to make sure you emit as little as possible. The
radiation standards are where others want you to limit your radiation
and thus you have an incentive to try to find a way around the law to
save those few pennies that shielding would cost.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
In article 1254844523.604...@news1nwk, brian.utterb...@sun.com says... Unruh wrote: * The processor card uses a PCI clock generator capable of spread spectrum output, this is always enabled and not controllable from the BIOS - the chip No idea what spread spectrum means for a clock. Spread spectrum clock signals are a dirty trick to get by EMI regulations. When measuring the EMI generated by a piece of hardware, the interference signal is integrated over time and the frequency. Thus for a given amount of energy leaked, if the clock signal was completely steady all of the energy released would be at that frequency. By modulating the clock signal, the same energy can be leaked, but it is spread out over all of the frequencies, thus lowering the amount of energy leaked at any given frequency. So, the same energy is leaked, but the peak at any given frequency is lower. And since the EMI regulations regulate the peak EMI, a piece of hardware can pass that would not pass if the frequency were constant and steady. It is very easy to implement. Just design your oscillator as a voltage controlled oscillator and feed a sine wave into it. Brian Utterback That, and most things that leak like that, can also be susceptable to incoming EMI. It's a bean counter bodge job, as above to fool EMI measuring receivers, so they don't have to pay to do a propper job in the first place. Real sloppy design, if you have to use spread-spectrum clocks to pass the EMC tests. Such cut price techniques have also been found to foul up other systems that genuinely use spread spectrum communications, clock osc's have harmonics that extend up into the low microwave area. Systems such as BlueTooth, and WiFi, can do odd things as a result that are difficult to track down. Best get it right the first time, it's cheaper in the long run too, but heck, how many carreer bean counters stay anywere for more than a year anyway. I know some so called engineers like that too. Get it to production asap, then leave. Regards. Dave B, who strangely works in EMC! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Dave Baxter wrote: Best get it right the first time, it's cheaper in the long run too, but heck, how many carreer bean counters stay anywere for more than a year anyway. I know some so called engineers like that too. Get it to production asap, then leave. When people doing the manufacturing get paid ~$1.00 USD a day, to manufacture a million PCBs (a ripoff of some other brand board they manufactured in the past), both of the designs were likely two generations old by the time they hit the streets, ... Not likely a lot more engineering going into something where every penny spent is ~$10k USD less in someones pocket. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
E-Mail Sent to this address will be added to the BlackLists n...@blacklist.anitech-systems.invalid writes: Dave Baxter wrote: Best get it right the first time, it's cheaper in the long run too, but heck, how many carreer bean counters stay anywere for more than a year anyway. I know some so called engineers like that too. Get it to production asap, then leave. When people doing the manufacturing get paid ~$1.00 USD a day, to manufacture a million PCBs (a ripoff of some other brand board they manufactured in the past), both of the designs were likely two generations old by the time they hit the streets, ... Not likely a lot more engineering going into something where every penny spent is ~$10k USD less in someones pocket. Yup. That is why you have regulations. It is clear that the present spread spectrum approach is basically an end run around the regulations. The regs were set up based on the idea that things that emit tend to be more or less monofrequency ( radio transmitters, sidebands, microwave ovens, etc), so the regulation framers ( mostly lawyers) regulated the obvious, and the manufacturers, concerned as you say with pennies, did everything they could to fulfil the letter of the law, damn the spirit. When the impact of the evasion hits some people in some other country, it is the letter of the law that will rule, so the regulations need to be more broadly crafted. -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh unruh-s...@physics.ubc.ca wrote: Yup. That is why you have regulations. It is clear that the present spread spectrum approach is basically an end run around the regulations. The regs were set up based on the idea that things that emit tend to be more or less monofrequency ( radio transmitters, sidebands, microwave ovens, etc), so the regulation framers ( mostly lawyers) regulated the obvious, and the manufacturers, concerned as you say with pennies, did everything they could to fulfil the letter of the law, damn the spirit. When the impact of the evasion hits some people in some other country, it is the letter of the law that will rule, so the regulations need to be more broadly crafted. And/or better educated customers willing and able to understand the value of a better crafted system when comparing to the one that didn't spend the pennies. Customers want lower prices, shareholders want greater profits. Something ends-up giving when squeezed between those two. As to it being pennies, or scores of pennies, or hundreds of pennies more, where can one go to veryify that it is indeed pennies? Is it indeed pennies to rework a PCB or redesign a chassis when say ostensibly socket-compatible wizzy new processor Z tickles things one never saw before with processors W, X and Y? rick jones -- I don't interest myself in why. I think more often in terms of when, sometimes where; always how much. - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Rick Jones wrote:
... EMC / EMI, Unintentional / Incidental, Radiators
And/or better educated customers willing and able to
understand the value of a better crafted system when
comparing to the one that didn't spend the pennies.
For anyone that cared enough about emissions, (and not about price)
they could always get a EMSEC / TEMPEST, Level A / 1, PC.
{I've worked on a few TEMPEST PCs (decades in the past),
it often takes 15 minutes of removing shielding panels
just to get to where you can remove the shielded container
a component (e.g. hard drive) is inside.
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
E-Mail Sent to this address will be added to the BlackLists
n...@blacklist.anitech-systems.invalid writes:
Rick Jones wrote:
... EMC / EMI, Unintentional / Incidental, Radiators
And/or better educated customers willing and able to
understand the value of a better crafted system when
comparing to the one that didn't spend the pennies.
For anyone that cared enough about emissions, (and not about price)
they could always get a EMSEC / TEMPEST, Level A / 1, PC.
{I've worked on a few TEMPEST PCs (decades in the past),
it often takes 15 minutes of removing shielding panels
just to get to where you can remove the shielded container
a component (e.g. hard drive) is inside.
In one case to make it so that it does not destroy other people's enjoyment of
their system, and the other to make sure a determined adversary cannot make use
of
yours. Different boxes for different folks.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote: * The processor card uses a PCI clock generator capable of spread spectrum output, this is always enabled and not controllable from the BIOS - the chip No idea what spread spectrum means for a clock. Spread spectrum clock signals are a dirty trick to get by EMI regulations. When measuring the EMI generated by a piece of hardware, the interference signal is integrated over time and the frequency. Thus for a given amount of energy leaked, if the clock signal was completely steady all of the energy released would be at that frequency. By modulating the clock signal, the same energy can be leaked, but it is spread out over all of the frequencies, thus lowering the amount of energy leaked at any given frequency. So, the same energy is leaked, but the peak at any given frequency is lower. And since the EMI regulations regulate the peak EMI, a piece of hardware can pass that would not pass if the frequency were constant and steady. It is very easy to implement. Just design your oscillator as a voltage controlled oscillator and feed a sine wave into it. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
On 2009-10-03, Rob nom...@example.com wrote: Steve Kostecke koste...@ntp.org wrote: In my experience with ntpd warm restarts have never been a problem. YMMV I am talking about the problem where after a couple of restarts you observe that the offset between local time and the external servers is actually increasing, not for just a moment but for a long time, before it loses sync and steps back in to the correct time. This has been observed by many users. s/many/some/ Not by you, apparently. Not across the 15, or so, Linux systems or the half dozen, or so, FreeBSD systems I've had under my control of have had access to at various times. Most of those systems do/did run constantly. But a couple of them were/are laptops. It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. There is no policy of denial. ... but saying don't see it here, YMMV is not much different from it. Not at all. I've personally never observed the behavior you describe. But I'm not questioning your report, either. In fact, no one is questioning the veracity of your, or anyone elses', claims. The simple fact is problems that can't be duplicated are rather difficult to fix. If you wish to report this problem please do so via the NTP bug tracking system at http://bugs.ntp.org/. Before submitting your report please do the following: 1. Upgrade to the current ntp stable _or_ dev release 2. Enable _full_ statistics collection and run ntpd until the problem occurs 3. Attach logs which substantiate your issue to your bug report I am just a user. I install a Linux system from a distributor which includes a recent version of ntpd. I try to get it configured correctly, maybe experimenting with some of the features I read about in the documents. Then I run into problems, that often magically go away when waiting long enough for things to settle down. If your OS vendor is shipping 4.2.4x then you are using a recent enough version of NTP. When I need to find out how to get a new version, compile and install it without disturbing the existing environment in the distribution, It's not that difficult to do if you are open to learning. You can always ask for help here in the news-group on on #ntp at irc.freenode.net. find out how to enable statistics and logging Statistics logging for the current stable release is documented at http://doc.ntp.org/4.2.4/monopt.html Many OSes include statistics logging configuration lines in their sample ntp.conf files. If yours doesn't either ask here in the news-group or on #ntp at irc.freenode.net. Extended testing and data collection will have to be done by developers or by those that want to spend one or several days on this issue. If you have an issue that is specific to a piece of hardware that you own, you're in the best position to run some tests. The next best option is to give a developer access to that system. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
On Saturday 03 October 2009 02:58:03 David Hawkins wrote: Hi I'm using a number of XTX form factor AMD Geode LX (500Mhz) cards at work. (Cannot get to news at work, and have left memory stick with details at work ! so apologies for missing info !) They are running Sues Linux from a read only flash drive, all identical clones other than host names and IP addresses. Most of the time ntp runs with no problems and will lock to a local server with less than 5ms offset, and the drift file comes out at between about -20 and -40. But now and again a system will not get a stable lock, and on investigation the drift file is at the maximum of -500. When I first encountered this I assumed it was a hardware problem with the processor card, just a one off, but now have seen this on around 10 systems out of 30 or so I have tested. When a system shows this fault, powering the unit on and off will almost always solve it, the unit synchronising to the server after a couple of hours with a drift file setting of -20 to -40 like the others. I'm more of a hardware engineer than software, but have now run out things to look at to solve this problem. I have considered / done the following * The drift file is stored in the ram drive /dev/shm so always starts at 00.000 when the system is started. * On a system not locking stopping ntp and restarting having set the drift file to -28, results in the drift going back to -400 over a couple of hours - so not some odd start-up state that confuses the control loop. * The processor card uses a PCI clock generator capable of spread spectrum output, this is always enabled and not controllable from the BIOS - the chip has two settings off and on with a -0.5% spread. Have verified with a spectrum analyser that the cards with good lock and bad lock, have the spread spectrum option enabled. * The cards seem to be more lightly to exhibit the problem when they have been turned off for a day or so. * Power saving modes of the processor are enabled, but understand that the timing is done using the counter timer in the Geode companion chip that runs at a constant 14.13MHz regardless of the power state:- also as all running exactly the same code why would some have problems and not others ? Sorry rather random thoughts but I have now run out of things to look at, have you ever seen a problem like this and even better found a solution ? Dave Dave, did you play around with adjtimex? I once had a machine who's internal clock was so horribly skewed that it would never sync. Tweaking the parms with adjtimex made the clock more stable and NTP could suddenly sync. Best regards, Frans ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh unruh-s...@physics.ubc.ca wrote in message news:lv9ym.47716$ph1.37...@edtnps82... E-Mail Sent to this address will be added to the BlackLists n...@blacklist.griffin-technologies.invalid writes: Unruh wrote: It is an unshielded efficient radiator, the motherboard. Unshielded because the manufacturer does not want to spend the money to shield it. Do you buy / use equipment that you have decided are the source of objectionable levels of EMI? I do not have the equipment to measure the radiation given off. The manufacturers do. If you tell me how I can get the information as to how much it emits, I will certainly include that in my decision process. The motherboard that costs an unexplained ten dollars more than the competition _may_ have spent it on shielding. Guess how many people will buy it? Remember, by your own admission, _you_ _cannot tell_. (Lying on the box? Who'd do such a horrible thing?) Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Maarten Wiltink maar...@kittensandcats.net writes: Unruh unruh-s...@physics.ubc.ca wrote in message news:lv9ym.47716$ph1.37...@edtnps82... E-Mail Sent to this address will be added to the BlackLists n...@blacklist.griffin-technologies.invalid writes: Unruh wrote: It is an unshielded efficient radiator, the motherboard. Unshielded because the manufacturer does not want to spend the money to shield it. Do you buy / use equipment that you have decided are the source of objectionable levels of EMI? I do not have the equipment to measure the radiation given off. The manufacturers do. If you tell me how I can get the information as to how much it emits, I will certainly include that in my decision process. The motherboard that costs an unexplained ten dollars more than the competition _may_ have spent it on shielding. Guess how many people will buy it? Remember, by your own admission, _you_ _cannot tell_. (Lying on the box? Who'd do such a horrible thing?) That is why one has regulations. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh unruh-s...@physics.ubc.ca wrote in message news:_mmym.46645$db2.5...@edtnps83... Maarten Wiltink maar...@kittensandcats.net writes: Unruh unruh-s...@physics.ubc.ca wrote in message news:lv9ym.47716$ph1.37...@edtnps82... E-Mail Sent to this address will be added to the BlackLists n...@blacklist.griffin-technologies.invalid writes: Unruh wrote: It is an unshielded efficient radiator, the motherboard. Unshielded because the manufacturer does not want to spend the money to shield it. Do you buy / use equipment that you have decided are the source of objectionable levels of EMI? I do not have the equipment to measure the radiation given off. The manufacturers do. If you tell me how I can get the information as to how much it emits, I will certainly include that in my decision process. The motherboard that costs an unexplained ten dollars more than the competition _may_ have spent it on shielding. Guess how many people will buy it? Remember, by your own admission, _you_ _cannot tell_. (Lying on the box? Who'd do such a horrible thing?) That is why one has regulations. Indeed. Just imagine the radio interference that e.g. motherboards might cause if there were no rules limiting it. (As another, very practical, example of well-intentioned regulations, there is the 'CE' mark featured on products that should be safe to use. There is a test to determine if your product may carry it. OR - you can simply slap it on and wait to be challenged. Then, if the challenger proves you don't deserve the mark, you have to take it off. A procedure officially sanctioned as 'self-declaration'.) Tebrgwrf, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Maarten Wiltink writes: As another, very practical, example of well-intentioned regulations, there is the 'CE' mark featured on products that should be safe to use. There is a test to determine if your product may carry it. OR - you can simply slap it on and wait to be challenged. Then, if the challenger proves you don't deserve the mark, you have to take it off. A procedure officially sanctioned as 'self-declaration'. Do that with the UL mark in the USA and you will be the defendant is a series of painful and expensive lawsuits. Plus bad publicity. Plus possible criminal prosecution for fraud. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Rob wrote: I am talking about problems at startup time. Even when you keep NTPD running 24x7 you have to start it at some time. That is not a smooth operation. But that problem is denied or ignored. I believe that Dr. Mills position is that the startup period is relatively short and it wasn't worth it (to him at least) to spend a lot of time tracking down what he viewed as transients. This has been reported many times in the newsgroup, and I know of some cases where it was reported via bugzilla. One case of low hanging fruit is that fact that NTP sets the drift frequency at startup and then if iburst is not in use, will correct the offset 5 minutes later. This offset correction is interpreted by the kernel reference code as a drift that has occurred since the frequency was set (i.e. 5 minutes) and then adjusts the frequency incrementally, sometimes putting the frequency at a drastically incorrect value, depending on the initial offset. What it should do is set the initial frequency and then set it again immediately after the first offset correction. Real frequency corrections should not occur until after the first offset correction. This is bug 1044 Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Richard B. Gilbert rgilber...@comcast.net wrote: Unruh wrote: Steve Kostecke koste...@ntp.org writes: On 2009-10-03, Rob nom...@example.com wrote: It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. In my experience with ntpd warm restarts have never been a problem. YMMV It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. There is no policy of denial. There have been extensive discussions on the slow convergence of ntp, and David Mills has been adamant that the current algorithm will not change, and that the slow convergence is a feature that will also not change. It is I agree not a policy of denial. It is a policy of that's not a bug, its a feature. It's a feature! Learn to live with it or write your own NTPD. Dr. Mills is unlikely to change his mind! Chrony and perhaps other products may come closer to meeting your requirements. My statement It seems that the official standpoint is to ignore or deny these problems was meant to point in this direction, but apparently my bad English idiom was again misunderstood. One relatively easy solution is to keep NTPD running 24x7. If you can't or won't do that, NTPD is a poor choice for your requirements! I am talking about problems at startup time. Even when you keep NTPD running 24x7 you have to start it at some time. That is not a smooth operation. But that problem is denied or ignored. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh unruh-s...@physics.ubc.ca wrote in message news:6rmxm.46378$db2.43...@edtnps83... Maarten Wiltink maar...@kittensandcats.net writes: Unruh unruh-s...@physics.ubc.ca wrote in message news:k8yxm.46291$db2.44...@edtnps83... No idea what spread spectrum means for a clock. That there is a certain jitter explicitly introduced in its effective frequency. Probably in the form of a random offset, that averages to zero, to every tick, so you're certain that the long-term frequency doesn't change. I am afraid I am left as confused as before. HOw introducing random offsets would stop the frequency from changing I have no idea. Say you have a clock running at 1 Hz. One tick per second. Naively, you might spread its spectrum by changing the frequency. Let it run at 0.5 Hz some seconds, 1.5 Hz some others. That's two ticks some seconds, two thirds of one others. The average frequency works out to 0.75 Hz. Not what you want. Alternatively, instead of ticking at the top of every second, add a random offset to the time when every tick happens. After an hour, there will have been 3,600 ticks. Still 1 Hz. It sounds like a terrible idea, but that may be ignorance. If you want the best clock possible, it is. But that's not the only consideration. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote: David Lord sn...@lordynet.org writes: I've started replacing ntpd on desktops and notebooks as it's not really appropriate and ntpd -q or ntpdate would be sufficient. It's just that ntpd was installed by default. Using ntpd -q before starting chrony seems to give good results. Why would that do anything? Chrony itself has an option to step the clock on startup if the offset is too large ( user selectable-- if you want to select .128 sec, that is fine) This is just for when using mobile broadband where there is massive latency and switching between GSM modes at start of connections. Ntp.conf with burst (from my own servers) gets initially to within about 20ms but without burst around 100ms at best and more often 1-2s. Desktops on wired network don't really need it but are sometimes connected by mobile so I've kept the same method. Chrony does have a burst option but this has to be called on demand using chronyc and I've not got round to trying that, but if it works ok I'll move to using that. When/if I can get a portable radioclock sorted that should be a better solution. David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Maarten Wiltink maar...@kittensandcats.net writes: Unruh unruh-s...@physics.ubc.ca wrote in message news:6rmxm.46378$db2.43...@edtnps83... Maarten Wiltink maar...@kittensandcats.net writes: Unruh unruh-s...@physics.ubc.ca wrote in message news:k8yxm.46291$db2.44...@edtnps83... No idea what spread spectrum means for a clock. That there is a certain jitter explicitly introduced in its effective frequency. Probably in the form of a random offset, that averages to zero, to every tick, so you're certain that the long-term frequency doesn't change. I am afraid I am left as confused as before. HOw introducing random offsets would stop the frequency from changing I have no idea. Say you have a clock running at 1 Hz. One tick per second. Naively, you might spread its spectrum by changing the frequency. Let it run at 0.5 Hz some seconds, 1.5 Hz some others. That's two ticks some seconds, two thirds of one others. The average frequency works out to 0.75 Hz. Not what you want. Alternatively, instead of ticking at the top of every second, add a random offset to the time when every tick happens. After an hour, there will have been 3,600 ticks. Still 1 Hz. It sounds like a terrible idea, but that may be ignorance. If you want the best clock possible, it is. But that's not the only consideration. Say you add plus or minus .5 sec at every tick. Yes, after an hour, you will still have 3600 ticks, but when you measure the time at any particular point in the hour, you will never know the time to better than .5 sec. This will set an ultimate limit on the accuracy of your clock. All to save a few cents in copper to shield your system properly. And your system is till polluting the airwaves with the same amount of energy, only spread around slightly in frequency. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Rob nom...@example.com writes: Richard B. Gilbert rgilber...@comcast.net wrote: Unruh wrote: Steve Kostecke koste...@ntp.org writes: On 2009-10-03, Rob nom...@example.com wrote: It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. In my experience with ntpd warm restarts have never been a problem. YMMV It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. There is no policy of denial. There have been extensive discussions on the slow convergence of ntp, and David Mills has been adamant that the current algorithm will not change, and that the slow convergence is a feature that will also not change. It is I agree not a policy of denial. It is a policy of that's not a bug, its a feature. It's a feature! Learn to live with it or write your own NTPD. Dr. Mills is unlikely to change his mind! Chrony and perhaps other products may come closer to meeting your requirements. My statement It seems that the official standpoint is to ignore or deny these problems was meant to point in this direction, but apparently my bad English idiom was again misunderstood. One relatively easy solution is to keep NTPD running 24x7. If you can't or won't do that, NTPD is a poor choice for your requirements! I am talking about problems at startup time. Even when you keep NTPD running 24x7 you have to start it at some time. That is not a smooth operation. But that problem is denied or ignored. No. ntp stores the current drift rate in a file. It also assumes that there is a mechanism to flywheel the time ( a real time clock) so that when it is restarted, it has a good idea of what the time is and what the drift rate is. The problems arise if either of these mechanism do not work. If the system has no on board rtc, then ntp can use the ntpd -g mechanism to rapidly get the right time set. If you have to drift file, it tries to rapidly get an idea of the drift. But if you hava a drift file and for some reason the real drift is different ( eg the Linux calibration problems) then ntp behaves very badly. (it also behaves badly if during the running the drift rate changes eg because the computer heats up due to heavy use). Thus on systems where the drift rate is stable over reboots ( to less than a PPM) ntpd behaves well even over restarts. On systems where that is not true, it behaves badly (ie slowly). If the true drift is out by say 50-100PPM and one has a large poll interval ( eg 6 or higher) it can easily approach or even exceed the 500PPM limit on the drift rate and go a bit crazy, or shut itself down. This is a problem with recent linux kernels where the drift rate can fluctuate by 50-100PPM over reboots. Note that the problem is not denied or ignored. It is stated that ntp needs time to settle down, and you should run ntp continuously. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh writes: Say you add plus or minus .5 sec at every tick. You don't. The modulation is applied to the UHF clock source the machine uses to generate its bus clocks. At these frequencies 10% modulation depth will result in perhaps a few hundred nanoseconds in uncertainty in the pulse position. This uncertainty is not magified as the clock is divided down. Yes, after an hour, you will still have 3600 ticks, but when you measure the time at any particular point in the hour, you will never know the time to better than .5 sec. More like 200 nsec. And your system is till polluting the airwaves with the same amount of energy, only spread around slightly in frequency. So are you by standing there giving off thermal radiation. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
I wrote: More like 200 nsec. No, more like tens of nanoseconds at most. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
John Hasler jhas...@newsguy.com writes: Unruh writes: Say you add plus or minus .5 sec at every tick. You don't. The modulation is applied to the UHF clock source the machine uses to generate its bus clocks. At these frequencies 10% modulation depth will result in perhaps a few hundred nanoseconds in uncertainty in the pulse position. This uncertainty is not magified as the clock is divided down. Yes, after an hour, you will still have 3600 ticks, but when you measure the time at any particular point in the hour, you will never know the time to better than .5 sec. More like 200 nsec. No. Because when you measure the time it is out by the amount that you jitter the time. (I assumed thatt he time jitter was .5 sec) IF you are claiming that the time jitter is 200ns then yes, the time would be out by 200ns And your system is till polluting the airwaves with the same amount of energy, only spread around slightly in frequency. So are you by standing there giving off thermal radiation. IF the amplitude were the same as the thermal amplitude, then I would not care not would the FCC. Unfortunately it is many many many orders of magnitude higher than thermal. It is an unshielded efficient radiator, the motherboard. Unshielded because the manufacturer does not want to spend the money to shield it. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
E-Mail Sent to this address will be added to the BlackLists
n...@blacklist.griffin-technologies.invalid writes:
Unruh wrote:
It is an unshielded efficient radiator, the motherboard.
Unshielded because the manufacturer does not want to spend
the money to shield it.
Do you buy / use equipment that you have decided are the source
of objectionable levels of EMI?
I do not have the equipment to measure the radiation given off. The
manufacturers do. If you tell me how I can get the information as to how
much it emits, I will certainly include that in my decision process.
If you have such equipment, what have you done to decrease
the emissions?
{Don't tell me you are complaining about it, while supporting
the manufacturers you think are behind the problem,
and doing nothing about it yourself.}
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote:
It is an unshielded efficient radiator, the motherboard.
Unshielded because the manufacturer does not want to spend
the money to shield it.
Do you buy / use equipment that you have decided are the source
of objectionable levels of EMI?
If you have such equipment, what have you done to decrease
the emissions?
{Don't tell me you are complaining about it, while supporting
the manufacturers you think are behind the problem,
and doing nothing about it yourself.}
--
E-Mail Sent to this address blackl...@griffin-technologies.net
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Richard B. Gilbert rgilber...@comcast.net wrote: * On a system not locking stopping ntp and restarting having set the drift file to -28, results in the drift going back to -400 over a couple of hours - so not some odd start-up state that confuses the control loop. This suggests that your local clock is defective! Most properly working hardware will generate an absolute value that is less than 100 and many will have an absolute value less than 50. I don't think so. This often happens with ntpd, also on systems with a well working clock. There is some sort of problem with ntpd startup as Unruh also explained. I have seen it many times. It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Rob nom...@example.com wrote in message news:slrnhce5df.10lk.nom...@xs7.xs4all.nl... Richard B. Gilbert rgilber...@comcast.net wrote: * On a system not locking stopping ntp and restarting having set the drift file to -28, results in the drift going back to -400 over a couple of hours - so not some odd start-up state that confuses the control loop. This suggests that your local clock is defective! Most properly working hardware will generate an absolute value that is less than 100 and many will have an absolute value less than 50. I don't think so. This often happens with ntpd, also on systems with a well working clock. There is some sort of problem with ntpd startup as Unruh also explained. I have seen it many times. It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. I have also seen similar problems where NTP will go wild, with the computed frequency error becoming further and further from the expected value. Stopping and restarting NTP will sometimes fix these problems, at other times it may be necessary to delete the drift file and let NTP establish a new value from scratch. Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
David Hawkins david.j.hawk...@btinternet.com writes: They are running Sues Linux from a read only flash drive, all identical clones other than host names and IP addresses. Aren't there stories of recent Linux kernels miscalibrating the kernel timer against the hardware? I guess you could check the dmesg at boot to see what frequency it thinks the timers are running at. David. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Rob wrote: Richard B. Gilbert rgilber...@comcast.net wrote: * On a system not locking stopping ntp and restarting having set the drift file to -28, results in the drift going back to -400 over a couple of hours - so not some odd start-up state that confuses the control loop. This suggests that your local clock is defective! Most properly working hardware will generate an absolute value that is less than 100 and many will have an absolute value less than 50. I don't think so. This often happens with ntpd, also on systems with a well working clock. There is some sort of problem with ntpd startup as Unruh also explained. I have seen it many times. It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. I don't think NTPD was designed to be restarted often. Chrony is said to be a better tool than NTPD if you want fast convergence. I haven't tried it since my systems run for months at a time. They would run for years if we didn't get two or three power outrages a year. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh unruh-s...@physics.ubc.ca wrote in message news:k8yxm.46291$db2.44...@edtnps83... [...] No idea what spread spectrum means for a clock. That there is a certain jitter explicitly introduced in its effective frequency. Probably in the form of a random offset, that averages to zero, to every tick, so you're certain that the long-term frequency doesn't change. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Richard B. Gilbert wrote: Rob wrote: Richard B. Gilbert rgilber...@comcast.net wrote: * On a system not locking stopping ntp and restarting having set the drift file to -28, results in the drift going back to -400 over a couple of hours - so not some odd start-up state that confuses the control loop. This suggests that your local clock is defective! Most properly working hardware will generate an absolute value that is less than 100 and many will have an absolute value less than 50. I don't think so. This often happens with ntpd, also on systems with a well working clock. There is some sort of problem with ntpd startup as Unruh also explained. I have seen it many times. It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. I don't think NTPD was designed to be restarted often. Chrony is said to be a better tool than NTPD if you want fast convergence. I haven't tried it since my systems run for months at a time. They would run for years if we didn't get two or three power outrages a year. I've started replacing ntpd on desktops and notebooks as it's not really appropriate and ntpd -q or ntpdate would be sufficient. It's just that ntpd was installed by default. Using ntpd -q before starting chrony seems to give good results. Of course having an existing good driftfile for either ntpd or chrony will help a lot and if drift is much over 50ppm I don't think ntpd is happy. Using one of methods to manually adjust frequency to a low drift 10ppm was my preferred method but that seems to get fouled up in newer kernels by the self calibration failing to get it right. Back to original problem I'd have drift file saved to non volatile storage otherwise I can't see ntpd being usable if drift happens to be large (or only useful after days with wild swings before possibly converging). David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
On 2009-10-03, Unruh unruh-s...@physics.ubc.ca wrote: David Hawkins david.j.hawk...@btinternet.com writes: * The processor card uses a PCI clock generator capable of spread spectrum output, this is always enabled and not controllable from the BIOS - the chip No idea what spread spectrum means for a clock. http://en.wikipedia.org/wiki/Spread_spectrum#Spread-spectrum_clock_signal_generation -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
On 2009-10-03, Rob nom...@example.com wrote: It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. In my experience with ntpd warm restarts have never been a problem. YMMV It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. There is no policy of denial. If you wish to report this problem please do so via the NTP bug tracking system at http://bugs.ntp.org/. Before submitting your report please do the following: 1. Upgrade to the current ntp stable _or_ dev release 2. Enable _full_ statistics collection and run ntpd until the problem occurs 3. Attach logs which substantiate your issue to your bug report -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Steve Kostecke koste...@ntp.org wrote: On 2009-10-03, Rob nom...@example.com wrote: It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. In my experience with ntpd warm restarts have never been a problem. YMMV I am talking about the problem where after a couple of restarts you observe that the offset between local time and the external servers is actually increasing, not for just a moment but for a long time, before it loses sync and steps back in to the correct time. This has been observed by many users. Not by you, apparently. It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. There is no policy of denial. ... but saying don't see it here, YMMV is not much different from it. If you wish to report this problem please do so via the NTP bug tracking system at http://bugs.ntp.org/. Before submitting your report please do the following: 1. Upgrade to the current ntp stable _or_ dev release 2. Enable _full_ statistics collection and run ntpd until the problem occurs 3. Attach logs which substantiate your issue to your bug report I am just a user. I install a Linux system from a distributor which includes a recent version of ntpd. I try to get it configured correctly, maybe experimenting with some of the features I read about in the documents. Then I run into problems, that often magically go away when waiting long enough for things to settle down. When I need to find out how to get a new version, compile and install it without disturbing the existing environment in the distribution, find out how to enable statistics and logging and THEN need to reproduce the issue (which happens only when experimenting and rebooting), it is easier to just leave things alone and hope it won't break completely. Extended testing and data collection will have to be done by developers or by those that want to spend one or several days on this issue. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Maarten Wiltink maar...@kittensandcats.net writes: Unruh unruh-s...@physics.ubc.ca wrote in message news:k8yxm.46291$db2.44...@edtnps83... [...] No idea what spread spectrum means for a clock. That there is a certain jitter explicitly introduced in its effective frequency. Probably in the form of a random offset, that averages to zero, to every tick, so you're certain that the long-term frequency doesn't change. I am afraid I am left as confused as before. HOw introducing random offsets would stop the frequency from changing I have no idea. It sounds like a terrible idea, but that may be ignorance. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Rob nom...@example.com writes: Richard B. Gilbert rgilber...@comcast.net wrote: * On a system not locking stopping ntp and restarting having set the drift file to -28, results in the drift going back to -400 over a couple of hours - so not some odd start-up state that confuses the control loop. This suggests that your local clock is defective! Most properly working hardware will generate an absolute value that is less than 100 and many will have an absolute value less than 50. I don't think so. This often happens with ntpd, also on systems with a well working clock. There is some sort of problem with ntpd startup as Unruh also explained. I have seen it many times. It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. ntp does NOT try to estimate the drift, which would be trivial to do if it kept some memory of past measurements. It simply looks at the current offset and alters the rate to try to eliminate that offset. But if the drift is wrong, that small change will not help and so it alters the drift more and more. By the time that offset starts to change, the drift is way way out, and it then waits until the offset is also way way out to try to pull things back into line. This takes a long time. ( the time scale for halving the drift offset is of the order of an hour. ) This is a result of the very simple Markovian algorithm that Mills chose for ntp. It is relatively robust, easy to analyse ( at least if things like the drift limits and the clock jumps at .128 sec offset are ignored), but is also very slow to settle down. More sophisticated schemes settle down far faster, but have no necessarily been as well analysed. It is trivial from 2 or 3 offset measurements to make a far better estimate of the drift and offset of the clock than ntp does. ntp gets there eventually. IF you are running Linux or BSD, chrony converges far faster. If you are running windows, it does not run on windows. If you are running hardware clocks, the official release does not support them but patches by Lichvar now do. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Steve Kostecke koste...@ntp.org writes: On 2009-10-03, Unruh unruh-s...@physics.ubc.ca wrote: David Hawkins david.j.hawk...@btinternet.com writes: * The processor card uses a PCI clock generator capable of spread spectrum output, this is always enabled and not controllable from the BIOS - the chip No idea what spread spectrum means for a clock. http://en.wikipedia.org/wiki/Spread_spectrum#Spread-spectrum_clock_signal_generation Ah. Thanks. OK-- it has nothing to do with making the clock better-- it makes it worse. It is just trying to use a loophole in the radiation emission regulations. -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Steve Kostecke koste...@ntp.org writes: On 2009-10-03, Rob nom...@example.com wrote: It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. In my experience with ntpd warm restarts have never been a problem. YMMV It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. There is no policy of denial. There have been extensive discussions on the slow convergence of ntp, and David Mills has been adamant that the current algorithm will not change, and that the slow convergence is a feature that will also not change. It is I agree not a policy of denial. It is a policy of that's not a bug, its a feature. If you wish to report this problem please do so via the NTP bug tracking system at http://bugs.ntp.org/. It has been reported often, and apparently for many years. Before submitting your report please do the following: 1. Upgrade to the current ntp stable _or_ dev release 2. Enable _full_ statistics collection and run ntpd until the problem occurs 3. Attach logs which substantiate your issue to your bug report -- Steve Kostecke koste...@ntp.org NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
David Lord sn...@lordynet.org writes: Richard B. Gilbert wrote: Rob wrote: Richard B. Gilbert rgilber...@comcast.net wrote: * On a system not locking stopping ntp and restarting having set the drift file to -28, results in the drift going back to -400 over a couple of hours - so not some odd start-up state that confuses the control loop. This suggests that your local clock is defective! Most properly working hardware will generate an absolute value that is less than 100 and many will have an absolute value less than 50. I don't think so. This often happens with ntpd, also on systems with a well working clock. There is some sort of problem with ntpd startup as Unruh also explained. I have seen it many times. It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. I don't think NTPD was designed to be restarted often. Chrony is said to be a better tool than NTPD if you want fast convergence. I haven't tried it since my systems run for months at a time. They would run for years if we didn't get two or three power outrages a year. I've started replacing ntpd on desktops and notebooks as it's not really appropriate and ntpd -q or ntpdate would be sufficient. It's just that ntpd was installed by default. Using ntpd -q before starting chrony seems to give good results. Why would that do anything? Chrony itself has an option to step the clock on startup if the offset is too large ( user selectable-- if you want to select .128 sec, that is fine) Of course having an existing good driftfile for either ntpd or chrony will help a lot and if drift is much over 50ppm I don't think ntpd is happy. Using one of methods to manually adjust frequency to a low drift 10ppm was my preferred method but that seems to get fouled up in newer kernels by the self calibration failing to get it right. Back to original problem I'd have drift file saved to non volatile storage otherwise I can't see ntpd being usable if drift happens to be large (or only useful after days with wild swings before possibly converging). This is a real problem with the recent kernel problems on Linux, because the system drift would change by 50PPM on successive restarts of the system. This would take ntp about 10 hours to correct. ( and chrony less than 1 hr) but is certainly a pain. David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh writes: it has nothing to do with making the clock better-- it makes it worse. It is just trying to use a loophole in the radiation emission regulations. It isn't a loophole. While it doesn't reduce the total power radiated it does reduce the interference with radio services which is the goal of the regulations. I also don't see that it would make the clock worse. The random frequency modulation comes from a cycling PRNG and will average out to zero over a fairly short period. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
In article ubmxm.46382$db2.8...@edtnps83, Unruh unruh-s...@physics.ubc.ca writes: Steve If you wish to report this problem please do so via the NTP bug tracking Steve system at http://bugs.ntp.org/. Unruh It has been reported often, and apparently for many years. There have been no bugzilla reports of this. There have been no log/stats snippets that document this. Before submitting your report please do the following: 1. Upgrade to the current ntp stable _or_ dev release 2. Enable _full_ statistics collection and run ntpd until the problem occurs 3. Attach logs which substantiate your issue to your bug report There is something going on for some people, but if developers cannot either duplicate the problem or see the logs to identify the problem, there's really no surprise that no progress is being made. -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
Unruh wrote: Steve Kostecke koste...@ntp.org writes: On 2009-10-03, Rob nom...@example.com wrote: It is worse when you start to twiddle the config and shutdown/restart ntpd often. Then it can take a very long time before it becomes stable again. In my experience with ntpd warm restarts have never been a problem. YMMV It seems that the official standpoint is to ignore or deny these problems, but that doesn't mean they cease to exist. There is no policy of denial. There have been extensive discussions on the slow convergence of ntp, and David Mills has been adamant that the current algorithm will not change, and that the slow convergence is a feature that will also not change. It is I agree not a policy of denial. It is a policy of that's not a bug, its a feature. It's a feature! Learn to live with it or write your own NTPD. Dr. Mills is unlikely to change his mind! Chrony and perhaps other products may come closer to meeting your requirements. One relatively easy solution is to keep NTPD running 24x7. If you can't or won't do that, NTPD is a poor choice for your requirements! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
John, In the implementations I have seen, the spread is generated by a 2-MHz triangular-wave modulation of the frequency control signal in the processor clock phase-lock loop resulting in a spread of about ten percent and reducing the interference potential to narrowband radio services some 20-30 dB. The result can be a significant error if the TSC is used to interpolate the tick. Dave John Hasler wrote: Unruh writes: it has nothing to do with making the clock better-- it makes it worse. It is just trying to use a loophole in the radiation emission regulations. It isn't a loophole. While it doesn't reduce the total power radiated it does reduce the interference with radio services which is the goal of the regulations. I also don't see that it would make the clock worse. The random frequency modulation comes from a cycling PRNG and will average out to zero over a fairly short period. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Strange NTP problem on AMD Geode LX cards.
Hi I'm using a number of XTX form factor AMD Geode LX (500Mhz) cards at work. (Cannot get to news at work, and have left memory stick with details at work ! so apologies for missing info !) They are running Sues Linux from a read only flash drive, all identical clones other than host names and IP addresses. Most of the time ntp runs with no problems and will lock to a local server with less than 5ms offset, and the drift file comes out at between about -20 and -40. But now and again a system will not get a stable lock, and on investigation the drift file is at the maximum of -500. When I first encountered this I assumed it was a hardware problem with the processor card, just a one off, but now have seen this on around 10 systems out of 30 or so I have tested. When a system shows this fault, powering the unit on and off will almost always solve it, the unit synchronising to the server after a couple of hours with a drift file setting of -20 to -40 like the others. I'm more of a hardware engineer than software, but have now run out things to look at to solve this problem. I have considered / done the following * The drift file is stored in the ram drive /dev/shm so always starts at 00.000 when the system is started. * On a system not locking stopping ntp and restarting having set the drift file to -28, results in the drift going back to -400 over a couple of hours - so not some odd start-up state that confuses the control loop. * The processor card uses a PCI clock generator capable of spread spectrum output, this is always enabled and not controllable from the BIOS - the chip has two settings off and on with a -0.5% spread. Have verified with a spectrum analyser that the cards with good lock and bad lock, have the spread spectrum option enabled. * The cards seem to be more lightly to exhibit the problem when they have been turned off for a day or so. * Power saving modes of the processor are enabled, but understand that the timing is done using the counter timer in the Geode companion chip that runs at a constant 14.13MHz regardless of the power state:- also as all running exactly the same code why would some have problems and not others ? Sorry rather random thoughts but I have now run out of things to look at, have you ever seen a problem like this and even better found a solution ? Dave ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Strange NTP problem on AMD Geode LX cards.
David Hawkins david.j.hawk...@btinternet.com writes: Hi I'm using a number of XTX form factor AMD Geode LX (500Mhz) cards at work. (Cannot get to news at work, and have left memory stick with details at work ! so apologies for missing info !) They are running Sues Linux from a read only flash drive, all identical clones other than host names and IP addresses. Most of the time ntp runs with no problems and will lock to a local server with less than 5ms offset, and the drift file comes out at between about -20 and -40. But now and again a system will not get a stable lock, and on investigation the drift file is at the maximum of -500. When I first encountered this I assumed it was a hardware problem with the processor card, just a one off, but now have seen this on around 10 systems out of 30 or so I have tested. When a system shows this fault, powering the unit on and off will almost always solve it, the unit synchronising to the server after a couple of hours with a drift file setting of -20 to -40 like the others. I'm more of a hardware engineer than software, but have now run out things to look at to solve this problem. I have considered / done the following * The drift file is stored in the ram drive /dev/shm so always starts at 00.000 when the system is started. * On a system not locking stopping ntp and restarting having set the drift file to -28, results in the drift going back to -400 over a couple of hours - so not some odd start-up state that confuses the control loop. Yes, it could be. ntpd is very very bad at homing in on a suitable drift. It takes a long time ( many hours) and the drift tends to wander off to very high values. ntpd is terrible at settling down, and is good for systems which are (almost) always on. Now the drift in those machines could be bad, but it could also be a bad response of ntp. How long have you waited to see what it settles down to? If you look at the offsets, what drift do you estimate yourself from those offsets ( esp the first few offsets). * The processor card uses a PCI clock generator capable of spread spectrum output, this is always enabled and not controllable from the BIOS - the chip No idea what spread spectrum means for a clock. has two settings off and on with a -0.5% spread. Have verified with a spectrum analyser that the cards with good lock and bad lock, have the spread spectrum option enabled. * The cards seem to be more lightly to exhibit the problem when they have been turned off for a day or so. * Power saving modes of the processor are enabled, but understand that the timing is done using the counter timer in the Geode companion chip that runs at a constant 14.13MHz regardless of the power state:- also as all running exactly the same code why would some have problems and not others ? Sorry rather random thoughts but I have now run out of things to look at, have you ever seen a problem like this and even better found a solution ? Dave ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
