Thread: Re: [Linuxptp-devel] Optimal P, I constants (Page 2)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-devel
|
From: Richard C. <ric...@gm...> - 2013-05-10 08:41:29
|
On Sun, May 05, 2013 at 03:14:21PM +0200, Richard Cochran wrote: > On Fri, May 03, 2013 at 06:17:41PM +0200, Miroslav Lichvar wrote: > > > > 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 |
|
From: Miroslav L. <mli...@re...> - 2013-05-10 15:23:03
|
On Fri, May 10, 2013 at 04:23:21PM +0200, Richard Cochran wrote: > On Fri, May 03, 2013 at 06:17:41PM +0200, Miroslav Lichvar wrote: > > 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 -- Miroslav Lichvar |
|
From: Richard C. <ric...@gm...> - 2013-05-10 17:06:51
|
On Fri, May 10, 2013 at 05:00:17PM +0200, Miroslav Lichvar wrote: > On Fri, May 10, 2013 at 04:23:21PM +0200, Richard Cochran wrote: > > > > 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 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 |
|
From: Miroslav L. <mli...@re...> - 2013-05-22 10:51:47
|
On Mon, May 13, 2013 at 08:47:28PM +0200, Richard Cochran wrote: > 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. >From the plots I can see that the method B does give better looking responses to frequency/time steps than the method A, but I'm afraid it comes at a cost of reduced accuracy when the servo is converged. > Miroslav, would you mind testing the tweaked constants in your > clknetsim environment? 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 | >From the results it seems there is an area in the first column where the method B is better in the frequency error, but overall it seems to perform significantly worse in both time error and frequency error. Here are some plots of the time and frequency error in time for the 2^-4/1e1 simulation. You can see the red line (method A) is below the simulated jitter, filtering the noise well, but still fast enough to keep up with the wander. The green line is within the jitter level, but doesn't seem very stable. http://mlichvar.fedorapeople.org/clknetsim/ptp/pi_diff/pi_diff_time.png http://mlichvar.fedorapeople.org/clknetsim/ptp/pi_diff/pi_diff_freq.png The scripts are available here: http://mlichvar.fedorapeople.org/clknetsim/ptp/pi_diff/ Thanks, -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2013-05-22 13:37:25
|
On Wed, May 22, 2013 at 12:51:37PM +0200, Miroslav Lichvar wrote: > On Mon, May 13, 2013 at 08:47:28PM +0200, Richard Cochran wrote: > 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 | -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2013-04-25 11:24:07
|
On Wed, Apr 24, 2013 at 08:07:47PM +0000, Keller, Jacob E wrote: > 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. > > 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. From the offsets printed by phc2sys or ptp4l (configured to not adjust the clock) you can get the Allan deviation plot. -- Miroslav Lichvar |
|
From: Miroslav L. <mli...@re...> - 2013-04-25 12:33:17
|
On Thu, Apr 25, 2013 at 01:20:01PM +0200, Miroslav Lichvar wrote: > On Wed, Apr 24, 2013 at 08:07:47PM +0000, Keller, Jacob E wrote: > > 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 |
|
From: Richard C. <ric...@gm...> - 2013-05-05 13:14:39
|
On Fri, May 03, 2013 at 06:17:41PM +0200, Miroslav Lichvar wrote: > > 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 |
|
From: Richard C. <ric...@gm...> - 2013-05-05 14:49:42
|
On Sun, May 05, 2013 at 03:14:21PM +0200, Richard Cochran wrote: > > 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 |
|
From: Richard C. <ric...@gm...> - 2013-05-10 14:23:35
|
On Fri, May 03, 2013 at 06:17:41PM +0200, Miroslav Lichvar wrote: > > 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 |
|
From: Richard C. <ric...@gm...> - 2013-05-13 18:47:48
|
On Fri, May 03, 2013 at 06:17:41PM +0200, Miroslav Lichvar wrote: > > 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X