Re: [Ptpd-devel] PTPd servo gains vs. attenuations

[Wojciech O. <woj...@ow...>]

Poul-Henning,

That's basically already done, just without the function pointer - there is a structure describing the controller and its properties and a single function implementing one iteration of the servo, and indeed phase offset comes in and frequency offset comes out. User can implement whatever they want. That is all nice and well and after 2.3 we will go ahead with modularisation and the structure will get function pointer(s) - that is the long term goal.

Thing is, we want to get ptpd out of the "by researchers, for researchers" realm. While it's great to allow people to add their own implementations, the focus right now is to get a stable release out after more than a year since the previous one, with sane defaults and good performance, suitable for basic enterprise deployment. So I was really looking for advice about the default servo choice for the imminent release.

Regards,
Wojciech

-
Wojciech Owczarek


On 19 Aug 2013, at 20:24, "Poul-Henning Kamp" <ph...@ph...> wrote:

> In message <CAHyFsxknaPKdCY-g_wDPZ41d6qPr=MRQ...@ma...>
> , Wojciech Owczarek writes:
> 
>> So my gut feeling was to go for double precision, but I know we have at
>> least some users wanting to stick to integer. If it was up to me I would
>> drop the integer version altogether.
> 
> What you really should do is make the entire PLL/Servo thing a
> pluggable component, so that you can have multiple different versions.
> 
> That will allow people to play with integers, kalman filters, 3rd
> order PLLs, autotuning PLLs, adaptive PLLs, all without the default
> code becoming a mess of #ifdefs.
> 
> After all, the interface Is really simple:  Offset measurements
> go in, frequency adjustments come out.
> 
> So what you need is a function pointer you call with new measurements
> and a function to call at the other end, to change the kernel frequency.
> 
> You should probably keep the step-logic generic, its going to be
> almost identical for all PLLs anyway.
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.