Re: [ntp:questions] Change poll interval at runtime?
"Uwe Klein" wrote in message news:0hfu19-smj@klein-habertwedt.de... [] The IBM-PC Hardware was quite the regression for the time. The 68k and Z80 Systems had "real*" and capable IO integrated circuits. The initial TTL bitbang stuff was really limited. Z8035, Z8530, M68851, M68230, .. uwe Yes, I had a whole box of that range of ICs - CPU, I/O etc. - but threw it out the other day as "no longer likely to be useful". What's been very helpful about the way that the IBM PC architecture and the operating system support through Windows has evolved. Given the right privilege, software which pokes the old I/O port numbers still works! I don't think that a very high price has been paid for that backward compatibility, either. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
David J Taylor wrote: "A C" wrote in message news:4f4c0508.2010...@acarver.net... [] Zilog was completely standard on sun4c and sun4m so it's neither case of non-standard nor faulty hardware. It's just different (but standard for the architecture). It also hasn't been fully worked through likely because the much more recent Sun hardware had shifted to other hardware components in an effort to reduce costs. Eventually, of course, Sun switched architectures entirely and the latest Sun hardware has an Intel based design rather than the orignal Sun RISC processor designs. OK, so non-standard architecture (for today), then! The IBM-PC Hardware was quite the regression for the time. The 68k and Z80 Systems had "real*" and capable IO integrated circuits. The initial TTL bitbang stuff was really limited. Z8035, Z8530, M68851, M68230, .. uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
"A C" wrote in message news:4f4c0508.2010...@acarver.net... [] Zilog was completely standard on sun4c and sun4m so it's neither case of non-standard nor faulty hardware. It's just different (but standard for the architecture). It also hasn't been fully worked through likely because the much more recent Sun hardware had shifted to other hardware components in an effort to reduce costs. Eventually, of course, Sun switched architectures entirely and the latest Sun hardware has an Intel based design rather than the orignal Sun RISC processor designs. OK, so non-standard architecture (for today), then!Still a pity that no-one has fixed the drivers Unless someone has a copy on CD laying around the earlier versions I can't get one from Oracle anymore. Let's hope someone does. I have grander plans for the GPS besides timekeeping so I want to have it running in SiRF mode which requires gpsd to translate the data and send it over to ntpd for time. But as long as PPS+Internet work then it's good enough for timing. One Internet server is set to prefer already so it does pick up on PPS after the servers have been polled a few times. They are just forever stuck at 64 second intervals. I expect you have the Internet servers set to iburst as well? It looks like you've done all you can. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/26/2012 23:38, David J Taylor wrote: "A C" wrote in message news:4f4b221a.6020...@acarver.net... [] Sun sparc (Zilog serial ports), not Intel/AMD. FreeBSD has different serial drivers for different architectures. The hardware I have is not faulty. Under Solaris it all works (but I don't have a copy of Solaris 7 around to support sun4c architecture). NetBSD supports sun4c and can see DCD just fine but it's unable to share half of the port (TX/RX) with one process while sharing the other half (DCD, RTS, CTS) with another process (this is what makes its serial port support broken). FreeBSD's sparc serial driver is unable to read the control lines so it's very broken. So non-standard hardware rather than faulty hardware. BTW: I thought that one of the benefits of open-course operating systems was that you could fix such problems yourself! A pity no-one has fixed the driver. I had also thought that Solaris was now free to download by anyone, and use for non-production use, but perhaps I'm wrong? Zilog was completely standard on sun4c and sun4m so it's neither case of non-standard nor faulty hardware. It's just different (but standard for the architecture). It also hasn't been fully worked through likely because the much more recent Sun hardware had shifted to other hardware components in an effort to reduce costs. Eventually, of course, Sun switched architectures entirely and the latest Sun hardware has an Intel based design rather than the orignal Sun RISC processor designs. http://www.oracle.com/technetwork/server-storage/solaris11/downloads/index.html I don't know about earlier versions Unless someone has a copy on CD laying around the earlier versions I can't get one from Oracle anymore. The sharing of a serial port is critical for ntpd to do PPS on the NMEA refclock. On Solaris 7 this would probably work fine. On NetBSD, ATOM or NMEA without PPS work but NMEA with PPS does not. On FreeBSD, forget PPS entirely. This is why my GPS data is coming in on serial port A and my PPS signal is coming in on serial port B. I have to split them up to see both on NetBSD which means I need two refclocks, one PPS and one NMEA (or SHM for when I have gpsd manage the GPS in SiRF mode). The GPS/PPS devices I have either require no management (the Sure board), or need just a one-time setup under Windows for the Garmin GPS 18/x LVC. There's no need for any routine interaction. My own tests with serial GPS/NMEA data alone support the view that it's no better than just using Internet servers, so Internet + PPS may be your best solution, and not worry too much if the Internet servers never ramp up to 1024s poll. You didn't say whether one of the Internet servers was marked "prefer". I have grander plans for the GPS besides timekeeping so I want to have it running in SiRF mode which requires gpsd to translate the data and send it over to ntpd for time. But as long as PPS+Internet work then it's good enough for timing. One Internet server is set to prefer already so it does pick up on PPS after the servers have been polled a few times. They are just forever stuck at 64 second intervals. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
"A C" wrote in message news:4f4b221a.6020...@acarver.net... [] Sun sparc (Zilog serial ports), not Intel/AMD. FreeBSD has different serial drivers for different architectures. The hardware I have is not faulty. Under Solaris it all works (but I don't have a copy of Solaris 7 around to support sun4c architecture). NetBSD supports sun4c and can see DCD just fine but it's unable to share half of the port (TX/RX) with one process while sharing the other half (DCD, RTS, CTS) with another process (this is what makes its serial port support broken). FreeBSD's sparc serial driver is unable to read the control lines so it's very broken. So non-standard hardware rather than faulty hardware. BTW: I thought that one of the benefits of open-course operating systems was that you could fix such problems yourself! A pity no-one has fixed the driver. I had also thought that Solaris was now free to download by anyone, and use for non-production use, but perhaps I'm wrong? http://www.oracle.com/technetwork/server-storage/solaris11/downloads/index.html I don't know about earlier versions The sharing of a serial port is critical for ntpd to do PPS on the NMEA refclock. On Solaris 7 this would probably work fine. On NetBSD, ATOM or NMEA without PPS work but NMEA with PPS does not. On FreeBSD, forget PPS entirely. This is why my GPS data is coming in on serial port A and my PPS signal is coming in on serial port B. I have to split them up to see both on NetBSD which means I need two refclocks, one PPS and one NMEA (or SHM for when I have gpsd manage the GPS in SiRF mode). The GPS/PPS devices I have either require no management (the Sure board), or need just a one-time setup under Windows for the Garmin GPS 18/x LVC. There's no need for any routine interaction. My own tests with serial GPS/NMEA data alone support the view that it's no better than just using Internet servers, so Internet + PPS may be your best solution, and not worry too much if the Internet servers never ramp up to 1024s poll. You didn't say whether one of the Internet servers was marked "prefer". Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/26/2012 22:02, David J Taylor wrote: "A C" wrote in message news:4f4a8863.2010...@acarver.net... [] FreeBSD's serial drivers are also very broken (in fact, even more broken than NetBSD because FreeBSD can't even see the DCD line). This sounds like you have faulty hardware. There has been no problem with FreeBSD drivers on the two different PCs I've tried - other than determining what name has been given to the serial port Sun sparc (Zilog serial ports), not Intel/AMD. FreeBSD has different serial drivers for different architectures. The hardware I have is not faulty. Under Solaris it all works (but I don't have a copy of Solaris 7 around to support sun4c architecture). NetBSD supports sun4c and can see DCD just fine but it's unable to share half of the port (TX/RX) with one process while sharing the other half (DCD, RTS, CTS) with another process (this is what makes its serial port support broken). FreeBSD's sparc serial driver is unable to read the control lines so it's very broken. The sharing of a serial port is critical for ntpd to do PPS on the NMEA refclock. On Solaris 7 this would probably work fine. On NetBSD, ATOM or NMEA without PPS work but NMEA with PPS does not. On FreeBSD, forget PPS entirely. This is why my GPS data is coming in on serial port A and my PPS signal is coming in on serial port B. I have to split them up to see both on NetBSD which means I need two refclocks, one PPS and one NMEA (or SHM for when I have gpsd manage the GPS in SiRF mode). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
"A C" wrote in message news:4f4a8863.2010...@acarver.net... [] FreeBSD's serial drivers are also very broken (in fact, even more broken than NetBSD because FreeBSD can't even see the DCD line). This sounds like you have faulty hardware. There has been no problem with FreeBSD drivers on the two different PCs I've tried - other than determining what name has been given to the serial port Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
"Richard B. Gilbert" wrote in message news:s9-dnzgbns0_jtfsnz2dnuvz_uwdn...@giganews.com... [] If you really want good time and can afford a GPS *timing* receiver that's the way to do it. The last I heard, you could get a timing receiver for $100 -- $300. Time for an update - as Bill says, US $35: http://www.satsignal.eu/ntp/Sure-GPS.htm and that includes the antenna. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2012-02-27, Richard B. Gilbert wrote: > On 2/26/2012 6:20 PM, unruh wrote: >> On 2012-02-26, Richard B. Gilbert wrote: >>> On 2/26/2012 12:55 AM, Ron Frazier (NTP) wrote: On 2/25/2012 5:05 PM, A C wrote: > On 2/25/2012 13:09, Richard B. Gilbert wrote: >> On 2/25/2012 1:20 AM, A C wrote: >>> On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar&associd hpoll=N" or is it ppoll? >>> >>> Actually, I should have been more specific and say change the minimum >>> polling interval. In other words, be able to adjust the conf file's >>> minpoll flag at runtime instead of restarting. >> >> What problem are you trying to solve? >> >> NTPD does a pretty good job of adjusting itself most of the time. >> >> Short poll intervals are useful when correcting large errors. >> Long poll intervals allow NTPD to make small corrections very >> accurately. > > The idea was to bump up the minimum poll interval after ntpd has been > running for a day or so to something more kind to the remote servers > because the refclock is holding the remote servers clamped to 64 > seconds. If I set minpoll in the config file, then ntpd's start up > takes a long time because of a long poll interval. If I don't set the > minpoll, then ntpd doesn't do "a pretty good job" because it clamps > the polling interval. > I've noticed the same thing. You could try what I'm doing, although I'm still testing for the best configuration. # GPS Lines server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 fudge 127.127.20.5 time2 0.3100 refid GPS1 # Internet server lines # NIST New York server nist1-ny.ustiming.org minpoll 8 maxpoll 13 # other internet server lines similar Sincerely, Ron >>> NTPD adjusts the poll interval dynamically. Just because MINPOLL=4 does >>> not mean that the poll interval is "stuck" there. Give NTPD a >>> rock solid 1 second per second source it will ramp up the poll interval >>> to 1024 seconds. Those "rock solid" ticks can frequently be found >>> 1:00AM to 5:00AM local time. The net quiets down and NTPD takes >>> shameless advantage. >>> >>> If you really want good time and can afford a GPS *timing* receiver >>> that's the way to do it. The last I heard, you could get a timing >>> receiver for $100 -- $300. >> >> Try $35. The Sure gps is a "timing receiver" in that it has a PPS pulse >> with a 20ns or so rise time, and probably comparable accuracy. >> If you want a receiver which a) does a location survey and then uses >> that location to derive the time even from a single sattelite, b) tells >> you what the sawtooth correction is >> (which may be what you think of as a timing receiver) then that is in >> the range you mention. Mind you if you are feeding a computer, you >> cannot actually get that ns level time accuracy into your system, since >> interrupts take 1-10us to be processed. >> >> >>> >>> ANY GPS receiver knows what time it is but the navigation receivers >>> give priority to location. Timing receivers give priority to delivering >>> the correct time. >>> >> Unfortunately most gps may know what the time is but they keep it >> secret. You need to look for a PPS output to get the time out from the >> receiver. >> > > ALL GPS receivers know both the time and the latitude and longitude. > The navigation receivers are optimized for use as navigation device > while the timing receivers are optimized to deliver time. > > Typically, a timing receiver has a pulse per second output, one edge of > which is accurate to within about 50 nanoseconds. In order to get this > accuracy, it is necessary to do a "site survey" which establishes But a "site survey" is what "latitude and longitude" is. Most gps with PPS output do not do a long "site survey" to determine their position. They get the position and time from the four or more sattelites they are tracking. Some do a long term averaging of the position to get rid of random errors. This makes perhaps at most a 30ns difference in the time accuracy of the PPS. They will also remember that position, so that they can use only a single sattelite to get the time, instead of needing 4 of them. But again, those are rarer than those that simply send out the time via the PPS based on the current measurements for 4 sattelites. They will also report what the error in the PPS was due to the "sawtooth" correction (difference between true time and nearest "local oscillator crossing zero" time at which the PPS was sent out. > the position of your GPS receiver's antenna. Once you know the position > of your antenna you can calculate the time. This is "overkill" for most > people. If you need something to happen
Re: [ntp:questions] Change poll interval at runtime?
On 2/26/2012 6:20 PM, unruh wrote: On 2012-02-26, Richard B. Gilbert wrote: On 2/26/2012 12:55 AM, Ron Frazier (NTP) wrote: On 2/25/2012 5:05 PM, A C wrote: On 2/25/2012 13:09, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar&associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. The idea was to bump up the minimum poll interval after ntpd has been running for a day or so to something more kind to the remote servers because the refclock is holding the remote servers clamped to 64 seconds. If I set minpoll in the config file, then ntpd's start up takes a long time because of a long poll interval. If I don't set the minpoll, then ntpd doesn't do "a pretty good job" because it clamps the polling interval. I've noticed the same thing. You could try what I'm doing, although I'm still testing for the best configuration. # GPS Lines server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 fudge 127.127.20.5 time2 0.3100 refid GPS1 # Internet server lines # NIST New York server nist1-ny.ustiming.org minpoll 8 maxpoll 13 # other internet server lines similar Sincerely, Ron NTPD adjusts the poll interval dynamically. Just because MINPOLL=4 does not mean that the poll interval is "stuck" there. Give NTPD a rock solid 1 second per second source it will ramp up the poll interval to 1024 seconds. Those "rock solid" ticks can frequently be found 1:00AM to 5:00AM local time. The net quiets down and NTPD takes shameless advantage. If you really want good time and can afford a GPS *timing* receiver that's the way to do it. The last I heard, you could get a timing receiver for $100 -- $300. Try $35. The Sure gps is a "timing receiver" in that it has a PPS pulse with a 20ns or so rise time, and probably comparable accuracy. If you want a receiver which a) does a location survey and then uses that location to derive the time even from a single sattelite, b) tells you what the sawtooth correction is (which may be what you think of as a timing receiver) then that is in the range you mention. Mind you if you are feeding a computer, you cannot actually get that ns level time accuracy into your system, since interrupts take 1-10us to be processed. ANY GPS receiver knows what time it is but the navigation receivers give priority to location. Timing receivers give priority to delivering the correct time. Unfortunately most gps may know what the time is but they keep it secret. You need to look for a PPS output to get the time out from the receiver. There are two types of GPS receiver, timing and navigation. The difference is that the navigation receiver is optimized to calculate and report latitude, longitude, and elevation with the time being an afterthought. The timing receiver is designed to report the date-time and the location is available as an afterthought! The position of the receiver is determined by a "site survey". Once the location is known with the desired accuracy, the time at the site can be easily determined. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/26/2012 6:20 PM, unruh wrote: On 2012-02-26, Richard B. Gilbert wrote: On 2/26/2012 12:55 AM, Ron Frazier (NTP) wrote: On 2/25/2012 5:05 PM, A C wrote: On 2/25/2012 13:09, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar&associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. The idea was to bump up the minimum poll interval after ntpd has been running for a day or so to something more kind to the remote servers because the refclock is holding the remote servers clamped to 64 seconds. If I set minpoll in the config file, then ntpd's start up takes a long time because of a long poll interval. If I don't set the minpoll, then ntpd doesn't do "a pretty good job" because it clamps the polling interval. I've noticed the same thing. You could try what I'm doing, although I'm still testing for the best configuration. # GPS Lines server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 fudge 127.127.20.5 time2 0.3100 refid GPS1 # Internet server lines # NIST New York server nist1-ny.ustiming.org minpoll 8 maxpoll 13 # other internet server lines similar Sincerely, Ron NTPD adjusts the poll interval dynamically. Just because MINPOLL=4 does not mean that the poll interval is "stuck" there. Give NTPD a rock solid 1 second per second source it will ramp up the poll interval to 1024 seconds. Those "rock solid" ticks can frequently be found 1:00AM to 5:00AM local time. The net quiets down and NTPD takes shameless advantage. If you really want good time and can afford a GPS *timing* receiver that's the way to do it. The last I heard, you could get a timing receiver for $100 -- $300. Try $35. The Sure gps is a "timing receiver" in that it has a PPS pulse with a 20ns or so rise time, and probably comparable accuracy. If you want a receiver which a) does a location survey and then uses that location to derive the time even from a single sattelite, b) tells you what the sawtooth correction is (which may be what you think of as a timing receiver) then that is in the range you mention. Mind you if you are feeding a computer, you cannot actually get that ns level time accuracy into your system, since interrupts take 1-10us to be processed. ANY GPS receiver knows what time it is but the navigation receivers give priority to location. Timing receivers give priority to delivering the correct time. Unfortunately most gps may know what the time is but they keep it secret. You need to look for a PPS output to get the time out from the receiver. ALL GPS receivers know both the time and the latitude and longitude. The navigation receivers are optimized for use as navigation device while the timing receivers are optimized to deliver time. Typically, a timing receiver has a pulse per second output, one edge of which is accurate to within about 50 nanoseconds. In order to get this accuracy, it is necessary to do a "site survey" which establishes the position of your GPS receiver's antenna. Once you know the position of your antenna you can calculate the time. This is "overkill" for most people. If you need something to happen simultaneously in New York City, and in Los Angeles, GPS timing can get you to within ~50 ns. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2012-02-26, A C wrote: > On 2/26/2012 15:09, Richard B. Gilbert wrote: >> On 2/26/2012 12:55 AM, Ron Frazier (NTP) wrote: >>> On 2/25/2012 5:05 PM, A C wrote: On 2/25/2012 13:09, Richard B. Gilbert wrote: > On 2/25/2012 1:20 AM, A C wrote: >> On 2/24/2012 21:26, A C wrote: >>> Is it possible to change the polling interval of one or more >>> associated >>> servers at runtime? It seems like I should be able to run: >>> >>> ntpq -c "writevar &associd hpoll=N" or is it ppoll? >>> >> >> Actually, I should have been more specific and say change the minimum >> polling interval. In other words, be able to adjust the conf file's >> minpoll flag at runtime instead of restarting. > > What problem are you trying to solve? > > NTPD does a pretty good job of adjusting itself most of the time. > > Short poll intervals are useful when correcting large errors. > Long poll intervals allow NTPD to make small corrections very > accurately. The idea was to bump up the minimum poll interval after ntpd has been running for a day or so to something more kind to the remote servers because the refclock is holding the remote servers clamped to 64 seconds. If I set minpoll in the config file, then ntpd's start up takes a long time because of a long poll interval. If I don't set the minpoll, then ntpd doesn't do "a pretty good job" because it clamps the polling interval. >>> >>> I've noticed the same thing. You could try what I'm doing, although I'm >>> still testing for the best configuration. >>> >>> # GPS Lines >>> server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 >>> fudge 127.127.20.5 time2 0.3100 refid GPS1 >>> >>> # Internet server lines >>> # NIST New York >>> server nist1-ny.ustiming.org minpoll 8 maxpoll 13 >>> >>> # other internet server lines similar >>> >>> Sincerely, >>> >>> Ron >>> >>> >> NTPD adjusts the poll interval dynamically. Just because MINPOLL=4 does >> not mean that the poll interval is "stuck" there. Give NTPD a >> rock solid 1 second per second source it will ramp up the poll interval >> to 1024 seconds. Those "rock solid" ticks can frequently be found >> 1:00AM to 5:00AM local time. The net quiets down and NTPD takes >> shameless advantage. >> >> If you really want good time and can afford a GPS *timing* receiver >> that's the way to do it. The last I heard, you could get a timing >> receiver for $100 -- $300. >> >> ANY GPS receiver knows what time it is but the navigation receivers >> give priority to location. Timing receivers give priority to delivering >> the correct time. >> > > I have a timing receiver. But after days of operation on a machine that > does nothing but ntpd none of the Internet servers move up past 64 > seconds and the PPS stays put at whatever minpoll is even though I have > no maxpoll. The PPS is supposed to stay at 16 seconds poll interval. It is not supposed to move up in poll interval. Why your others are not moving up I do not know. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2012-02-26, Richard B. Gilbert wrote: > On 2/26/2012 12:55 AM, Ron Frazier (NTP) wrote: >> On 2/25/2012 5:05 PM, A C wrote: >>> On 2/25/2012 13:09, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: > On 2/24/2012 21:26, A C wrote: >> Is it possible to change the polling interval of one or more >> associated >> servers at runtime? It seems like I should be able to run: >> >> ntpq -c "writevar &associd hpoll=N" or is it ppoll? >> > > Actually, I should have been more specific and say change the minimum > polling interval. In other words, be able to adjust the conf file's > minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. >>> >>> The idea was to bump up the minimum poll interval after ntpd has been >>> running for a day or so to something more kind to the remote servers >>> because the refclock is holding the remote servers clamped to 64 >>> seconds. If I set minpoll in the config file, then ntpd's start up >>> takes a long time because of a long poll interval. If I don't set the >>> minpoll, then ntpd doesn't do "a pretty good job" because it clamps >>> the polling interval. >>> >> >> I've noticed the same thing. You could try what I'm doing, although I'm >> still testing for the best configuration. >> >> # GPS Lines >> server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 >> fudge 127.127.20.5 time2 0.3100 refid GPS1 >> >> # Internet server lines >> # NIST New York >> server nist1-ny.ustiming.org minpoll 8 maxpoll 13 >> >> # other internet server lines similar >> >> Sincerely, >> >> Ron >> >> > NTPD adjusts the poll interval dynamically. Just because MINPOLL=4 does > not mean that the poll interval is "stuck" there. Give NTPD a > rock solid 1 second per second source it will ramp up the poll interval > to 1024 seconds. Those "rock solid" ticks can frequently be found > 1:00AM to 5:00AM local time. The net quiets down and NTPD takes > shameless advantage. > > If you really want good time and can afford a GPS *timing* receiver > that's the way to do it. The last I heard, you could get a timing > receiver for $100 -- $300. Try $35. The Sure gps is a "timing receiver" in that it has a PPS pulse with a 20ns or so rise time, and probably comparable accuracy. If you want a receiver which a) does a location survey and then uses that location to derive the time even from a single sattelite, b) tells you what the sawtooth correction is (which may be what you think of as a timing receiver) then that is in the range you mention. Mind you if you are feeding a computer, you cannot actually get that ns level time accuracy into your system, since interrupts take 1-10us to be processed. > > ANY GPS receiver knows what time it is but the navigation receivers > give priority to location. Timing receivers give priority to delivering > the correct time. > Unfortunately most gps may know what the time is but they keep it secret. You need to look for a PPS output to get the time out from the receiver. > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/26/2012 15:09, Richard B. Gilbert wrote: On 2/26/2012 12:55 AM, Ron Frazier (NTP) wrote: On 2/25/2012 5:05 PM, A C wrote: On 2/25/2012 13:09, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar &associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. The idea was to bump up the minimum poll interval after ntpd has been running for a day or so to something more kind to the remote servers because the refclock is holding the remote servers clamped to 64 seconds. If I set minpoll in the config file, then ntpd's start up takes a long time because of a long poll interval. If I don't set the minpoll, then ntpd doesn't do "a pretty good job" because it clamps the polling interval. I've noticed the same thing. You could try what I'm doing, although I'm still testing for the best configuration. # GPS Lines server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 fudge 127.127.20.5 time2 0.3100 refid GPS1 # Internet server lines # NIST New York server nist1-ny.ustiming.org minpoll 8 maxpoll 13 # other internet server lines similar Sincerely, Ron NTPD adjusts the poll interval dynamically. Just because MINPOLL=4 does not mean that the poll interval is "stuck" there. Give NTPD a rock solid 1 second per second source it will ramp up the poll interval to 1024 seconds. Those "rock solid" ticks can frequently be found 1:00AM to 5:00AM local time. The net quiets down and NTPD takes shameless advantage. If you really want good time and can afford a GPS *timing* receiver that's the way to do it. The last I heard, you could get a timing receiver for $100 -- $300. ANY GPS receiver knows what time it is but the navigation receivers give priority to location. Timing receivers give priority to delivering the correct time. I have a timing receiver. But after days of operation on a machine that does nothing but ntpd none of the Internet servers move up past 64 seconds and the PPS stays put at whatever minpoll is even though I have no maxpoll. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/26/2012 12:55 AM, Ron Frazier (NTP) wrote: On 2/25/2012 5:05 PM, A C wrote: On 2/25/2012 13:09, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar &associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. The idea was to bump up the minimum poll interval after ntpd has been running for a day or so to something more kind to the remote servers because the refclock is holding the remote servers clamped to 64 seconds. If I set minpoll in the config file, then ntpd's start up takes a long time because of a long poll interval. If I don't set the minpoll, then ntpd doesn't do "a pretty good job" because it clamps the polling interval. I've noticed the same thing. You could try what I'm doing, although I'm still testing for the best configuration. # GPS Lines server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 fudge 127.127.20.5 time2 0.3100 refid GPS1 # Internet server lines # NIST New York server nist1-ny.ustiming.org minpoll 8 maxpoll 13 # other internet server lines similar Sincerely, Ron NTPD adjusts the poll interval dynamically. Just because MINPOLL=4 does not mean that the poll interval is "stuck" there. Give NTPD a rock solid 1 second per second source it will ramp up the poll interval to 1024 seconds. Those "rock solid" ticks can frequently be found 1:00AM to 5:00AM local time. The net quiets down and NTPD takes shameless advantage. If you really want good time and can afford a GPS *timing* receiver that's the way to do it. The last I heard, you could get a timing receiver for $100 -- $300. ANY GPS receiver knows what time it is but the navigation receivers give priority to location. Timing receivers give priority to delivering the correct time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/26/2012 2:30 PM, A C wrote: On 2/26/2012 10:20, David J Taylor wrote: "A C" wrote in message news:4f4a6e79.3010...@acarver.net... [] It's the latest dev version on NetBSD using five network servers plus the SHM refclock plus the ATOM refclock. The SHM is not very stable with its offset so I don't use it right now which leaves me ATOM plus network (one of the network servers is marked prefer). (Don't ask about using NMEA with PPS enabled, it doesn't work due to the serial drivers on NetBSD/sparc so PPS has to be separate via a second serial port). If I set minpoll to 8 or 9 to be nice to the network servers, it takes six or eight polling periods before ATOM turns on and becomes the system peer. If I leave out minpoll, ATOM clamps the polling period to 64 seconds. It still takes six to eight polling periods to activate ATOM but 8 * 64 is much less than 8 * 256 or 8 * 512. Thanks for that summary, there are so many systems being discussed that it's easy to lose touch! Leaving aside the question of when the ATOM driver becomes selected, isn't the time accurate enough for your purposes simply by using the five networks servers within a minute or two? I take it that you have "iburst" against all the servers, and that you have one of them marked "prefer"? Can you accept a reduced accuracy until the ATOM kicks in? I've done it before so it's entirely possible to let it go for the total cycle time until ATOM is selected, it just means that the system then takes a while to slew into position after it has been on the Internet servers for a while. I was just hoping to have the best of both, faster convergence and then a kinder polling period afterwards. In the discussions I had with Dave Mills here some time back, I recall that it was a requirement that is the ref clock was at 16s intervals, the Internet servers shouldn't be at 1024s, although that does seem to work correctly here. I have at the back of my mind a feeling that it's tied in with the NMEA not working, i.e. the ATOM driver is somehow working on its own (as an edge of second reference) without a "time of day" source being polled at a similar interval. Anyway, all I can suggest is trying FreeBSD and seeing whether its serial drivers will work for you. I don't feel I can help further. FreeBSD's serial drivers are also very broken (in fact, even more broken than NetBSD because FreeBSD can't even see the DCD line). I'll just experiment with the keys and ntpq commands that Dave Hart suggested. That will probably get me what I'm looking for though I may have to stagger the drops and re-adds if it is truly a drop and re-add rather than just updating the parameters. I just had a thought that I wanted to share. Now, I know just enough about Linux to be really dangerous, and nothing about any form of BSD. So, people who do know about such things may laugh at this idea. But, what if you could do this: Write your own special script to start up NTPD. Have two versions of ntp.conf, say, ntp.conf-fast and ntp.conf-slow. When the script starts, first copy ntp.conf-fast over to /etc/ntp.conf (or wherever it lives). Then, the script starts NTPD. Then the script goes to sleep. During this time, NTPD will be running with a version of ntp.conf which sets polling intervals very fast to get quick convergence. After NTPD has been running, and the script has been sleeping for, say, 10 minutes, let's suppose that the PC clock is very close to the GPS time or a preferred internet server. (I realize the term "very close" can be interpreted different ways.) Say it's within 10 ms. After 10 minutes, the script wakes up again. It shuts down NTPD. Then, it copies ntp.conf-slow over to /etc/ntp.conf. Then, it restarts NTPD. Now the script terminates, but NPTD keeps running. Now, however, NTPD is running with an ntp.conf file that has longer polling intervals that you want after the system is stable. When NTPD is restarted, it SHOULD maintain the close alignment of the PC clock to the preferred source, I think. It should pick up running about where it left off, and then fine tune the synchronization over the next few hours, perhaps. That way, you could have your cake and eat it too. Short polling intervals at first, then longer ones. If, HOWEVER, you encounter the phenomenon (bug?) I've experienced in Linux, you clock will jump to a large offset when NTPD starts up, and that will foil the plan. My approach of polling the GPS at very short minimum intervals and the internet servers at longer minimum intervals seems to be working OK. As long as my GPS time is normally not too far out from what the internet servers are reporting, it should still fail over to the internet if the GPS becomes unreliable. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new me
Re: [ntp:questions] Change poll interval at runtime?
On 2/26/2012 10:20, David J Taylor wrote: "A C" wrote in message news:4f4a6e79.3010...@acarver.net... [] It's the latest dev version on NetBSD using five network servers plus the SHM refclock plus the ATOM refclock. The SHM is not very stable with its offset so I don't use it right now which leaves me ATOM plus network (one of the network servers is marked prefer). (Don't ask about using NMEA with PPS enabled, it doesn't work due to the serial drivers on NetBSD/sparc so PPS has to be separate via a second serial port). If I set minpoll to 8 or 9 to be nice to the network servers, it takes six or eight polling periods before ATOM turns on and becomes the system peer. If I leave out minpoll, ATOM clamps the polling period to 64 seconds. It still takes six to eight polling periods to activate ATOM but 8 * 64 is much less than 8 * 256 or 8 * 512. Thanks for that summary, there are so many systems being discussed that it's easy to lose touch! Leaving aside the question of when the ATOM driver becomes selected, isn't the time accurate enough for your purposes simply by using the five networks servers within a minute or two? I take it that you have "iburst" against all the servers, and that you have one of them marked "prefer"? Can you accept a reduced accuracy until the ATOM kicks in? I've done it before so it's entirely possible to let it go for the total cycle time until ATOM is selected, it just means that the system then takes a while to slew into position after it has been on the Internet servers for a while. I was just hoping to have the best of both, faster convergence and then a kinder polling period afterwards. In the discussions I had with Dave Mills here some time back, I recall that it was a requirement that is the ref clock was at 16s intervals, the Internet servers shouldn't be at 1024s, although that does seem to work correctly here. I have at the back of my mind a feeling that it's tied in with the NMEA not working, i.e. the ATOM driver is somehow working on its own (as an edge of second reference) without a "time of day" source being polled at a similar interval. Anyway, all I can suggest is trying FreeBSD and seeing whether its serial drivers will work for you. I don't feel I can help further. FreeBSD's serial drivers are also very broken (in fact, even more broken than NetBSD because FreeBSD can't even see the DCD line). I'll just experiment with the keys and ntpq commands that Dave Hart suggested. That will probably get me what I'm looking for though I may have to stagger the drops and re-adds if it is truly a drop and re-add rather than just updating the parameters. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
"A C" wrote in message news:4f4a6e79.3010...@acarver.net... [] It's the latest dev version on NetBSD using five network servers plus the SHM refclock plus the ATOM refclock. The SHM is not very stable with its offset so I don't use it right now which leaves me ATOM plus network (one of the network servers is marked prefer). (Don't ask about using NMEA with PPS enabled, it doesn't work due to the serial drivers on NetBSD/sparc so PPS has to be separate via a second serial port). If I set minpoll to 8 or 9 to be nice to the network servers, it takes six or eight polling periods before ATOM turns on and becomes the system peer. If I leave out minpoll, ATOM clamps the polling period to 64 seconds. It still takes six to eight polling periods to activate ATOM but 8 * 64 is much less than 8 * 256 or 8 * 512. Thanks for that summary, there are so many systems being discussed that it's easy to lose touch! Leaving aside the question of when the ATOM driver becomes selected, isn't the time accurate enough for your purposes simply by using the five networks servers within a minute or two? I take it that you have "iburst" against all the servers, and that you have one of them marked "prefer"? Can you accept a reduced accuracy until the ATOM kicks in? In the discussions I had with Dave Mills here some time back, I recall that it was a requirement that is the ref clock was at 16s intervals, the Internet servers shouldn't be at 1024s, although that does seem to work correctly here. I have at the back of my mind a feeling that it's tied in with the NMEA not working, i.e. the ATOM driver is somehow working on its own (as an edge of second reference) without a "time of day" source being polled at a similar interval. Anyway, all I can suggest is trying FreeBSD and seeing whether its serial drivers will work for you. I don't feel I can help further. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/25/2012 23:19, David J Taylor wrote: "A C" wrote in message news:4f49ca89.9090...@acarver.net... On 2/25/2012 21:55, Ron Frazier (NTP) wrote: [] # GPS Lines server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 fudge 127.127.20.5 time2 0.3100 refid GPS1 # Internet server lines # NIST New York server nist1-ny.ustiming.org minpoll 8 maxpoll 13 # other internet server lines similar Sincerely, I know I can do that to the config file but then it takes forever to synchronize. As I said, the idea was to not give a min/maxpoll so that ntpd would converge on a clock adjustment quickly (polling once ever 64 seconds) and then, after a couple days, I could throttle back the polling interval without restarting the server and changing the configuration file. "Takes forever" is the problem you should try to solve. With the systems here, which have a GPS/PPS ref clock, they are synced within a minute of NTP starting, although it takes longer to get the ultimate accuracy. What version of ntp are you running, what OS, and what ref clock? It's the latest dev version on NetBSD using five network servers plus the SHM refclock plus the ATOM refclock. The SHM is not very stable with its offset so I don't use it right now which leaves me ATOM plus network (one of the network servers is marked prefer). (Don't ask about using NMEA with PPS enabled, it doesn't work due to the serial drivers on NetBSD/sparc so PPS has to be separate via a second serial port). If I set minpoll to 8 or 9 to be nice to the network servers, it takes six or eight polling periods before ATOM turns on and becomes the system peer. If I leave out minpoll, ATOM clamps the polling period to 64 seconds. It still takes six to eight polling periods to activate ATOM but 8 * 64 is much less than 8 * 256 or 8 * 512. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2012-02-26, Ron Frazier (NTP) wrote: > On 2/25/2012 6:42 PM, unruh wrote: >> On 2012-02-25, Richard B. Gilbert wrote: >> >>> On 2/25/2012 1:20 AM, A C wrote: >>> On 2/24/2012 21:26, A C wrote: > Is it possible to change the polling interval of one or more associated > servers at runtime? It seems like I should be able to run: > > ntpq -c "writevar&associd hpoll=N" or is it ppoll? > > Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. >>> What problem are you trying to solve? >>> >>> NTPD does a pretty good job of adjusting itself most of the time. >>> >>> Short poll intervals are useful when correcting large errors. >>> Long poll intervals allow NTPD to make small corrections very accurately. >>> >> IF the drift is very stable, long poll intervals allow ntpd to make >> small corrections to the drift rate accurately. They in general make the >> offsets larger and mean that the system cannot respond to changes (eg >> temp changes due to the coputer being used) rapidly. This is especially >> true of ntpd because it throws away 7/8 of the measurements in the clock >> filter, meaning that the actuall poll time is about 8 times longer than >> the set poll interval. (poll 10 then has an effective poll of 8000 sec) >> >> Anyway, that is an aside. I agree with you that I do not understand what >> problem he is trying to solve. >> > > I'll admit to not having read every sentence in this thread, but I have > a question about what was just said. Even if the clock algorithm > discards 7/8 of the measurements, as stated, isn't ntpd sitll hitting Yes. > the remote servers at whatever the minpoll value is set to, or the > default minpoll value if not set. So, if the internet servers are set > to a minpoll value of 8 (approximately 4 minutes), aren't those remote > servers actually getting polled every 4 minutes, regardless of what ntpd Yes. > does with the data. Which is why ntpd is very profligate of data. Not that hitting a remote server once every 4 min is much of a load-- that is about 1b/s on a link that can co 1b/s. Mind you if 1 machines are all trying to do that, things get serious. > > Sincerely, > > Ron > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
Ron Frazier (NTP) wrote: On 2/25/2012 6:42 PM, unruh wrote: On 2012-02-25, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar&associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. IF the drift is very stable, long poll intervals allow ntpd to make small corrections to the drift rate accurately. They in general make the offsets larger and mean that the system cannot respond to changes (eg temp changes due to the coputer being used) rapidly. This is especially true of ntpd because it throws away 7/8 of the measurements in the clock filter, meaning that the actuall poll time is about 8 times longer than the set poll interval. (poll 10 then has an effective poll of 8000 sec) Anyway, that is an aside. I agree with you that I do not understand what problem he is trying to solve. I'll admit to not having read every sentence in this thread, but I have a question about what was just said. Even if the clock algorithm discards 7/8 of the measurements, as stated, isn't ntpd sitll hitting the remote servers at whatever the minpoll value is set to, or the default minpoll value if not set. So, if the internet servers are set to a minpoll value of 8 (approximately 4 minutes), aren't those remote servers actually getting polled every 4 minutes, regardless of what ntpd does with the data. Minpoll 8 shouldn't cause servers any problem. Using iburst sometimes gets rate limit responses from my own servers when a client is restarted several times. My own systems have been affected by temperature changes this year and been stuck at faster poll rates than in previous years but I don't know if that is due to it being a warmer winter or different ntpd. Last week house was down at 15C overnight up to 25C during day. Ntpd is now 4.2.6p5. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
"A C" wrote in message news:4f49ca89.9090...@acarver.net... On 2/25/2012 21:55, Ron Frazier (NTP) wrote: [] # GPS Lines server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 fudge 127.127.20.5 time2 0.3100 refid GPS1 # Internet server lines # NIST New York server nist1-ny.ustiming.org minpoll 8 maxpoll 13 # other internet server lines similar Sincerely, I know I can do that to the config file but then it takes forever to synchronize. As I said, the idea was to not give a min/maxpoll so that ntpd would converge on a clock adjustment quickly (polling once ever 64 seconds) and then, after a couple days, I could throttle back the polling interval without restarting the server and changing the configuration file. "Takes forever" is the problem you should try to solve. With the systems here, which have a GPS/PPS ref clock, they are synced within a minute of NTP starting, although it takes longer to get the ultimate accuracy. What version of ntp are you running, what OS, and what ref clock? Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/26/2012 1:00 AM, A C wrote: On 2/25/2012 21:55, Ron Frazier (NTP) wrote: On 2/25/2012 5:05 PM, A C wrote: On 2/25/2012 13:09, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar &associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. The idea was to bump up the minimum poll interval after ntpd has been running for a day or so to something more kind to the remote servers because the refclock is holding the remote servers clamped to 64 seconds. If I set minpoll in the config file, then ntpd's start up takes a long time because of a long poll interval. If I don't set the minpoll, then ntpd doesn't do "a pretty good job" because it clamps the polling interval. I've noticed the same thing. You could try what I'm doing, although I'm still testing for the best configuration. # GPS Lines server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 fudge 127.127.20.5 time2 0.3100 refid GPS1 # Internet server lines # NIST New York server nist1-ny.ustiming.org minpoll 8 maxpoll 13 # other internet server lines similar Sincerely, I know I can do that to the config file but then it takes forever to synchronize. As I said, the idea was to not give a min/maxpoll so that ntpd would converge on a clock adjustment quickly (polling once ever 64 seconds) and then, after a couple days, I could throttle back the polling interval without restarting the server and changing the configuration file. I'm polling the GPS every 8 seconds, and it's the preferred server. I'm allowing it to poll the GPS at up to every 64 seconds. Note that I've forced the internet servers to a longer interval, but that doesn't affect convergence time if the GPS server is my primary time source, denoted with "*", as far as I can tell. I can preset the clock to within a few 10's of ms or so with something like NTPDATE to an internet NIST server, or even with the GUI interface to the clock to within 300 ms or so if I'm really careful how I click the mouse button. Once I start NTPD, it locks into the GPS and starts polling every 8 seconds. I get synchronized to within 20 ms or so within just a few minutes. A few minutes more, and I get to the level of accuracy which is at the limit of my USB GPS, which is about 6 mS. I don't know if you're running PPS or not. I'm not running PPS. If you need uS accuracy, I'm sure it will take longer. What I'm describing is running on Windows. I've tried to do the same thing on Linux. However, when I'm on Linux, even if the clock is synchronized to within 30 mS when I start NTPD, I immediately get offsets reported from all clock sources in the 500 - 5000 mS range. I don't know why. The best I can do is to sync the clock with the GUI interface while NTPD is running and get it to within 300 - 500 ms just comparing to my wristwatch (which is atomic). Then I let it sync up from there. I think there is a problem with the startup code in NTPD when it's pulling time from the NMEA driver and running Linux. You cannot run NTPDATE while NTPD is running, which is why I have to use the GUI. However, in Windows at least, I don't have to wait any more than half an hour to get synchronized to within the limits of my equipment. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/25/2012 21:55, Ron Frazier (NTP) wrote: On 2/25/2012 5:05 PM, A C wrote: On 2/25/2012 13:09, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar &associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. The idea was to bump up the minimum poll interval after ntpd has been running for a day or so to something more kind to the remote servers because the refclock is holding the remote servers clamped to 64 seconds. If I set minpoll in the config file, then ntpd's start up takes a long time because of a long poll interval. If I don't set the minpoll, then ntpd doesn't do "a pretty good job" because it clamps the polling interval. I've noticed the same thing. You could try what I'm doing, although I'm still testing for the best configuration. # GPS Lines server 127.127.20.5 prefer minpoll 3 maxpoll 6 mode 72 fudge 127.127.20.5 time2 0.3100 refid GPS1 # Internet server lines # NIST New York server nist1-ny.ustiming.org minpoll 8 maxpoll 13 # other internet server lines similar Sincerely, I know I can do that to the config file but then it takes forever to synchronize. As I said, the idea was to not give a min/maxpoll so that ntpd would converge on a clock adjustment quickly (polling once ever 64 seconds) and then, after a couple days, I could throttle back the polling interval without restarting the server and changing the configuration file. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/25/2012 5:05 PM, A C wrote: On 2/25/2012 13:09, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar &associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. The idea was to bump up the minimum poll interval after ntpd has been running for a day or so to something more kind to the remote servers because the refclock is holding the remote servers clamped to 64 seconds. If I set minpoll in the config file, then ntpd's start up takes a long time because of a long poll interval. If I don't set the minpoll, then ntpd doesn't do "a pretty good job" because it clamps the polling interval. I've noticed the same thing. You could try what I'm doing, although I'm still testing for the best configuration. # GPS Lines server 127.127.20.5prefer minpoll 3 maxpoll 6 mode 72 fudge 127.127.20.5 time2 0.3100 refid GPS1 # Internet server lines # NIST New York server nist1-ny.ustiming.org minpoll 8 maxpoll 13 # other internet server lines similar Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/25/2012 6:42 PM, unruh wrote: On 2012-02-25, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar&associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. IF the drift is very stable, long poll intervals allow ntpd to make small corrections to the drift rate accurately. They in general make the offsets larger and mean that the system cannot respond to changes (eg temp changes due to the coputer being used) rapidly. This is especially true of ntpd because it throws away 7/8 of the measurements in the clock filter, meaning that the actuall poll time is about 8 times longer than the set poll interval. (poll 10 then has an effective poll of 8000 sec) Anyway, that is an aside. I agree with you that I do not understand what problem he is trying to solve. I'll admit to not having read every sentence in this thread, but I have a question about what was just said. Even if the clock algorithm discards 7/8 of the measurements, as stated, isn't ntpd sitll hitting the remote servers at whatever the minpoll value is set to, or the default minpoll value if not set. So, if the internet servers are set to a minpoll value of 8 (approximately 4 minutes), aren't those remote servers actually getting polled every 4 minutes, regardless of what ntpd does with the data. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2012-02-25, Richard B. Gilbert wrote: > On 2/25/2012 1:20 AM, A C wrote: >> On 2/24/2012 21:26, A C wrote: >>> Is it possible to change the polling interval of one or more associated >>> servers at runtime? It seems like I should be able to run: >>> >>> ntpq -c "writevar &associd hpoll=N" or is it ppoll? >>> >> >> Actually, I should have been more specific and say change the minimum >> polling interval. In other words, be able to adjust the conf file's >> minpoll flag at runtime instead of restarting. > > What problem are you trying to solve? > > NTPD does a pretty good job of adjusting itself most of the time. > > Short poll intervals are useful when correcting large errors. > Long poll intervals allow NTPD to make small corrections very accurately. IF the drift is very stable, long poll intervals allow ntpd to make small corrections to the drift rate accurately. They in general make the offsets larger and mean that the system cannot respond to changes (eg temp changes due to the coputer being used) rapidly. This is especially true of ntpd because it throws away 7/8 of the measurements in the clock filter, meaning that the actuall poll time is about 8 times longer than the set poll interval. (poll 10 then has an effective poll of 8000 sec) Anyway, that is an aside. I agree with you that I do not understand what problem he is trying to solve. > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/25/2012 13:09, Richard B. Gilbert wrote: On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar &associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. The idea was to bump up the minimum poll interval after ntpd has been running for a day or so to something more kind to the remote servers because the refclock is holding the remote servers clamped to 64 seconds. If I set minpoll in the config file, then ntpd's start up takes a long time because of a long poll interval. If I don't set the minpoll, then ntpd doesn't do "a pretty good job" because it clamps the polling interval. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/25/2012 1:20 AM, A C wrote: On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar &associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. What problem are you trying to solve? NTPD does a pretty good job of adjusting itself most of the time. Short poll intervals are useful when correcting large errors. Long poll intervals allow NTPD to make small corrections very accurately. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On Sat, Feb 25, 2012 at 06:20, A C wrote: > On 2/24/2012 21:26, A C wrote: >> >> Is it possible to change the polling interval of one or more associated >> servers at runtime? It seems like I should be able to run: >> >> ntpq -c "writevar &associd hpoll=N" or is it ppoll? >> > > Actually, I should have been more specific and say change the minimum > polling interval. In other words, be able to adjust the conf file's minpoll > flag at runtime instead of restarting. Yes but first you have to set up a ntp.keys file and reference from ntp.conf keys containing a symmetric key ID, type, and secret which you'll use for runtime configuration: in ntp.keys: 1 M mysecret # choose keyid from 1-65535, longer secret is stronger in ntp.conf: keys "/etc/ntp.keys" # match key ID from ntp.keys for both controlkey 1 # key allowed to remotely manage trustedkey 1 # keys trusted for symmetric auth including management Then something like the below will work: ntpq -c "keyid 1" -c "passwd mysecret" -c ":config unpeer server.to.change" -c ":config server server.to.change iburst minpoll Y" If you leave off the passwd command you'll be prompted for the secret and can type it without displaying it. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Change poll interval at runtime?
On 2/24/2012 21:26, A C wrote: Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar &associd hpoll=N" or is it ppoll? Actually, I should have been more specific and say change the minimum polling interval. In other words, be able to adjust the conf file's minpoll flag at runtime instead of restarting. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Change poll interval at runtime?
Is it possible to change the polling interval of one or more associated servers at runtime? It seems like I should be able to run: ntpq -c "writevar &associd hpoll=N" or is it ppoll? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
