PLL (was Re: Objectives for the next year)

Achim Gratz Stromeko at nexgo.de
Sun Jun 20 13:25:52 UTC 2021


Hal Murray via devel writes:
> esr at thyrsus.com said:
>> I did.  There's a blog post about it:
>> https://blog.ntpsec.org/2017/02/22/testframe-the-epic-failure.html 
>
> From there:
>> One was what in discussion on the mailing list I later tagged "the code-path
>> split". There are two kinds of NTP hosts; one uses a kernel facility known as
>> the "PLL" for doing fine adjustments to the tick speed of the system clock,
>> the other kind does not. Most of our potential deployment targets have PLLs;
>> an undismissable minority do not. 
>
> What do you mean by PLL?  Which systems don't have it?

Essentially all of them if you go by system count, although I think *BSD
might still have it.  The in-kernel PLL that is still in Linux has been
effectively dead for quite some time since it never was updated to work
with the tickless kernel that is the default for all main platforms
Linux works on.

> A PLL requires 2 things.  One is a knob/switch to adjust something.  The other 
> is sensor to compare something against a target setting and use that to 
> control the knob.  A thermostat and heater is the normal example.
>
> The kernels I'm familiar with have the knob but not the sensor.  They actually 
> do have a sensor if you build the kernel with the right option but none of the 
> distros I'm familiar with ship with that option enabled.

The in-kernel PLL is exactly the same as the one in ntpd, except that it
benefits from a much higher update rate (each tick vs. each second).
THe control data comes from ntpd when it gets enabled.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves



More information about the devel mailing list