[Linuxptp-devel] Optimal P, I constants

[Miroslav Lichvar]

I've been experimenting with phc2sys and the clknetsim simulator to
find out how is the clock synchronization affected by changes in the
P, I constants with different jitters and clock stabilities, and I
thought others on this list might be interested in the results.

The instability of the clock frequency is called wander and it is
described by random-walk noise. A good value used to simulate an
average computer clock is around 0.5 ppb/s. However, there are
non-random effects like changes in the temperature due to variations
in the CPU load etc, which may quickly change the frequency by several
ppm. These effects are difficult to describe, so I simply use a larger
wander (up to 10 ppb/s) to make a room for them. In some older
experiments with NTP, when compared to results obtained on real HW,
this worked pretty well.

I'm also interested in how stable are the PTP clocks to allow better
configuration of the ptp4l servo. I've measured the Allan deviation
with two different NICs. One seems to have an ordinary oscillator
(wander slightly below 1 ppb/s), the other seems to have some kind of
stabilization (wander around 0.01 ppb/s). Here is a plot of the two
measured deviations and a simulation with 1us jitter and 1ppb/s wander
for comparison:
Loading Image...

The time interval in the Allan deviation plot where the -1 jitter
slope intersects the +1/2 wander slope is called Allan intercept. It
is a ratio of the jitter and wander.

The results of the servo tests are presented here in maps. I tried 3D
plots, but it wasn't very readable. The X axis is the P constant in
log10, the Y axis is the I constant in log10 and the Z axis is the
measured RMS time error of the simulated clock in decibels relative to
the lowest (best) value in the map. Please note that the absolute
values of jitter and wander are not really important here, only their
ratio - Allan intercept.

First is a map done with 10ns normally distributed jitter, 10ppb/s
wander and 1s update interval. It looks like this is the case the
current phc2sys default P, I (0.7, 0.3) are optimized for.

-4.0 -3.7 -3.3 -3.0 -2.7 -2.3 -2.0 -1.7 -1.3 -1.0 -0.7 -0.3 +0.0
-5.0 42 39 37 36 35 33 31 30 27 27 26 22 19
-4.7 40 38 36 34 33 31 30 28 26 25 24 22 19
-4.3 39 35 35 33 32 30 28 26 24 23 21 18 18
-4.0 37 34 33 31 30 28 27 25 23 22 20 18 16
-3.7 34 33 31 30 28 26 25 23 21 20 17 16 15
-3.3 34 31 29 27 26 24 23 21 20 18 16 14 13
-3.0 31 29 29 26 24 23 21 20 18 16 15 13 11
-2.7 31 27 27 25 24 21 20 18 16 15 13 11 10
-2.3 29 27 25 23 21 20 18 16 15 13 11 10 8
-2.0 27 24 23 21 20 18 16 15 13 11 10 8 6
-1.7 24 22 21 19 18 16 15 13 11 10 8 6 5
-1.3 22 21 19 18 17 14 13 11 10 8 6 5 3
-1.0 22 19 18 16 15 13 11 10 8 6 5 3 2
-0.7 18 18 17 14 13 11 10 8 6 5 3 2 0
-0.3 18 17 15 12 12 10 9 7 5 4 2 1 0
+0.0 18 16 14 13 12 10 8 7 5 3 2 1 1

This one is with 100us jitter, 10ppb/s wander and 1s interval. The
best I constant now becomes impractical as it will take hours
for the servo to converge.

-4.0 -3.7 -3.3 -3.0 -2.7 -2.3 -2.0 -1.7 -1.3 -1.0 -0.7 -0.3 +0.0
-5.0 15 12 10 8 6 4 3 2 2 3 5 7 9
-4.7 11 10 9 6 4 3 2 1 1 3 5 6 9
-4.3 9 8 6 5 3 2 1 0 1 3 5 6 9
-4.0 7 7 6 4 3 1 0 0 1 3 5 6 9
-3.7 10 9 6 4 3 2 1 0 1 3 5 6 9
-3.3 10 8 8 6 4 3 1 1 2 3 5 6 9
-3.0 12 11 9 8 6 5 3 2 2 3 5 6 9
-2.7 15 13 11 9 7 6 5 3 3 3 5 6 9
-2.3 16 13 13 11 10 8 6 5 4 4 5 6 9
-2.0 17 17 15 12 11 9 8 6 5 4 5 7 9
-1.7 20 17 16 15 13 11 10 8 6 5 5 7 9
-1.3 19 18 18 16 14 13 11 9 8 7 6 7 9
-1.0 18 18 18 17 16 15 13 11 10 8 7 7 9
-0.7 16 16 16 16 16 15 14 13 11 10 9 8 9
-0.3 15 15 15 14 14 14 14 14 13 11 10 10 10
+0.0 13 13 13 13 13 13 13 13 13 12 12 11 11

To see how the results change with different update intervals, these
three are with 10ns jitter, 1ppb/s wander, and 100s, 1s and 0.01s
update intervals respectively. The sudden jump to 45-47 shows where
the servo becomes unstable.

-3.0 -2.7 -2.3 -2.0 -1.7 -1.3 -1.0 -0.7 -0.3 +0.0 +0.3 +0.7 +1.0
-3.0 10 9 7 5 46 46 46 46 45 45 45 45 45
-2.7 9 7 5 3 46 46 46 46 46 45 45 45 45
-2.3 7 5 3 2 46 46 46 46 46 46 45 45 45
-2.0 5 3 2 0 46 46 46 46 46 45 45 45 45
-1.7 3 2 0 46 46 46 46 46 45 46 45 45 45
-1.3 46 46 46 46 46 46 46 46 46 45 45 45 45
-1.0 46 46 46 46 46 46 46 46 46 46 45 45 45
-0.7 46 46 46 46 45 46 46 46 45 46 45 45 45
-0.3 46 46 46 46 45 46 45 46 45 45 45 45 45
+0.0 45 46 46 46 46 46 45 45 45 45 45 45 45

-3.0 -2.7 -2.3 -2.0 -1.7 -1.3 -1.0 -0.7 -0.3 +0.0 +0.3 +0.7 +1.0
-3.0 19 18 16 15 13 11 10 9 7 4 46 46 46
-2.7 19 16 15 13 12 10 8 7 5 4 47 46 46
-2.3 18 14 13 11 10 8 6 5 4 3 47 47 46
-2.0 15 14 12 10 8 6 5 3 2 2 47 47 47
-1.7 14 11 10 8 6 5 3 2 1 2 47 47 47
-1.3 13 10 8 6 5 3 2 1 0 2 47 47 47
-1.0 10 11 8 6 5 3 2 0 0 2 47 47 47
-0.7 11 11 8 7 5 4 2 1 1 2 47 47 47
-0.3 13 11 10 9 7 5 4 2 2 3 47 47 47
+0.0 15 14 13 10 9 7 6 4 4 5 47 47 47

-3.0 -2.7 -2.3 -2.0 -1.7 -1.3 -1.0 -0.7 -0.3 +0.0 +0.3 +0.7 +1.0
-3.0 36 35 28 31 23 23 10 7 6 2 1 14 15
-2.7 31 35 27 30 10 21 7 4 3 2 1 1 9
-2.3 28 31 24 31 23 16 7 4 2 1 1 2 2
-2.0 21 29 29 25 21 7 5 3 2 1 0 2 3
-1.7 26 28 27 26 18 15 4 4 2 1 1 1 4
-1.3 21 18 29 26 12 13 9 4 3 2 1 2 3
-1.0 27 23 23 21 14 10 9 5 4 4 2 2 4
-0.7 19 18 25 21 13 14 9 8 6 5 3 3 4
-0.3 22 21 12 20 17 12 12 9 9 6 5 4 4
+0.0 20 17 14 16 13 15 12 11 9 8 6 5 5

More data and the script which was used to generate it is available
here:
http://mlichvar.fedorapeople.org/clknetsim/ptp/pi_search/

I was wondering how useful it would be to have a new servo parameter
for the Allan intercept and set the P, I constants automatically
according the intercept and measured clock update interval. What do
you think?

[Keller, Jacob E]

-----Original Message-----
Sent: Tuesday, April 23, 2013 6:45 AM
Subject: [Linuxptp-devel] Optimal P, I constants
I've been experimenting with phc2sys and the clknetsim simulator to
find out how is the clock synchronization affected by changes in the
P, I constants with different jitters and clock stabilities, and I
thought others on this list might be interested in the results.

<snip>

More data and the script which was used to generate it is available
http://mlichvar.fedorapeople.org/clknetsim/ptp/pi_search/
I was wondering how useful it would be to have a new servo parameter
for the Allan intercept and set the P, I constants automatically
according the intercept and measured clock update interval. What do
you think?
--
Miroslav Lichvar

Hey Miroslav -

First of all, thank you for the detail, this is an impressive in depth look at the P/I servos.

I think it might be better (at first) to create a new clock which is based on Allan intercept, since most people doing PTP are familiar enough with the P/I constants servo. I do think in the long term it definitely makes more sense to put the Allan intercept, as that appears to work better, and is easier to measure if I am not mistaken? (Jitter * wander in pbb, right?)


Wouldn't this also have to set the update frequency as well? It appears that some update frequencies cause the result to be unstable or too slow..

Thanks

- Jake

[Miroslav Lichvar]

Post by Keller, Jacob E
I think it might be better (at first) to create a new clock which is based on Allan intercept, since most people doing PTP are familiar enough with the P/I constants servo.

I think the options to set P, I directly could be still used, the new
option would be effective only if the configured P or I was zero, or
the new option was non-zero.

Post by Keller, Jacob E
I do think in the long term it definitely makes more sense to put the Allan intercept, as that appears to work better, and is easier to measure if I am not mistaken? (Jitter * wander in pbb, right?)

The Allan intercept is approximately
(jitter / wander_per_second)^(2/3) * 2

The deviation can be calculated from offsets reported by phc2sys (or
ptp4l) when free running and the intercept can be estimated from the
plot. A tool I use is at https://github.com/mlichvar/ppsallan.

With phc2sys it can be used like this:
phc2sys -P 1e-50 -I 1e-50 -m | tail -n +10 > log
awk '{ printf "%.9f\n", $4 * 1e-9 }' < log | ppsallan -B > adev
plotallan adev

The offsets should be collected at one second interval, or the result
needs to be scaled accordingly. To see the +1/2 slope well, it's
good to have at least 10 hours or more of data.

Post by Keller, Jacob E
Wouldn't this also have to set the update frequency as well? It appears that some update frequencies cause the result to be unstable or too slow..

Yes, the update interval would need to be included in the P, I
calculation. I think that's the main problem with the current code,
that the sync interval can change to a longer one in the runtime, but
P, I don't change and the servo may suddenly be unstable.

Ideally, the constants would be adjusted automatically according to
the current conditions. Or try a more sophisticated servo. I have some
ideas I want to explore, but it's not on my short-term todo list.

Thanks,

[Keller, Jacob E]

-----Original Message-----
Sent: Wednesday, April 24, 2013 2:35 AM
To: Keller, Jacob E
Subject: Re: [Linuxptp-devel] Optimal P, I constants

Post by Keller, Jacob E
I think it might be better (at first) to create a new clock which is based

on Allan intercept, since most people doing PTP are familiar enough
with the P/I constants servo.
I think the options to set P, I directly could be still used, the new
option would be effective only if the configured P or I was zero, or
the new option was non-zero.

Post by Keller, Jacob E
I do think in the long term it definitely makes more sense to put the

Allan intercept, as that appears to work better, and is easier to measure
if I am not mistaken? (Jitter * wander in pbb, right?)
The Allan intercept is approximately
(jitter / wander_per_second)^(2/3) * 2
The deviation can be calculated from offsets reported by phc2sys (or
ptp4l) when free running and the intercept can be estimated from the
plot. A tool I use is at https://github.com/mlichvar/ppsallan.
phc2sys -P 1e-50 -I 1e-50 -m | tail -n +10 > log
awk '{ printf "%.9f\n", $4 * 1e-9 }' < log | ppsallan -B > adev
plotallan adev
The offsets should be collected at one second interval, or the result
needs to be scaled accordingly. To see the +1/2 slope well, it's
good to have at least 10 hours or more of data.

Post by Keller, Jacob E
Wouldn't this also have to set the update frequency as well? It

appears that some update frequencies cause the result to be unstable
or too slow..
Yes, the update interval would need to be included in the P, I
calculation. I think that's the main problem with the current code,
that the sync interval can change to a longer one in the runtime, but
P, I don't change and the servo may suddenly be unstable.
Ideally, the constants would be adjusted automatically according to
the current conditions. Or try a more sophisticated servo. I have some
ideas I want to explore, but it's not on my short-term todo list.
Thanks,
--
Miroslav Lichvar

I like the dynamic adjustments idea, but definitely would require work.

- Jake

[Richard Cochran]

Post by Miroslav Lichvar
This one is with 100us jitter, 10ppb/s wander and 1s interval. The
best I constant now becomes impractical as it will take hours
for the servo to converge.

What clock has 100us jitter? Are you trying to model time stamp error,
like in SW time stamping?

Post by Miroslav Lichvar
I was wondering how useful it would be to have a new servo parameter
for the Allan intercept and set the P, I constants automatically
according the intercept and measured clock update interval. What do
you think?

I would like to have a table of PI constants, with one pair for each
(reasonable) sync rate. I don't think these need to be tuned to
particular oscillator characteristics, but rather just for "typical"
hardware. Most people will not know what they have and will not be
able to measure the Allan deviation of their clock.

Your simulation results are interesting. Do you propose to find PI
values for different sync rates in this way?

Thanks,
Richard

[Keller, Jacob E]

-----Original Message-----
Sent: Wednesday, April 24, 2013 11:52 AM
To: Miroslav Lichvar
Subject: Re: [Linuxptp-devel] Optimal P, I constants

Post by Miroslav Lichvar
This one is with 100us jitter, 10ppb/s wander and 1s interval. The
best I constant now becomes impractical as it will take hours
for the servo to converge.

What clock has 100us jitter? Are you trying to model time stamp error,
like in SW time stamping?

Post by Miroslav Lichvar
I was wondering how useful it would be to have a new servo

parameter

Post by Miroslav Lichvar
for the Allan intercept and set the P, I constants automatically
according the intercept and measured clock update interval. What do
you think?

I would like to have a table of PI constants, with one pair for each
(reasonable) sync rate. I don't think these need to be tuned to
particular oscillator characteristics, but rather just for "typical"
hardware. Most people will not know what they have and will not be
able to measure the Allan deviation of their clock.
Your simulation results are interesting. Do you propose to find PI
values for different sync rates in this way?
Thanks,
Richard

How difficult would it be to calculate allan deviation on the fly? If it's not possible, then definitely having some good P/I values per hardware would be good.

Miroslav: I would like to know how to measure these so that I can find optimal values for the hardware I support. Thanks.

- Jake

[Miroslav Lichvar]

Post by Keller, Jacob E
How difficult would it be to calculate allan deviation on the fly? If it's not possible, then definitely having some good P/I values per hardware would be good.

I think it's not possible to measure the deviation when the clock is
disciplined as you would have to undo the changes in the collected
offsets as if the clock was free running and that cannot be done
without knowing exactly when were the changes in the frequency applied
by the kernel. Much easier it would be to have a "learning" mode where
the clock is not touched.

Post by Keller, Jacob E
Miroslav: I would like to know how to measure these so that I can find optimal values for the hardware I support. Thanks.

See the mail I sent yesterday.

[Miroslav Lichvar]

Post by Miroslav Lichvar

Post by Keller, Jacob E
How difficult would it be to calculate allan deviation on the fly? If it's not possible, then definitely having some good P/I values per hardware would be good.

I think it's not possible to measure the deviation when the clock is
disciplined as you would have to undo the changes in the collected
offsets as if the clock was free running and that cannot be done
without knowing exactly when were the changes in the frequency applied
by the kernel.

On another thought, what matters here is the sum of the errors and
it's possible it would be close to zero and not affect the result.
There is only one way how to find out, I think it would be worth a
shot. :)

[Miroslav Lichvar]

Post by Richard Cochran

Post by Miroslav Lichvar
This one is with 100us jitter, 10ppb/s wander and 1s interval. The
best I constant now becomes impractical as it will take hours
for the servo to converge.

What clock has 100us jitter? Are you trying to model time stamp error,
like in SW time stamping?

Yes, 100 us was used to simulate a bad SW time stamping.

Post by Richard Cochran

Post by Miroslav Lichvar
I was wondering how useful it would be to have a new servo parameter
for the Allan intercept and set the P, I constants automatically
according the intercept and measured clock update interval. What do
you think?

I would like to have a table of PI constants, with one pair for each
(reasonable) sync rate. I don't think these need to be tuned to
particular oscillator characteristics, but rather just for "typical"
hardware. Most people will not know what they have and will not be
able to measure the Allan deviation of their clock.

What exactly is a typical hardware? :) I think we could create a table
with safe P, I constants for different rates. We could also check them
at runtime and print a warning or clamp them if they are in the unsafe
range.

I'd prefer if they were scaled automatically as the update rate can
change in the runtime and the user now has to pick the constants so
they are safe even with the longest expected sync interval.

Post by Richard Cochran
Your simulation results are interesting. Do you propose to find PI
values for different sync rates in this way?

I think the simulations show that the constants can be scaled
proportionally with the update rate.

Thanks,

[Richard Cochran]

Post by Miroslav Lichvar

Post by Richard Cochran
Your simulation results are interesting. Do you propose to find PI
values for different sync rates in this way?

I think the simulations show that the constants can be scaled
proportionally with the update rate.

I didn't expect that the constants may be scaled, and so a wrote a
simulator of my own (not to be compared with clknetsim, of course).

http://linuxptp.sourceforge.net/pi_const/

This program only simulates the PI controller with an ideal,
noise-free error signal. By starting out with a time offset of 100
microseconds, the program plots the step response of the servo.

First let us look at what linuxptp does today when the actual sync
rate is faster than the default of 1 Hz.

Loading Image...

The x-axis is the simulation time, and the y-axis is the output of the
servo in PPM. The red 2^0 line shows how the default constants cause
the servo to settle within the expected 15 second interval. If we just
use these same constants with an increased sync rate (2^ -1, -2, and
-3), the the servo still converges in the same interval, but with
over-steering. The faster the sync rate, the greater the overshooting.

If the actual sync rate is slower than the default of 1 Hz, then the
servo becomes unstable:

Loading Image...

So the current linuxptp behavior of applying constants tuned for a 1
Hz sync to other rates does not work very well, or not at all, unless
the user provides constants tuned to the expected sync rate.

Now let us consider scaling the constants to the sync rate.

Loading Image...

With rates over 1 Hz, the shape of convergence is improved, but you
can still see the over-steering effect. For example, the 2^-3 case
produces an initial 800 PPM adjustment for the 100 microsecond offset.

When the sync rate is slower than 1 Hz,

Loading Image...

the result appears at first glance acceptable, but any noise in the
error signal would probably spoil things.

So my conclusion is that, although automatically scaling the constants
is an improvement over blindly applying the defaults, still scaling is
not the right solution. What we really want is a set of tuned PI
constants, one for each combination of supported sync interval and
HW/SW time stamping.

As an example, compare the using the scaled defaults with using hand
tuned constants for the 2^-3 sync interval.

Loading Image...

Thoughts?

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran
So the current linuxptp behavior of applying constants tuned for a 1
Hz sync to other rates does not work very well, or not at all, unless
the user provides constants tuned to the expected sync rate.

Agreed.

Post by Richard Cochran
Now let us consider scaling the constants to the sync rate.
http://linuxptp.sourceforge.net/pi_const/plot3.png
With rates over 1 Hz, the shape of convergence is improved, but you
can still see the over-steering effect.

The shape should be identical, just scaled differently. It can be seen
better when the x axis is in clock updates instead of time.

Loading Image...

Post by Richard Cochran
For example, the 2^-3 case
produces an initial 800 PPM adjustment for the 100 microsecond offset.

That's perfectly fine, the servo running at 8Hz rate is 8 times
faster. The amount of offset corrected in one clock update is the
same.

Post by Richard Cochran
When the sync rate is slower than 1 Hz,
http://linuxptp.sourceforge.net/pi_const/plot4.png
the result appears at first glance acceptable, but any noise in the
error signal would probably spoil things.

I think the jitter should have the same effect in the different rates.

Post by Richard Cochran
So my conclusion is that, although automatically scaling the constants
is an improvement over blindly applying the defaults, still scaling is
not the right solution.

It depends on what are our requirements. To ensure stable operation
with different rates, the scaling is probably the easiest one to
implement. Another could be clamping the constants to the value of
rate in Hz.

Post by Richard Cochran
What we really want is a set of tuned PI
constants, one for each combination of supported sync interval and
HW/SW time stamping.
As an example, compare the using the scaled defaults with using hand
tuned constants for the 2^-3 sync interval.
http://linuxptp.sourceforge.net/pi_const/plot5.png

Do you want to adjust the constants with the rate so that the servo
will work similarly well with the same jitter/wander ratio?

That's what I was proposing originally, but I wanted it to be fully
configurable instead of having only two presets for a "typical" system
and SW/HW time stamping.

I think we can select one configurable constant which will be
independent from the update rate and calculate the rest from it. The
constant could still have two default values for the SW and HW
time stamping. It could be the P constant "normalized" for 1 Hz, the I
constant "normalized" for 1 Hz, the Allan intercept, jitter divided by
wander, or another arbitrary scale. The Allan intercept has an
advantage over the others that it can be seen on the Allan deviation
plot.

Thanks,

[Richard Cochran]

This post might be inappropriate. Click to display it.

[Miroslav Lichvar]

Post by Richard Cochran
When we scale the 1 Hz constant for 8 Hz, for example, the servo first
dials +800 PPM and then almost -100 PPM. Properly tuned constants

Post by Miroslav Lichvar

Post by Richard Cochran
http://linuxptp.sourceforge.net/pi_const/plot5.png

I'm not sure what I should see in the plot. The 2^0 and scaled 2^-3
curves are identical, just stretched differently. Why should be 100us
offset corrected at 100 ppm good and at 800 ppm bad? Are you
considering a situation with a typical wander?

This is similar to the PLL and its time constant. Halving the time
constant doubles the frequency adjustment. And the constant needs
to be scaled with the update interval to not become unstable.

Post by Richard Cochran

Post by Miroslav Lichvar
I think we can select one configurable constant which will be
independent from the update rate and calculate the rest from it. The
constant could still have two default values for the SW and HW
time stamping. It could be the P constant "normalized" for 1 Hz, the I
constant "normalized" for 1 Hz, the Allan intercept, jitter divided by
wander, or another arbitrary scale. The Allan intercept has an
advantage over the others that it can be seen on the Allan deviation
plot.

I still don't understand what you are proposing. Given an intercept,
how do you derive P and I?

I believe there is a formula to calculate P for given intercept and
rate. Then the I constant can be calculated from P and the rate. The
constants will need to be clamped to not become unstable (in that case
a shorter update interval would give better results). I don't know the
formulas, but I don't think it will be very difficult to figure them
out from the simulations. I just didn't want to spend much time on it
if you are opposed to the idea.

Thanks,

[Richard Cochran]

Post by Miroslav Lichvar

Post by Richard Cochran
http://linuxptp.sourceforge.net/pi_const/plot5.png

I'm not sure what I should see in the plot. The 2^0 and scaled 2^-3
curves are identical, just stretched differently. Why should be 100us
offset corrected at 100 ppm good and at 800 ppm bad? Are you
considering a situation with a typical wander?

When designing a controller, one of the factors is amount of
steering. Minimizing the magnitude of the steering is a good thing. In
the car example, it saves gas and wear on the brakes. For a clock,
time based applications prefer small frequency errors to larger ones.

In the plot, you can see that there are better choices of constants
for different sample rates than just scaling. The hand tuned constants
converge in the same time, but without inducing so much frequency
error. Finding these constants requires some analysis.

Post by Miroslav Lichvar
I believe there is a formula to calculate P for given intercept and
rate. Then the I constant can be calculated from P and the rate. The
constants will need to be clamped to not become unstable (in that case
a shorter update interval would give better results). I don't know the
formulas, but I don't think it will be very difficult to figure them
out from the simulations. I just didn't want to spend much time on it
if you are opposed to the idea.

Please go ahead and see what you come up with. I am interested to see
how you do it and what the results are. The servo parameters involve
trade offs, and so there is no one right answer. Even if the software
ends up with a tabular approach (one PI pair per sync rate), still we
can always include your results in table form.

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran
Please go ahead and see what you come up with. I am interested to see
how you do it and what the results are. The servo parameters involve
trade offs, and so there is no one right answer. Even if the software
ends up with a tabular approach (one PI pair per sync rate), still we
can always include your results in table form.

I tried to find which PI constant give the best RMS time error in the
simulation results when the jitter/wander ratio and update interval
change and run lines through the points. I guess it could be done
accurately by mathematical analysis, but that would be much more
difficult, at least for me. Similarly, it should be possible to get
constants which minimize the RMS frequency error or a combination of
the two.

Here is what I found, u is the update interval in seconds, a is the
Allan intercept in seconds and jw is the jitter/wander ratio. The
clamping constants were chosen so P+I ≈ 1/u and P*u ≈ (I*u)^0.5.

jw ≈ (a / 2)^1.5
P_min_rms_time ≈ min(10^0.2 / (u^0.3 * jw^0.5), 0.62 / u)
I_min_rms_time ≈ min(10^0.1 / (u^-0.4 * jw), 0.38 / u)

Here are calculated constants for some selected Allan intercepts and
update intervals.

u\a | 1 | 10 | 100 | 1000 |
2^+4 | 3.9e-02 2.4e-02 | 3.9e-02 2.4e-02 | 3.7e-02 1.1e-02 | 6.5e-03 3.4e-04 |
2^+3 | 7.7e-02 4.8e-02 | 7.7e-02 4.8e-02 | 4.5e-02 8.2e-03 | 8.0e-03 2.6e-04 |
2^+2 | 1.5e-01 9.5e-02 | 1.5e-01 9.5e-02 | 5.6e-02 6.2e-03 | 9.9e-03 2.0e-04 |
2^+1 | 3.1e-01 1.9e-01 | 3.1e-01 1.5e-01 | 6.8e-02 4.7e-03 | 1.2e-02 1.5e-04 |
2^-0 | 6.2e-01 3.8e-01 | 4.7e-01 1.1e-01 | 8.4e-02 3.6e-03 | 1.5e-02 1.1e-04 |
2^-1 | 1.2e+00 7.6e-01 | 5.8e-01 8.5e-02 | 1.0e-01 2.7e-03 | 1.8e-02 8.5e-05 |
2^-2 | 2.5e+00 1.5e+00 | 7.2e-01 6.5e-02 | 1.3e-01 2.0e-03 | 2.3e-02 6.5e-05 |
2^-3 | 5.0e+00 1.5e+00 | 8.8e-01 4.9e-02 | 1.6e-01 1.5e-03 | 2.8e-02 4.9e-05 |
2^-4 | 6.1e+00 1.2e+00 | 1.1e+00 3.7e-02 | 1.9e-01 1.2e-03 | 3.4e-02 3.7e-05 |

What do you think?

[Richard Cochran]

Post by Miroslav Lichvar
What do you think?

At first glance, some of the constants seem promising, especially the
a=10 column.

I wanted to finally try the clknetsim program to simulate the servo's
step response, but when I run the example phc2sys.test, the results do
not look right. I see the following in tmp/log.1.

[0.000] failed to adjust the clock: No such file or directory
[0.000] failed to set the clock status: Operation not permitted
ioctl PTP_SYS_OFFSET: Operation not permitted
[1.000] phc offset 1463 s0 freq +0 delay 0
[2.000] failed to step clock: Operation not permitted
[2.000] failed to adjust the clock: Operation not permitted
[2.000] failed to set clock status and maximum error: Operation not permitted
[2.000] phc offset -1196 s1 freq -22447 delay 0
[3.000] failed to adjust the clock: Operation not permitted
[3.000] failed to set clock status and maximum error: Operation not permitted
[3.000] phc offset -954 s2 freq -23401 delay 0
[4.000] failed to adjust the clock: Operation not permitted
[4.000] failed to set clock status and maximum error: Operation not permitted

Can you tell me what is going on here? Shouldn't the program be able
to step and adjust the simulated clock?

Thanks,
Richard

[Richard Cochran]

Post by Richard Cochran
Can you tell me what is going on here? Shouldn't the program be able
to step and adjust the simulated clock?

Never mind - it is because my glibc does not offer clock_adjtime().

Thanks,
Richard

[Richard Cochran]

Post by Richard Cochran

Post by Miroslav Lichvar
What do you think?

At first glance, some of the constants seem promising, especially the
a=10 column.

I spent some time this week reviewing how to obtain good PI servo
constants, and now I am even more convinced that the choice involves
tradeoffs that only the end user can decide.

I am going to introduce a table of constants, with one PI pair per
sync interval, but I have a few questions where I could use some
feedback.

1. What range of sync intervals should be supported? 2^-7 to 2^+7 ?

2. Should user constants appear in the config file, or should we have
a new, separate file for that?

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran
I spent some time this week reviewing how to obtain good PI servo
constants, and now I am even more convinced that the choice involves
tradeoffs that only the end user can decide.

What tradeoffs do you think the user can consider? For me, the only
things that matter are time error, frequency error and convergence
time.

Post by Richard Cochran
I am going to introduce a table of constants, with one PI pair per
sync interval, but I have a few questions where I could use some
feedback.
1. What range of sync intervals should be supported? 2^-7 to 2^+7 ?

I have no suggestion for that.

Post by Richard Cochran
2. Should user constants appear in the config file, or should we have
a new, separate file for that?

How about a list of EXP:P:I triplets separated by commas in the config?

Thanks,

[Richard Cochran]

Post by Miroslav Lichvar

Post by Richard Cochran
I spent some time this week reviewing how to obtain good PI servo
constants, and now I am even more convinced that the choice involves
tradeoffs that only the end user can decide.

What tradeoffs do you think the user can consider? For me, the only
things that matter are time error, frequency error and convergence
time.

Yes, that pretty much says it all.

Post by Miroslav Lichvar

Post by Richard Cochran
2. Should user constants appear in the config file, or should we have
a new, separate file for that?

How about a list of EXP:P:I triplets separated by commas in the config?

I was thinking something more like:

# Sync P I
pi_constant 0 0.7 0.3
pi_constant -1 0.58 0.085

In that way, a config file can personalize as much or as little of the
table as desired.

Thanks,
Richard

[Keller, Jacob E]

-----Original Message-----
Sent: Friday, May 10, 2013 10:21 AM
To: Miroslav Lichvar
Subject: Re: [Linuxptp-devel] Optimal P, I constants

Post by Miroslav Lichvar

Post by Richard Cochran
I spent some time this week reviewing how to obtain good PI servo
constants, and now I am even more convinced that the choice

involves

Post by Miroslav Lichvar

Post by Richard Cochran
tradeoffs that only the end user can decide.

What tradeoffs do you think the user can consider? For me, the only
things that matter are time error, frequency error and convergence
time.

Yes, that pretty much says it all.

Post by Miroslav Lichvar

Post by Richard Cochran
2. Should user constants appear in the config file, or should we have
a new, separate file for that?

How about a list of EXP:P:I triplets separated by commas in the config?

# Sync P I
pi_constant 0 0.7 0.3
pi_constant -1 0.58 0.085
In that way, a config file can personalize as much or as little of the
table as desired.
Thanks,
Richard

I agree with that, and we can just comment out the ones we don't select,
But if the user wants it is easy to just add the values they want.

- Jake

[Miroslav Lichvar]

Post by Richard Cochran

Post by Miroslav Lichvar

Post by Richard Cochran
2. Should user constants appear in the config file, or should we have
a new, separate file for that?

How about a list of EXP:P:I triplets separated by commas in the config?

# Sync P I
pi_constant 0 0.7 0.3
pi_constant -1 0.58 0.085
In that way, a config file can personalize as much or as little of the
table as desired.

I'd rather avoid introducing a new config file and keep everything in
the main config. There could be a new section for it.

[pi_constants]
#Sync P I
0 0.7 0.3
-1 0.52 0.085

Thanks,

[Keller, Jacob E]

-----Original Message-----
Sent: Monday, May 13, 2013 1:33 AM
To: Richard Cochran
Subject: Re: [Linuxptp-devel] Optimal P, I constants

Post by Richard Cochran

Post by Miroslav Lichvar

Post by Richard Cochran
2. Should user constants appear in the config file, or should we

have

Post by Richard Cochran

Post by Miroslav Lichvar

Post by Richard Cochran
a new, separate file for that?

How about a list of EXP:P:I triplets separated by commas in the

config?

Post by Richard Cochran
# Sync P I
pi_constant 0 0.7 0.3
pi_constant -1 0.58 0.085
In that way, a config file can personalize as much or as little of the
table as desired.

I'd rather avoid introducing a new config file and keep everything in
the main config. There could be a new section for it.

I am pretty sure Richard didn't intend these to be in a new config file.

[pi_constants]
#Sync P I
0 0.7 0.3
-1 0.52 0.085
Thanks,
--
Miroslav Lichvar

I like using the headers, though it might make sense to stick to the same format we have everywhere else in the file for consistency.

- Jake

[Richard Cochran]

Post by Miroslav Lichvar
u\a | 1 |
2^+4 | 3.9e-02 2.4e-02 |
2^+3 | 7.7e-02 4.8e-02 |
2^+2 | 1.5e-01 9.5e-02 |
2^+1 | 3.1e-01 1.9e-01 |
2^-0 | 6.2e-01 3.8e-01 |
2^-1 | 1.2e+00 7.6e-01 |
2^-2 | 2.5e+00 1.5e+00 | *
2^-3 | 5.0e+00 1.5e+00 | *
2^-4 | 6.1e+00 1.2e+00 | *
What do you think?

According to the analysis in the Eidson book, the constants marked
with * are not stable, and my simplistic servo simulator also confirms
this.

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran

Post by Miroslav Lichvar
2^-2 | 2.5e+00 1.5e+00 | *
2^-3 | 5.0e+00 1.5e+00 | *
2^-4 | 6.1e+00 1.2e+00 | *
What do you think?

According to the analysis in the Eidson book, the constants marked
with * are not stable, and my simplistic servo simulator also confirms
this.

Can you please share the code and settings that show the instability?
I see no problems with:

pi_sim -s 0.25 -p 2.5 -i 1.5
pi_sim -s 0.125 -p 5.0 -i 1.5
pi_sim -s 0.0625 -p 6.1 -i 1.2

[Richard Cochran]

Post by Miroslav Lichvar

Post by Richard Cochran
According to the analysis in the Eidson book, the constants marked
with * are not stable, and my simplistic servo simulator also confirms
this.

Can you please share the code and settings that show the instability?
pi_sim -s 0.25 -p 2.5 -i 1.5
pi_sim -s 0.125 -p 5.0 -i 1.5
pi_sim -s 0.0625 -p 6.1 -i 1.2

Yes, you are right, I neglected the -s setting.

I am beginning to think that there is an error in Eidson's analysis,
because I noticed another unexpected detail regarding the estimated
settling time.

For now, we can leave off any limits on the user PI constants. My
focus now is to generate a set of reasonable defaults.

Thanks,
Richard

[Richard Cochran]

Post by Miroslav Lichvar
Here is what I found, u is the update interval in seconds, a is the
Allan intercept in seconds and jw is the jitter/wander ratio. The
clamping constants were chosen so P+I ≈ 1/u and P*u ≈ (I*u)^0.5.
jw ≈ (a / 2)^1.5
P_min_rms_time ≈ min(10^0.2 / (u^0.3 * jw^0.5), 0.62 / u)
I_min_rms_time ≈ min(10^0.1 / (u^-0.4 * jw), 0.38 / u)

I have taken Miroslav's formulae, tweaked them a bit, ran some
simulations and actual experiments, and I suggest using the
following method to calculate default PI constants.

Kp = (.8) * u^-.5 , u <= 1
Ki = (.2) * u^.5 , u <= 1
Kp = (.7) / u , u > 1
Ki = (.38) / u , u > 1

As before, the simulations are the step response, but this time to a
100 PPM frequency error. The resulting graphs end up the same shape as
in a classical step response. I divided the simulations between those
with a sync period less than or equal to one second, and those greater
than. In each case, I compared Miroslav's constants (with a=10),
called method A, with my tweaked formulae, called method B.

http://linuxptp.sourceforge.net/pi_calc_plots/

Without discussing the graphs in detail, in general one can say that
the two sets of constants yield very similar results, with method B
resulting in lower RMS error.

| file | description |
|---------------+--------------------|
| neg_plot1.png | Sync period = 2^0 |
| neg_plot2.png | 2^-1 |
| ... | |
| neg_plot8.png | 2^-7 |
|---------------+--------------------|
| pos_plot1.png | 2^1 |
| ... | |
| pos_plot7.png | 2^7 |
|---------------+--------------------|

More interesting perhaps are the log capture files, creating on a PTP
slave running on the M5234BCC using the phyter, with the OMTC 100
master clock. The two were connected via an ordinary Linksys
switch. For these tests, method B appears a bit nicer during the
initial convergence, but otherwise the performance was much the same.

|---------------+--------------------|
| cap_plot1.png | Sync period = 2^0 |
| cap_plot3.png | 2^-1 |
| cap_plot4.png | 2^-2 |
| cap_plot5.png | 2^-3 |
| cap_plot6.png | 2^-4 |
| cap_plot7.png | 2^-5 |
|---------------+--------------------|

I repeated just two cases, directly connecting the BCC to the OMTC
with an Ethernet cable. In the 2^0 case, both the A and B runs
suffered from an initial bad, negative path delay estimate. In the
2^-5 case, it is interesting to note the extremely low RMS error
(under 10) and the little bumps around time 40 and time 55 seconds.

| cap_plot2.png | Sync period = 2^0 |
| cap_plot8.png | 2^-5 |

I put the scripts, logs, and programs under:

http://linuxptp.sourceforge.net/pi_calc/

Miroslav, would you mind testing the tweaked constants in your
clknetsim environment?

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran
http://linuxptp.sourceforge.net/pi_calc_plots/
Without discussing the graphs in detail, in general one can say that
the two sets of constants yield very similar results, with method B
resulting in lower RMS error.

It seems the cap plots are created from the RMS offsets reported by
ptp4l, which include the jitter. Even if the reported RMS offsets
are similar with both methods, the actual accuracy could be
significantly better with one method. Unfortunately that information
is hidden in the noise. To evaluate the accuracy of the clock
controlled by the servo, more accurate measurements are needed than
the measurements feeded to the servo. This is where simulations are
very useful.

[Miroslav Lichvar]

Ok, I've run simulations with the two methods with different update
intervals and jitter/wander ratios, and compared the pairs of the RMS
time error and frequency error. The differences are in dB (20*log10).
u\jw | 1e0 | 1e1 | 1e2 | 1e3 |
2^-7 | -24 -18 | -30 -29 | -35 -40 | -32 -41 |
2^-6 | -20 -14 | -25 -24 | -31 -35 | -33 -42 |
2^-5 | -15 -8 | -21 -19 | -26 -29 | -30 -39 |
2^-4 | -10 -2 | -15 -13 | -20 -23 | -24 -33 |
2^-3 | -6 3 | -10 -7 | -15 -17 | -20 -28 |
2^-2 | -3 7 | -5 -3 | -11 -13 | -16 -24 |
2^-1 | -2 5 | -2 -2 | -7 -13 | -12 -24 |
2^+0 | -1 0 | -2 -5 | -7 -17 | -13 -28 |
2^+1 | 0 0 | -0 -1 | -6 -13 | -11 -24 |
2^+2 | 1 0 | 0 -1 | -3 -8 | -9 -20 |
2^+3 | 1 0 | 0 0 | -1 -2 | -6 -15 |
2^+4 | 1 0 | 0 0 | 0 -1 | -4 -10 |
2^+5 | 1 0 | 1 0 | 1 -0 | -1 -4 |
2^+6 | 1 0 | 1 0 | 1 0 | 0 -1 |
2^+7 | 0 0 | 1 0 | 1 0 | 0 -0 |

And the following table is for the constants used with software time
stamping from the "[PATCH RFC 3/6] Add a table of PI constants, with
one entry per sync interval." patch.

u\jw | 1e0 | 1e1 | 1e2 | 1e3 |
2^-7 | -41 -12 | -40 -16 | -19 -0 | -43 -30 |
2^-6 | -27 2 | -20 4 | -20 -0 | -26 -13 |
2^-5 | -31 -1 | -19 6 | -12 8 | -18 -2 |
2^-4 | -31 -0 | -17 9 | -8 12 | -11 4 |
2^-3 | -32 1 | -18 8 | -5 14 | -6 6 |
2^-2 | -33 2 | -19 8 | -5 12 | -2 3 |
2^-1 | -33 -0 | -19 9 | -5 9 | -1 -1 |
2^+0 | -32 -2 | -19 9 | -5 5 | -1 -6 |
2^+1 | -34 -5 | -26 5 | -12 8 | -1 -2 |
2^+2 | -34 -6 | -31 -2 | -18 9 | -5 3 |
2^+3 | -34 -6 | -34 -5 | -25 6 | -11 7 |
2^+4 | -34 -7 | -34 -6 | -31 -0 | -17 8 |
2^+5 | -34 -6 | -33 -6 | -33 -5 | -23 6 |
2^+6 | -34 -7 | -34 -7 | -33 -6 | -30 1 |
2^+7 | -34 -7 | -34 -7 | -34 -6 | -33 -4 |

[Richard Cochran]

Post by Miroslav Lichvar
It seems the cap plots are created from the RMS offsets reported by
ptp4l, which include the jitter. Even if the reported RMS offsets
are similar with both methods, the actual accuracy could be
significantly better with one method. Unfortunately that information
is hidden in the noise. To evaluate the accuracy of the clock
controlled by the servo, more accurate measurements are needed than
the measurements feeded to the servo. This is where simulations are
very useful.

Right, so after seeing your simulation results, I am going to try and
validate them using an actual PPS.

BTW, do you have a test setup to measure this yourself? If so, please
do tell us what you find.

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran
Right, so after seeing your simulation results, I am going to try and
validate them using an actual PPS.

Great, I'm looking forward to see your results.

Post by Richard Cochran
BTW, do you have a test setup to measure this yourself? If so, please
do tell us what you find.

I don't have a setup to do that. Beside measuring the accuracy of the
PTP clock, I'd like to be able to do it also with the system clock. I
wish there was a way of getting the TSC as a pulse signal directly
from the CPU.

Thanks,

[Richard Cochran]

Post by Miroslav Lichvar

Post by Richard Cochran
Right, so after seeing your simulation results, I am going to try and
validate them using an actual PPS.

Great, I'm looking forward to see your results.

First results are in:

http://linuxptp.sourceforge.net/igb-master_bcc-slave_pps/

- plot1.png Initial convergence at Sync 2^0
- plot2.png Initial convergence at Sync 2^-4
- plot3.png Steady state at Sync 2^0
- plot4.png Steady state at Sync 2^-4

For this test, I used the m5234bcc (phyter) as a slave to the Intel
i210 card. The 1 PPS from the i210 was time stamped by the phyter.
You can see a static offset of 400 nanoseconds, due to path
asymmetry. Overall, method B is looking better, but that is just my
impression, and I haven't really quantified that impression.

I hope to repeat the test today, with the roles reversed.

Thanks,
Richard

[Richard Cochran]

Post by Richard Cochran

Post by Miroslav Lichvar

Post by Richard Cochran
Right, so after seeing your simulation results, I am going to try and
validate them using an actual PPS.

Great, I'm looking forward to see your results.

http://linuxptp.sourceforge.net/igb-master_bcc-slave_pps/

And here is how the tests were conducted. The bcc was directly
connected to the i210 by a short Ethernet cable. The script on the bcc
(slave) looks like:

testptp.m68k -f 0
testptp.m68k -s
# NB: system time on the bcc starts at value zero
testptp.m68k -e 600 &
ptp4l.m68k -f config

and the config file had the set of constants to try:

# method A at 2^0
pi_proportional_const 0.47
pi_integral_const 0.11
# method B at 2^0
# pi_proportional_const 0.8
# pi_integral_const 0.2
# method A at 2^-4
# pi_proportional_const 1.1
# pi_integral_const 0.037
# method B at 2^-4
# pi_proportional_const 3.2
# pi_integral_const 0.05

Thanks,
Richard

[Miroslav Lichvar]

Post by Richard Cochran

Post by Richard Cochran
http://linuxptp.sourceforge.net/igb-master_bcc-slave_pps/

Very interesting, thank you for doing this.

Is there any specification on the accuracy of the generated PPS signal
and the accuracy of the PPS capture? Could be the PPS rate increased?

I'd expect the jitter in the PPS offsets to be smaller than in the
offsets measured by ptp4l, which doesn't seem happen here. An
explanation for that could be that most of the error is the clock
instability, i.e. the Allan intercept is extremely short. This could
be on the master or the slave or both.

Could you please try running the test again with a very short sync
interval (-7?), free_running enabled and summary_interval set to the
sync interval, so we can see the measured offsets and try to estimate
the jitter and wander?

Post by Richard Cochran
# method B at 2^-4
# pi_proportional_const 3.2
# pi_integral_const 0.05

Hm, doesn't the method B give at 2^-4 kp=0.2 and ki=0.8?

Thanks,

[Miroslav Lichvar]

Post by Miroslav Lichvar

Post by Richard Cochran
# method B at 2^-4
# pi_proportional_const 3.2
# pi_integral_const 0.05

Hm, doesn't the method B give at 2^-4 kp=0.2 and ki=0.8?

Well, it doesn't. It seems I was using a wrong formula for the method
B the whole time. I had not noticed it was written with multiplication
instead of division. The previous comparisons I made are invalid, I'm
sorry.

When I use the correct (hopefully) formula, the difference is much
less dramatic. This comparison is with the original method A (with jw
set correctly) vs the original method B (which doesn't have a jw
parameter).

u\jw | 1e0 | 1e1 | 1e2 | 1e3 |
2^-7 | -1 -2 | -4 -13 | -10 -23 | -14 -33 |
2^-6 | -2 -1 | -4 -11 | -8 -22 | -13 -31 |
2^-5 | -1 0 | -3 -10 | -8 -20 | -14 -30 |
2^-4 | -2 2 | -3 -9 | -8 -19 | -13 -29 |
2^-3 | -2 4 | -2 -8 | -7 -18 | -12 -28 |
2^-2 | -2 5 | -2 -7 | -7 -18 | -12 -28 |
2^-1 | -2 4 | -2 -6 | -7 -17 | -12 -27 |
2^+0 | -1 0 | -2 -5 | -7 -17 | -13 -28 |
2^+1 | 0 0 | -0 -1 | -6 -13 | -11 -24 |
2^+2 | 1 0 | 0 -1 | -3 -8 | -9 -20 |
2^+3 | 1 0 | 0 0 | -1 -3 | -6 -15 |
2^+4 | 0 0 | 1 0 | 0 -1 | -4 -10 |
2^+5 | 0 0 | 1 0 | 0 -0 | -1 -4 |
2^+6 | 0 0 | 1 0 | 1 0 | 0 -1 |
2^+7 | 1 0 | 0 0 | 1 0 | 0 -0 |

Now, as I'm writing the patch for the extended servo configuration,
I'm looking for some defaults I could put into it. The most imporant
difference between the method A and B is in the exponents. If I set
the scale and the limiting coefficients identically and in such a way
that it gives the same defaults with 1 sec interval as the current HW
time stamping default, this is what I get.

method A':
kp = min(0.7 * u^-0.3, 0.7/u)
ki = min(0.3 * u^0.4, 0.3/u)

method B':
kp = min(0.7 * u^-0.5, 0.7/u)
ki = min(0.3 * u^0.5, 0.3/u)

u\jw | 1e0 | 1e1 | 1e2 | 1e3 |
2^-7 | -0 -8 | -3 -8 | -3 -8 | -2 -8 |
2^-6 | -0 -7 | -2 -7 | -2 -7 | -2 -7 |
2^-5 | 0 -6 | -2 -6 | -1 -6 | -1 -6 |
2^-4 | 0 -4 | -1 -5 | -1 -5 | -1 -5 |
2^-3 | 0 -3 | -1 -3 | -1 -3 | -1 -3 |
2^-2 | 1 -2 | -0 -2 | -0 -2 | -0 -2 |
2^-1 | 0 -1 | -0 -1 | -0 -1 | -0 -1 |
2^+0 | -0 -0 | -0 -0 | -0 -0 | -0 0 |
2^+1 | 0 0 | 0 -0 | 0 0 | 0 0 |
2^+2 | -0 -0 | 0 0 | -0 0 | -0 0 |
2^+3 | 0 -0 | -0 -0 | 0 0 | 0 0 |
2^+4 | -0 0 | -0 0 | 0 0 | 0 0 |
2^+5 | -0 -0 | 0 0 | -0 0 | 0 0 |
2^+6 | 0 0 | -0 0 | -0 -0 | -0 -0 |
2^+7 | -0 0 | -0 -0 | -0 -0 | -0 -0 |

The difference is small, but it seems the -0.3 and 0.4 exponents are
slighly better in minimizing both time error and frequency error. The
limiting coefficients could be increased to allow more aggresive
setting with longer intervals and reduce the error, but I think we can
focus on that later.

Thanks,

[Richard Cochran]

Post by Miroslav Lichvar

Post by Miroslav Lichvar

Post by Richard Cochran
# method B at 2^-4
# pi_proportional_const 3.2
# pi_integral_const 0.05

Hm, doesn't the method B give at 2^-4 kp=0.2 and ki=0.8?

Well, it doesn't. It seems I was using a wrong formula for the method
B the whole time. I had not noticed it was written with multiplication
instead of division. The previous comparisons I made are invalid, I'm
sorry.

That is quite alright, we will slowly get to a good result...

I had meant to reply about the method B and also post a bunch of
new measurements I made, but I just couldn't find the time.

I will post them and also try out you new patch, hopefully soon.

Thanks,
Richard