[ntp:questions] NTP phase lock loop inputs and outputs?
I'm doing NTP exchanges to determine my clock offset. I use this to adjust my clock frequency, but there's a lot of lag so I overshoot by too much and it oscillates around the reference frequency. This is an audio clock so I have to do my own NTP stuff. I think I want to use a phase lock loop as described in the NTP literature, but I'm confused by the terminology (and possibly the math) so I'm not sure what the inputs or outputs should be. If my reference clock is running at ~44100 Hz and through my NTP exchanges, I get an instantaneous offset of -20 Hz, I want to adjust my clock to 44080 Hz, but no more than 5 Hz/sec (so it's not audible) and that instantaneous offset will likely change as it narrows in on the true frequency. The formula I've seen for NTP's PLL is: y = (Vs*u) / (64Tc)^2 I do NTP packet exchanges every 2 seconds so I think that resolves to: y = (2*Vs) / 16384 Is Vs the actual reference frequency estimate (44080 Hz in this case)? I'm not sure how I use the result of the equation to adjust the clock. I guess my question is that if I think my frequency is 44100 Hz and via an NTP exchange, I calculate I'm off by -20 Hz, how should I calculate what I should set my frequency to, to slowly sync to the reference frequency (no more than 5 Hz/sec) while also factoring in the previous clock offset estimate? The current scheme I'm using to simply set my clock to 44100-5 Hz (capping the -20 Hz offset to 5) every 2 seconds doesn't work very well because it's too slow to realize that the direction of the offset has changed because the absolute clock offset is still negative (e.g. went from -20 to -5, but it's still negative so it thinks it still needs to reduce the clock frequency when it should probably increase it or leave it the same). ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 18, 12:39 am, [EMAIL PROTECTED] (Danny Mayer) wrote: > > It's not doing nothing. If the CPU is on standby nothing, including > ntpd, should be running. One thing is the CPU in standby, something else the whole system. In modern x86 systems running Linux, the CPU enters C1 state when there's no task to run. When the CPU is in the C1 state, the internal circuitry is shutdown, reducing the power used by the by about one order of magnitude. Some processors will automatically enter deeper CPU standby states, others require OS intervention. Linux will use all available CPU standby states as often as possible by default. So even after a few fractions of a second in the C1 state, it can put the CPU in C2 (or C3) state, when the processor disconnects the core from the bus interface keeping caches coherent (or not), reducing the power to a fraction of the C1 state. Amazingly enough, servers spend most of the time in a C state, whether waiting for disk access or for network replies. Therefore, it's a critical part of power management in data-center. In data-centers, every W used by equipment will require another W in AC. With several systems, it's not difficult to end up with a few kWh everyday due to NTP, which translates into possibly hundreds of dollars in additional costs. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On May 16, 6:44 pm, "David L. Mills" <[EMAIL PROTECTED]> wrote: > > With respect, you miss the point. The ntpd does not require a tickle > every second just to scan for polls; it requires that tickle in order to > discipline the clcok frequency. The additional cycles necessary to link > to the next association structure, then increment and test a variable, > are way, way down in the noise. I don't pretend to know NTP innards, but wouldn't it be possible to select the scale of updates? And, please, don't consider the power used by NTP itself, but rather the power used by the CPU idling in a higher power state than before NTP woke it up. Modern processors can draw 100W without doing anything useful, but it falls down to less than 10W it it's allowed run the HALT instruction instead when there's nothing to do. The picture that Red Hat refers to is that the CPU is removed from a deep C-state in order to run NTP for microseconds and then it remains in the running state for a few fractions of a second until it goes back to a deep C-state. So it's not a matter of NTP's duty cycle, but the duty cycle resulting from the heuristics used by the hardware or the OS to decide when to place the CPU in a deep C-state. HTH ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Another item is due to the consecutive namechanges ntp --> xntp --> ntp and the linux standardisation effort LSB. when xntp was recent the LSB ( Linux Standards Base ) fixed some names for required functionality which lead to some distributions still naming the timekeeping package "xntp" and the rcscript "rcxntp" though the distributed ntp version is as recent as can be. This still leads to some friendly greeting "to first update their ancient version of (x)ntp" for linuxers asking for help. I assume that this is a bit of a "cats and dogs" issue. All the ntpregulars seem to be very friendly on all other occasions ;-) But it certainly has been habit forming on both sides. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On 2008-05-18, Unruh <[EMAIL PROTECTED]> wrote: > Uwe Klein <[EMAIL PROTECTED]> writes: >>Linux presents afaik the biggest userbase for ntp (and is >>simultanously the most derided group of questioneers in this NG, > > I certainly have no idea what you are talking about. What derision? The Linux kernel maintainer are regularly criticised for making changes which are hostile to NTP. Frequent statments have been made that Linux is an inferior plaform for NTP (e.g. WRT to lost interrrupts, etc.) >>though i think compared to the installed instances linux is imho >>underrepresented). If a large group is beat over the head in a >>somewhat regular fashion ( which may have been just a cats and dogs >>thing ) it is rather unsurprising to find those people working around >>this obstacle. > > What "beat over the head"? What obstacle? If a group is frequently criticized, or their requests are dismissed out of hand they may very well implement their own solutions. >>Whichever way one does this ntp needs to be able to respond to finer >>grained external triggers. It can not any longer be "King of the >>Castle". > > No idea what this means either. "King of the Castle" == the most important code running on the system. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
On 2008-05-17, Chris Adams <[EMAIL PROTECTED]> wrote: > Once upon a time, David Woolley <[EMAIL PROTECTED]> said: > >>I'm not convinced this is even about laptops. I think it is about >>PDAs, or about embedded systems that may run for a year on a couple of >>AA bateries, or may run on small photocell arrays. > > It is about pretty much anything running Linux, from embedded devices > to servers. Large colocation factilities have discovered that the > limiting factor is not space anymore, but power and cooling. Anything > that can be done that makes the servers use less power is a big win. A system functioning as an NTP server (i.e. one which answers polls from clients) needs to be ready to respond to a poll at any time. It stands to reason the such a system would likely never be completely quiescent. And that such a system probably could not, or should not, take advantage of this power-saving patch, A system funtioning as an NTP client (i.e. a leaf node with no polling clients) merely has to be awake enough to poll its time sources and discipline its clock in compliance with its time stability requirements. This discussion is arguing the merits of a patch without any consideration of when its use is indicated. As stated elsewhere in this thread, one size does _not_ fit all. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Unruh wrote: > I am totally confused. The cpu is in sleep mode. The cpu is not doing > anything. ntp is NOT running. ntp cannot wake up the cpu because ntp is not > running. Only external events can wake up the cpu, and ntp is not an > external event. So, once the cpu is woken up, and ntp can run, what does it > matter if ntp then runs? you've got it assbackwards. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Unruh wrote: > I am totally confused. The cpu is in sleep mode. The cpu is not doing > anything. ntp is NOT running. ntp cannot wake up the cpu because ntp is not > running. Only external events can wake up the cpu, and ntp is not an > external event. So, once the cpu is woken up, and ntp can run, what does it > matter if ntp then runs? Ntp runs whenever one of the pieces of hardware it watches reports an event. One of those is the once-per-second wakeup call. But as I said elsewhere in this thread, I don't think that the important thing is ntpd's own power footprint, but rather the implications of the platform's attempts at saving power. Or as someone else put it: the basic assumptions ntpd makes of the behaviour of the platform (hardware and OS) while it's _not_ running (i.e. between invocations of itself). Cheers, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Uwe Klein <[EMAIL PROTECTED]> writes: >David Woolley wrote: >> Uwe Klein wrote: >> >>> Danny Mayer wrote: >>> It's not doing nothing. If the CPU is on standby nothing, including ntpd, should be running. >>> >>> >>> ntp would then need to accomodate thinks like a "sleep mode"? >>> and a "trigger" of type "Query the associations now" >>> ( on linux forex be d-bus aware? ) >> >> >> The impression I get is that ntpd should be treated as infrastructure, >> and have power management states, but Red Hat are treating it as an >> errant application that needs to be modified to avoid upsetting the >> power management apple cart. >Hello David, >I am not surprised. >Linux presents afaik the biggest userbase for ntp (and is simultanously >the most derided group of questioneers in this NG, though i think compared >to the installed instances linux is imho underrepresented). >If a large group is beat over the head in a somewhat regular fashion >( which may have been just a cats and dogs thing ) it is rather >unsurprising to find those people working around this obstacle. I certainly have no idea what you are talking about. What derision? What "beat over the head"? What obstacle? > E.g. after resume from RAM, it needs to >> progress the clock discipline algorithm forwards (including extra >> corrections for temperature excursions) before anything is allowed to >> read the value of the clock, and after resume from disk, it should >> probably do a restart. >Well it should start with ntp getting signaled to prepare for various >modes of sleep or cpu frequency slowdown. >Save as much state as is possible, then ack for sleep. >There is actually another situation where currently ntp is just >killed of and started again: network interface changes. >This could be handled in a less disruptive way as well. >> >> The latter greatly increases the importance of fast convergence, and >> without specific compensation for temperature variation, even resume >> from RAM needs the ability to respond fast to frequency hits, possibly >> conditioned on just having done a resume. >Whichever way one does this ntp needs to be able to respond to finer >grained external triggers. It can not any longer be "King of the Castle". No idea what this means either. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Uwe Klein <[EMAIL PROTECTED]> writes: >Danny Mayer wrote: >> It's not doing nothing. If the CPU is on standby nothing, including >> ntpd, should be running. >ntp would then need to accomodate thinks like a "sleep mode"? >and a "trigger" of type "Query the associations now" >( on linux forex be d-bus aware? ) >The basic assumptions about the host systems ntp runs on are >changing fast! I am totally confused. The cpu is in sleep mode. The cpu is not doing anything. ntp is NOT running. ntp cannot wake up the cpu because ntp is not running. Only external events can wake up the cpu, and ntp is not an external event. So, once the cpu is woken up, and ntp can run, what does it matter if ntp then runs? >uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
David Woolley wrote: > Uwe Klein wrote: > >> Danny Mayer wrote: >> >>> It's not doing nothing. If the CPU is on standby nothing, including >>> ntpd, should be running. >> >> >> ntp would then need to accomodate thinks like a "sleep mode"? >> and a "trigger" of type "Query the associations now" >> ( on linux forex be d-bus aware? ) > > > The impression I get is that ntpd should be treated as infrastructure, > and have power management states, but Red Hat are treating it as an > errant application that needs to be modified to avoid upsetting the > power management apple cart. Hello David, I am not surprised. Linux presents afaik the biggest userbase for ntp (and is simultanously the most derided group of questioneers in this NG, though i think compared to the installed instances linux is imho underrepresented). If a large group is beat over the head in a somewhat regular fashion ( which may have been just a cats and dogs thing ) it is rather unsurprising to find those people working around this obstacle. E.g. after resume from RAM, it needs to > progress the clock discipline algorithm forwards (including extra > corrections for temperature excursions) before anything is allowed to > read the value of the clock, and after resume from disk, it should > probably do a restart. Well it should start with ntp getting signaled to prepare for various modes of sleep or cpu frequency slowdown. Save as much state as is possible, then ack for sleep. There is actually another situation where currently ntp is just killed of and started again: network interface changes. This could be handled in a less disruptive way as well. > > The latter greatly increases the importance of fast convergence, and > without specific compensation for temperature variation, even resume > from RAM needs the ability to respond fast to frequency hits, possibly > conditioned on just having done a resume. Whichever way one does this ntp needs to be able to respond to finer grained external triggers. It can not any longer be "King of the Castle". G! uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Uwe Klein wrote: > Danny Mayer wrote: > >> It's not doing nothing. If the CPU is on standby nothing, including >> ntpd, should be running. > > ntp would then need to accomodate thinks like a "sleep mode"? > and a "trigger" of type "Query the associations now" > ( on linux forex be d-bus aware? ) The impression I get is that ntpd should be treated as infrastructure, and have power management states, but Red Hat are treating it as an errant application that needs to be modified to avoid upsetting the power management apple cart. E.g. after resume from RAM, it needs to progress the clock discipline algorithm forwards (including extra corrections for temperature excursions) before anything is allowed to read the value of the clock, and after resume from disk, it should probably do a restart. The latter greatly increases the importance of fast convergence, and without specific compensation for temperature variation, even resume from RAM needs the ability to respond fast to frequency hits, possibly conditioned on just having done a resume. > > The basic assumptions about the host systems ntp runs on are > changing fast! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Danny Mayer wrote: > It's not doing nothing. If the CPU is on standby nothing, including > ntpd, should be running. ntp would then need to accomodate thinks like a "sleep mode"? and a "trigger" of type "Query the associations now" ( on linux forex be d-bus aware? ) The basic assumptions about the host systems ntp runs on are changing fast! uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
David L. Mills wrote: > Uwe, > > Problem is that, while GPS could in principle provide guidance beyond > Earth space, the signal strength is not sufficient for Moon navigation. Right. emphasis was on GPS _like_ This would have to be a new system. Are there any nonregular effects in space transmissions? I think not. uwe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
