Re: [ntp:questions] ntpd -q and driftfile
On Thu, Mar 24, 2011 at 1:45 AM, prashant sherin wrote: > Hi All, > Thanks for the discussion and suggestions. > I accept there are disadvantages in syncing the local clock using ntpd > -q. > My only question was whether the drift file will be created/used/ > updated by ntpd when it is used with -q option. The best clue is from the man page: "...With the -q option ntpd operates as in continous mode, but exits just after setting the clock for the first time with the configured servers. ..." The point of having a drift file is just to give ntpd a hint when it starts up so that it can sync faster. So by the above I'd say that ntpd does the same thing on startup with and without the -q option. As for setting the drift file I don't know if that is even meaningful for a short run. Typically you want to run for hours or days to get an accurate drift. By the above quote I'm pretty sure ntpd must use the file but if it sets the file, well you could determine yourself by looking at the file's time stamp to see the last time of modification. If ntpd is not allowed to run long enough to set the drift file then after some time (weeks, months) it will hardly matter if ntp reads the drift file as the data inside will be outdated. -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
Hi All, Thanks for the discussion and suggestions. I accept there are disadvantages in syncing the local clock using ntpd -q. My only question was whether the drift file will be created/used/ updated by ntpd when it is used with -q option. Thanks and Regards, Prashant ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
Chris Albertson wrote: I'd bet any musician could do better than 0.1 sec. If you are playing piano and the timing of a note is off by as much as .1 sec it sounds like an error.MIDI is used to record musical performances and it uses a "tick" about every 10ms or 100 or 128 per second. That is about the range of human hearing, if you are good, delays smaller seem to us a simultaneous. I'd say that people who pratice every day such as pianists could get to the 0.01 second range You're probably right. My cousin Nils who's a very talented musician/composer used to claim that "anyone can learn to sing in tune", but timing was something you had to be born with. (He's got the kind of ear that can listen to a 15-min piece of music once, then sit down and write out the score for all the instruments.) Terje -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On Tue, Mar 22, 2011 at 11:12 PM, unruh wrote: > On 2011-03-23, Hal Murray wrote: > > You can probably do better than that. That is for the reaction to > something that you do not expect. Ie, you have decide that the event has > occured and then send the messages to your finger to press. However for > the timing, you know exactly when it is going to occur. You can get > yourself into a rhythm on each second, and then finally press the > button. So I suspect you can do about .1 sec if you try hard. I'd bet any musician could do better than 0.1 sec. If you are playing piano and the timing of a note is off by as much as .1 sec it sounds like an error.MIDI is used to record musical performances and it uses a "tick" about every 10ms or 100 or 128 per second. That is about the range of human hearing, if you are good, delays smaller seem to us a simultaneous. I'd say that people who pratice every day such as pianists could get to the 0.01 second range -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 2011-03-22, bombjack wrote: > I am fully aware fo how ntpd should be used, i.e. 24/7/365, but that > is not what I am asking for. As I stated above, I need to make sure > the system clock is roughly (your wrist watch would do) the correct > time ASAP during boot as other systems will use this time and can't > easily be changed later if time deviates too much when ntpd (later) > has initial sync. Then you really want to set the clock correctly the first time. > I presume you are aware of that ntpd will take some samples/time > before syncing and that is not good enough. therefore, I still wonder > if ntpd -q could be used in favour of rdate? My tests of 'ntpd -gq' (using 4.2.5*, IIRC) showed that under optimal conditions* initial clock syncronization can be achieved in ~ 11 seconds. * LAN time server, local DNS, "good" value in the drift file, warm restart of ntpd If you just start ntpd with '-g' _and_ use 'iburst' on your server lines _and_ have a "good" value in your drift file you should see initial clock synchronization in ~ 20 seconds. Is that not good enough? -- Steve Kostecke NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 23.3.2011 8:07, Hal Murray wrote: You can probably do better than that. That is for the reaction to something that you do not expect. Ie, you have decide that the event has occured and then send the messages to your finger to press. However for the timing, you know exactly when it is going to occur. You can get yourself into a rhythm on each second, and then finally press the button. So I suspect you can do about .1 sec if you try hard. That would be another good science fair type experiment. How long does it take to respond to a predictible event vs to an unpredictable stimulus. What is the distribution? Musicians in a good orchestra are synchronized within 20ms. On the other hand, reaction time for the event that is expected to occur is called personal equation. The value is usually in the range 0.2 or 0.3 sec. For example, chronographs used by amateurs for timing star eclipse by the Moon allow to measure this value. An experienced observer has stable personal equation when relaxed and focused. Karel Sandler ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
>You can probably do better than that. That is for the reaction to >something that you do not expect. Ie, you have decide that the event has >occured and then send the messages to your finger to press. However for >the timing, you know exactly when it is going to occur. You can get >yourself into a rhythm on each second, and then finally press the >button. So I suspect you can do about .1 sec if you try hard. That would be another good science fair type experiment. How long does it take to respond to a predictible event vs to an unpredictable stimulus. What is the distribution? -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 2011-03-23, Hal Murray wrote: > >>> oh, come off it. Your reaction time is nowhere near what ntp -q would >>> give you. Using ntp -q run once every hour, and assuming say a 20PPM >>> drift for the crystal, his clock would be out by less than a 100 ms due to >>> the >>> drifting, and your reaction time with your watch ( and wyour watch) are >>> nowhere near that accurate. > >>Actually, it is on the borderline of the achievable. You phase lock >>your finger bounces to the second ticks and just go that little further >>on the exact time. It's certainly good to 200ms and possibly good to 100ms. > > That would be a fun project for a science fair. > Build a setup. Collect a lot of data. > How much does it vary? For one person, between people, ... > How close can you get if you are trying to set a clock? > Can you calibrate the person and subtract off a constant? > What if you get multiple samples? > > Many years ago, my boss did that sort of stuff. I think he said that > normal reaction time from light-on to button-press was 250 ms. It's > faster if there is no penalties for false presses. > You can probably do better than that. That is for the reaction to something that you do not expect. Ie, you have decide that the event has occured and then send the messages to your finger to press. However for the timing, you know exactly when it is going to occur. You can get yourself into a rhythm on each second, and then finally press the button. So I suspect you can do about .1 sec if you try hard. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
>> oh, come off it. Your reaction time is nowhere near what ntp -q would >> give you. Using ntp -q run once every hour, and assuming say a 20PPM >> drift for the crystal, his clock would be out by less than a 100 ms due to >> the >> drifting, and your reaction time with your watch ( and wyour watch) are >> nowhere near that accurate. >Actually, it is on the borderline of the achievable. You phase lock >your finger bounces to the second ticks and just go that little further >on the exact time. It's certainly good to 200ms and possibly good to 100ms. That would be a fun project for a science fair. Build a setup. Collect a lot of data. How much does it vary? For one person, between people, ... How close can you get if you are trying to set a clock? Can you calibrate the person and subtract off a constant? What if you get multiple samples? Many years ago, my boss did that sort of stuff. I think he said that normal reaction time from light-on to button-press was 250 ms. It's faster if there is no penalties for false presses. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 3/22/2011 1:22 PM, unruh wrote: On 2011-03-22, David J Taylor wrote: He can do that if he wants to. That was why the -q option was designed into ntpd-- one time setting of the clock time. However it cannot create a drift file. If he wants a drift file then as you say, he must run it continuously. You could look at it that way, Bill, if all he needs is a one-off setting. However, Prashant says he wants to run it periodically, which doesn't really make sense. Rather than a periodic run, he should leave ntpd running continuously, which is what ntpd is designed for. ntpd -q is a replacemtn for ntpdate, which was typically run from cron, and he is doing, and it is an "acceptable" procedure if for example you do not want a daemon running which could have (unknown to you) security issues. It is also a bit unclear how to switch off the server role of ntpd and he may not want others querying his machine. On the other had it comes at a cost of far worse clock discipline and the probability of the computer jumping backwards in time. Prashant, the fact that the server capability is already built-in to ntpd in no way detracts from using ntpd just as a client for your PC to keep the time spot-on. Just leave it running all the time as it uses very little resources. It will then compute the drift information after (IIRC) one hours of running, and it will keep your PC clock correct by adjusting the rate, rather than bang-bang adjustments of the time. One hour? More like 10 hr. ntpd is really bad at recovering from changes, and switchon is a big change. After 1 hr the drift is liable to be way off, as ntpd alters the drift to bring the clock back into line. That depends on how accurate you want your time to be. NTPD should have the right day, hour, and minute within a very few minutes or even seconds. If you want microsecond accuracy you run in a temperature controlled environment and endeavor to keep it running 24 hours a day, seven days a week, 365 days a year! There are people who want fast startup. NTPD does not do fast startups. If you want to turn everything on at 8:30AM and shut it all off again at 5:00PM, NTPD is not good choice!! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
oh, come off it. Your reaction time is nowhere near what ntp -q would give you. Using ntp -q run once every hour, and assuming say a 20PPM drift for the crystal, his clock would be out by less than a 100 ms due to the drifting, and your reaction time with your watch ( and wyour watch) are nowhere near that accurate. Actually, it is on the borderline of the achievable. You phase lock your finger bounces to the second ticks and just go that little further on the exact time. It's certainly good to 200ms and possibly good to 100ms. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
"unruh" wrote in message news:slrniohsae.ksv.un...@wormhole.physics.ubc.ca... [] I have seen the drift out by 400PPM at around the hour mark. ntpd massively overswings to correct any intial error in the clock ( say a few ms) , and then gradually settles back toward the correct drift rate. Thus the drift printed into the file during that transient really has little relation to the true drift rate, and is not very helpful. I have seen the drift become unstable, but not after just starting ntpd, and not recently. Perhaps there was a bug which is now fixed? Now, if the clock is close to the correct time, and the system had a reasonable drift rate in the file before hand, then the drift rate published after an hour may well be pretty close to the right rate. But if the clock was say out by 50ms, then it could get pretty hairy. This problem is caused by ntp having no memory, except for the drift rate and the current time. It thus cannot use the past history of offsets to make a better estimate of what the true drift rate is. The drift rate it has now is a sum of the true drift rate and the drift rate being used to correct the clock offset. While with history, it would be trivial to calculate the true drift rate and disentangle the two ntpd does not do that. (chrony does). Perhaps "if" is the operative word here - I have not seen this to be a problem on my systems within the last year or two, and they aren't rebooted very often. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 3/22/2011 12:07 PM, bombjack wrote: On Mar 22, 4:20 pm, "Richard B. Gilbert" wrote: On 3/22/2011 2:56 AM, prashant sherin wrote: ntpd is intended to for continuous, not periodic running. You are not using it correctly. Cheers, David Thanks for the quick reply. ntpd does allow us to run this way. From the ntpd man page: -q Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option. The idea is to use it as ntp client. Thanks and Regards, Prashant The fact that it's possible to use NTPD that way does NOT mean that it is anywhere close to using NTPD as designed nor is it the best way for most purposes! You could do almost as well by setting the time from from my wrist watch which uses VLF radio to receive time broadcasts. "Normal usage" is to run NTPD 24 hours a day, 365 days a year or 366 on leap years. Hi, First: Thanks for quick response I am fully aware fo how ntpd should be used, i.e. 24/7/365, but that is not what I am asking for. As I stated above, I need to make sure the system clock is roughly (your wrist watch would do) the correct time ASAP during boot as other systems will use this time and can't easily be changed later if time deviates too much when ntpd (later) has initial sync. I presume you are aware of that ntpd will take some samples/time before syncing and that is not good enough. therefore, I still wonder if ntpd -q could be used in favour of rdate? thanks, Fredrik If you are satisfied with hours and minutes; e.g. 4:02PM you can use NTPDATE or NTP -g, (check this against the NPTD documentation, I'm running on memory and may have dropped at bit or two). NTPDATE is "deprecated"; it's no longer maintained or distributed. There are, however, a few thousand or a few million copies either in use or just stored "in case we need it". Many of the people who hang out here are trying to get a whole herd of computers and other devices to agree on a common time that is a reasonable approximation of the *correct* time. This is necessary for things like analyzing log files. Some have legal requirements for time stamping transactions. Some are hobbyists who see it as a technical challenge. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 2011-03-22, Chris Albertson wrote: > On Mon, Mar 21, 2011 at 11:38 PM, prashant sherin wrote: >> Hi, >> I would like to know if ntpd would use the driftfile specified in /etc/ >> ntp.conf file if it is run periodically using crontab with -q option >> as below: > > That is a rather resource intensive way to run NTP. You use fewer > CPU cycles just letting ntpd run in the background. ntpd will decide > all by itself that it can "sleep" once the clock is running well. > The longer ntp has been running the longer these sleep periods tend to > be. It actually does more work when it starts up than after running > for a few hours. Placing it in the cron tab will force NTP to > endlessly go through the hard work of staring up. > > You want a really bad car analogy? To bad you get one anyway > Cars use most of their gas accelerating up to speed after stopping for > a red light. They use the least gas when cruising at steady speed of > 35MPH. Same with NTP by far most of the resources are used in the > fist minute or so. First off Cron has to create a shell process and > that process creates an instances of NTP by loadingit's code from the > disk into RAM, ntp then exchanges messages with other ntp servers at a > relatively fast rate. but after ntpd has been running for a few hours > it has settled into doing almost nothing The amount of work done by ntpd even when it is working hard ( on startup) is completely trivial. This is like worrying about how much the weight of your crisps packet contributes to the reduction in gas milage on your car, while driving a V8 1/2ton truck. The cost of ntpd is completely swamped by all kinds of other inefficiencies in your operating system. (Of course if you are on a bicycle in the tour de France, it may be a legitimate worry). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 2011-03-22, David J Taylor wrote: > > "unruh" wrote in message > news:slrniohmmc.6v5.un...@wormhole.physics.ubc.ca... > [] >> ntpd -q is a replacemtn for ntpdate, which was typically run from cron, >> and he is doing, and it is an "acceptable" procedure if for example you >> do not want a daemon running which could have (unknown to you) security >> issues. It is also a bit unclear how to switch off the server role of >> ntpd and he may not want others querying his machine. On the other had >> it comes at a cost of far worse clock discipline and the probability of >> the computer jumping backwards in time. > > For a one-off invocation, "acceptable", but to use it for repeated > periodic invocations would require further justification, in my view. > >> One hour? More like 10 hr. ntpd is really bad at recovering from >> changes, and switchon is a big change. >> After 1 hr the drift is liable to be way off, as ntpd alters the drift >> to bring the clock back into line. > > In my experience, NTP writes the drift file every hour, not every ten > hours. Even after one hour, the drift value is likely to be of more use > than no drift value at all. I have seen the drift out by 400PPM at around the hour mark. ntpd massively overswings to correct any intial error in the clock ( say a few ms) , and then gradually settles back toward the correct drift rate. Thus the drift printed into the file during that transient really has little relation to the true drift rate, and is not very helpful. Now, if the clock is close to the correct time, and the system had a reasonable drift rate in the file before hand, then the drift rate published after an hour may well be pretty close to the right rate. But if the clock was say out by 50ms, then it could get pretty hairy. This problem is caused by ntp having no memory, except for the drift rate and the current time. It thus cannot use the past history of offsets to make a better estimate of what the true drift rate is. The drift rate it has now is a sum of the true drift rate and the drift rate being used to correct the clock offset. While with history, it would be trivial to calculate the true drift rate and disentangle the two ntpd does not do that. (chrony does). > > Cheers, > David > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
"unruh" wrote in message news:slrniohmmc.6v5.un...@wormhole.physics.ubc.ca... [] ntpd -q is a replacemtn for ntpdate, which was typically run from cron, and he is doing, and it is an "acceptable" procedure if for example you do not want a daemon running which could have (unknown to you) security issues. It is also a bit unclear how to switch off the server role of ntpd and he may not want others querying his machine. On the other had it comes at a cost of far worse clock discipline and the probability of the computer jumping backwards in time. For a one-off invocation, "acceptable", but to use it for repeated periodic invocations would require further justification, in my view. One hour? More like 10 hr. ntpd is really bad at recovering from changes, and switchon is a big change. After 1 hr the drift is liable to be way off, as ntpd alters the drift to bring the clock back into line. In my experience, NTP writes the drift file every hour, not every ten hours. Even after one hour, the drift value is likely to be of more use than no drift value at all. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 2011-03-22, Richard B. Gilbert wrote: > On 3/22/2011 2:56 AM, prashant sherin wrote: >>> ntpd is intended to for continuous, not periodic running. You are not >>> using it correctly. >>> >>> Cheers, >>> David >> >> Thanks for the quick reply. >> ntpd does allow us to run this way. From the ntpd man page: >> >> -q Exit the ntpd just after the first time the clock is set. >> This behavior mimics that of the ntpdate program, which is to be >> retired. The -g and -x options can >> be used with this option. Note: The kernel time >> discipline is disabled with this option. >> >> The idea is to use it as ntp client. >> >> Thanks and Regards, >> Prashant > > The fact that it's possible to use NTPD that way does NOT mean that it > is anywhere close to using NTPD as designed nor is it the best way for > most purposes! You could do almost as well by setting the time from > from my wrist watch which uses VLF radio to receive time broadcasts. oh, come off it. Your reaction time is nowhere near what ntp -q would give you. Using ntp -q run once every hour, and assuming say a 20PPM drift for the crystal, his clock would be out by less than a 100 ms due to the drifting, and your reaction time with your watch ( and wyour watch) are nowhere near that accurate. > > "Normal usage" is to run NTPD 24 hours a day, 365 days a year or 366 on > leap years. Agreed. That is indeed the best, but not the only way to use ntpd. And it is not "wrong" to use it in the other way. It is up to him to decide what he wants running on his machine. However, he should know what his decisions mean and right now he is confused. > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 2011-03-22, bombjack wrote: > On Mar 22, 4:20?pm, "Richard B. Gilbert" > wrote: >> On 3/22/2011 2:56 AM, prashant sherin wrote: >> >> >> >> >> >> >> >> >> >> >> ntpd is intended to for continuous, not periodic running. ?You are not >> >> using it correctly. >> >> >> Cheers, >> >> David >> >> > Thanks for the quick reply. >> > ntpd does allow us to run this way. From the ntpd man page: >> >> > ? -q ? ? ?Exit the ntpd just after the first time the clock is set. >> > This behavior mimics that of the ntpdate program, which is to be >> > retired. The -g and -x ?options ?can >> > ? ? ? ? ? ? ? ? be used with this option. Note: The kernel time >> > discipline is disabled with this option. >> >> > The idea is to use it as ntp client. >> >> > Thanks and Regards, >> > Prashant >> >> The fact that it's possible to use NTPD that way does NOT mean that it >> is anywhere close to using NTPD as designed nor is it the best way for >> most purposes! ?You could do almost as well by setting the time from >> from my wrist watch which uses VLF radio to receive time broadcasts. >> >> "Normal usage" is to run NTPD 24 hours a day, 365 days a year or 366 on >> leap years. > > Hi, > First: Thanks for quick response > > I am fully aware fo how ntpd should be used, i.e. 24/7/365, but that > is not what I am asking for. As I stated above, I need to make sure > the system clock is roughly (your wrist watch would do) the correct > time ASAP during boot as other systems will use this time and can't > easily be changed later if time deviates too much when ntpd (later) > has initial sync. I presume you are aware of that ntpd will take some > samples/time before syncing and that is not good enough. therefore, I > still wonder if ntpd -q could be used in favour of rdate? Yes. It is far better than rdate. IF you want rapid convergence, and you are running linux/bsd, you might have a look at chrony which has far more rapid convergence of the time, can be set up to initially step the clock to the right time (as can I beleive ntp) and disciplines the clock to tighter tolerances than does ntpd. > > thanks, > Fredrik ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 2011-03-22, David J Taylor wrote: >> He can do that if he wants to. That was why the -q option was designed >> into ntpd-- one time setting of the clock time. However it cannot create >> a drift file. If he wants a drift file then as you say, he must run it >> continuously. > > You could look at it that way, Bill, if all he needs is a one-off setting. > However, Prashant says he wants to run it periodically, which doesn't > really make sense. Rather than a periodic run, he should leave ntpd > running continuously, which is what ntpd is designed for. ntpd -q is a replacemtn for ntpdate, which was typically run from cron, and he is doing, and it is an "acceptable" procedure if for example you do not want a daemon running which could have (unknown to you) security issues. It is also a bit unclear how to switch off the server role of ntpd and he may not want others querying his machine. On the other had it comes at a cost of far worse clock discipline and the probability of the computer jumping backwards in time. > > Prashant, the fact that the server capability is already built-in to ntpd > in no way detracts from using ntpd just as a client for your PC to keep > the time spot-on. Just leave it running all the time as it uses very > little resources. It will then compute the drift information after (IIRC) > one hours of running, and it will keep your PC clock correct by adjusting > the rate, rather than bang-bang adjustments of the time. One hour? More like 10 hr. ntpd is really bad at recovering from changes, and switchon is a big change. After 1 hr the drift is liable to be way off, as ntpd alters the drift to bring the clock back into line. > > Cheers, > David > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On Mon, Mar 21, 2011 at 11:38 PM, prashant sherin wrote: > Hi, > I would like to know if ntpd would use the driftfile specified in /etc/ > ntp.conf file if it is run periodically using crontab with -q option > as below: That is a rather resource intensive way to run NTP. You use fewer CPU cycles just letting ntpd run in the background. ntpd will decide all by itself that it can "sleep" once the clock is running well. The longer ntp has been running the longer these sleep periods tend to be. It actually does more work when it starts up than after running for a few hours. Placing it in the cron tab will force NTP to endlessly go through the hard work of staring up. You want a really bad car analogy? To bad you get one anyway Cars use most of their gas accelerating up to speed after stopping for a red light. They use the least gas when cruising at steady speed of 35MPH. Same with NTP by far most of the resources are used in the fist minute or so. First off Cron has to create a shell process and that process creates an instances of NTP by loadingit's code from the disk into RAM, ntp then exchanges messages with other ntp servers at a relatively fast rate. but after ntpd has been running for a few hours it has settled into doing almost nothing -- = Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On Mar 22, 4:20 pm, "Richard B. Gilbert" wrote: > On 3/22/2011 2:56 AM, prashant sherin wrote: > > > > > > > > > > >> ntpd is intended to for continuous, not periodic running. You are not > >> using it correctly. > > >> Cheers, > >> David > > > Thanks for the quick reply. > > ntpd does allow us to run this way. From the ntpd man page: > > > -q Exit the ntpd just after the first time the clock is set. > > This behavior mimics that of the ntpdate program, which is to be > > retired. The -g and -x options can > > be used with this option. Note: The kernel time > > discipline is disabled with this option. > > > The idea is to use it as ntp client. > > > Thanks and Regards, > > Prashant > > The fact that it's possible to use NTPD that way does NOT mean that it > is anywhere close to using NTPD as designed nor is it the best way for > most purposes! You could do almost as well by setting the time from > from my wrist watch which uses VLF radio to receive time broadcasts. > > "Normal usage" is to run NTPD 24 hours a day, 365 days a year or 366 on > leap years. Hi, First: Thanks for quick response I am fully aware fo how ntpd should be used, i.e. 24/7/365, but that is not what I am asking for. As I stated above, I need to make sure the system clock is roughly (your wrist watch would do) the correct time ASAP during boot as other systems will use this time and can't easily be changed later if time deviates too much when ntpd (later) has initial sync. I presume you are aware of that ntpd will take some samples/time before syncing and that is not good enough. therefore, I still wonder if ntpd -q could be used in favour of rdate? thanks, Fredrik ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 3/22/2011 2:56 AM, prashant sherin wrote: ntpd is intended to for continuous, not periodic running. You are not using it correctly. Cheers, David Thanks for the quick reply. ntpd does allow us to run this way. From the ntpd man page: -q Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option. The idea is to use it as ntp client. Thanks and Regards, Prashant The fact that it's possible to use NTPD that way does NOT mean that it is anywhere close to using NTPD as designed nor is it the best way for most purposes! You could do almost as well by setting the time from from my wrist watch which uses VLF radio to receive time broadcasts. "Normal usage" is to run NTPD 24 hours a day, 365 days a year or 366 on leap years. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
Thanks all for the suggestions and explanation. Regards, Prashant ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
He can do that if he wants to. That was why the -q option was designed into ntpd-- one time setting of the clock time. However it cannot create a drift file. If he wants a drift file then as you say, he must run it continuously. You could look at it that way, Bill, if all he needs is a one-off setting. However, Prashant says he wants to run it periodically, which doesn't really make sense. Rather than a periodic run, he should leave ntpd running continuously, which is what ntpd is designed for. Prashant, the fact that the server capability is already built-in to ntpd in no way detracts from using ntpd just as a client for your PC to keep the time spot-on. Just leave it running all the time as it uses very little resources. It will then compute the drift information after (IIRC) one hours of running, and it will keep your PC clock correct by adjusting the rate, rather than bang-bang adjustments of the time. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
prashant sherin wrote: The idea is to use it as ntp client. It would only be an SNTP client, used like this. My understanding is that if I run ntpd in daemon mode, it will also act like an NTP server listening on UDP port 123. I think running ntpd with -q option would prevent the server from running and also it would be a good It will still act as a aerver whilst it is running. Why are you so concerned about people knowing the quality of your system's time? You need to go back a further level in the requirements (although I suspect security paranoia). You can use configuration options to prevent it serving time and to ignore packets from IP addresses other than your official servers. replacement for ntpdate command as stated in the manual page. Neither ntpdate nor ntpd -q create a frequency solution, so a drift file is of no use to them. ntdp -q may read an existing drift file, but I'm not sure if it would save it into the kernel time discipline. You would have to populate the file manually. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 2011-03-22, prashant sherin wrote: >> ntpd is intended to for continuous, not periodic running. ?You are not >> using it correctly. >> >> Cheers, >> David > > Thanks for the quick reply. > ntpd does allow us to run this way. From the ntpd man page: > > -q Exit the ntpd just after the first time the clock is set. > This behavior mimics that of the ntpdate program, which is to be > retired. The -g and -x options can >be used with this option. Note: The kernel time > discipline is disabled with this option. > > The idea is to use it as ntp client. No idea what that is supposed to mean. ntpd run continuously is an ntp client as well. An ntp client is something that uses another time source to control the local clock. You can do that in a one shot fashion as you seem to want to do, or use it continuously so it disciplines the rate as well as the time. It is up to you. However, you may well be very confused about ntpd as well. Your posts do not rule that out. Maybe if you told us what you want to accomplish we can give you advice on how best to accomplish it. > > Thanks and Regards, > Prashant ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 2011-03-22, David J Taylor wrote: >> Hi, >> I would like to know if ntpd would use the driftfile specified in /etc/ >> ntp.conf file if it is run periodically using crontab with -q option >> as below: >> >> /usr/sbin/ntpd -u ntp:ntp -p /var/run/ntpd.pid -g -q -L eth0 >> >> I do not find any drift file being created at the specified location. >> >> Thanks and Regards, >> Prashant > > Prashant, > > ntpd is intended to for continuous, not periodic running. You are not > using it correctly. He can do that if he wants to. That was why the -q option was designed into ntpd-- one time setting of the clock time. However it cannot create a drift file. If he wants a drift file then as you say, he must run it continuously. > > Cheers, > David > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On 2011-03-22, prashant sherin wrote: > Hi, > I would like to know if ntpd would use the driftfile specified in /etc/ > ntp.conf file if it is run periodically using crontab with -q option > as below: > > /usr/sbin/ntpd -u ntp:ntp -p /var/run/ntpd.pid -g -q -L eth0 > > I do not find any drift file being created at the specified location. How can it? All that does is to, like ntpdate, reset the clock to the correct time. It does not run long enough (ie about 10 hrs) to determine the drift rate of the clock. It has no idea what the drift rate is. > > Thanks and Regards, > Prashant ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
On Mar 22, 12:18 pm, unruh wrote: > On 2011-03-22, prashant sherin wrote: > > > > >> ntpd is intended to for continuous, not periodic running. ?You are not > >> using it correctly. > > >> Cheers, > >> David > > > Thanks for the quick reply. > > ntpd does allow us to run this way. From the ntpd man page: > > > -q Exit the ntpd just after the first time the clock is set. > > This behavior mimics that of the ntpdate program, which is to be > > retired. The -g and -x options can > > be used with this option. Note: The kernel time > > discipline is disabled with this option. > > > The idea is to use it as ntp client. > > No idea what that is supposed to mean. ntpd run continuously is an ntp > client as well. An ntp client is something that uses another time source > to control the local clock. You can do that in a one shot fashion as you > seem to want to do, or use it continuously so it disciplines the rate as > well as the time. It is up to you. However, you may well be very > confused about ntpd as well. Your posts do not rule that out. > Maybe if you told us what you want to accomplish we can give you advice > on how best to accomplish it. > > > > > Thanks and Regards, > > Prashant Thanks for the explanation. Yes, I am no expert in ntp. My understanding is that if I run ntpd in daemon mode, it will also act like an NTP server listening on UDP port 123. I think running ntpd with -q option would prevent the server from running and also it would be a good replacement for ntpdate command as stated in the manual page. Regards, prashant ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] ntpd -q and driftfile
Hi, I would like to know if ntpd would use the driftfile specified in /etc/ ntp.conf file if it is run periodically using crontab with -q option as below: /usr/sbin/ntpd -u ntp:ntp -p /var/run/ntpd.pid -g -q -L eth0 I do not find any drift file being created at the specified location. Thanks and Regards, Prashant ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
Hi, I would like to know if ntpd would use the driftfile specified in /etc/ ntp.conf file if it is run periodically using crontab with -q option as below: /usr/sbin/ntpd -u ntp:ntp -p /var/run/ntpd.pid -g -q -L eth0 I do not find any drift file being created at the specified location. Thanks and Regards, Prashant Prashant, ntpd is intended to for continuous, not periodic running. You are not using it correctly. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -q and driftfile
> ntpd is intended to for continuous, not periodic running. You are not > using it correctly. > > Cheers, > David Thanks for the quick reply. ntpd does allow us to run this way. From the ntpd man page: -q Exit the ntpd just after the first time the clock is set. This behavior mimics that of the ntpdate program, which is to be retired. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option. The idea is to use it as ntp client. Thanks and Regards, Prashant ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
