Tighter regulation?

[Mischanko, Edward T]

Hello friends,

Does anyone know what setting can be changed that will cause
tighter regulation of the offset. My goal is to get clk_wander to
equal as close to zero as possible more often. I would also like
to see the frequency adjusted with every change in offset data;
it currently does not appear to do that; it seems to be random.
I am monitoring a Windows XP client.

Regards,
Ed

[David Taylor]

Ed, does reducing maxpoll help? That's assuming it doesn't contravene
the terms of use of the server, of course. Does adding more servers help?
--
Cheers,
David
Web: http://www.satsignal.eu

[David Woolley]

Mischanko, Edward T wrote:

> Does anyone know what setting can be changed that will cause
> tighter regulation of the offset. My goal is to get clk_wander to

Why do you want to track network propagation delay changes, at the
expense of accurate time keeping?

> equal as close to zero as possible more often. I would also like
> to see the frequency adjusted with every change in offset data;
> it currently does not appear to do that; it seems to be random.

I think you are seeing the effects of the 8 stage minimum delay filter.
Defeating this is likely to increase jitter against true time, as it
will cause the frequency to be adjusted based on low quality measurement
samples, increasing the variability of the frequency.

Note that the time constants for the frequency adjustment loops are
significantly larger than 8 times the sample interval.

[Mischanko, Edward T]

David,

The particular client I am monitoring is on an extremely stable corporate
LAN. The servers are on the same LAN. Changes in network propagation
are minimal.

The 8 stage minimum delay filter is exactly what I am seeing and exactly
what I would like to disable. When polling above 256 seconds the amount
of time it takes to make an adjustment is excessive. Setting maxpoll to
8 does help, but that defeats what server administrators like to have to
reduce loading, on a grand scheme.

I am not sure what jitter will do, but what good is low jitter at the
expense of poor offset correction?

Regards,
Ed

> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions

[Mischanko, Edward T]

Hello David Taylor,

Yes, reducing maxpoll does help. The expense to the network is minimal
for my one client. But, what if everybody in the whole world did that
to get better regulation? I am trying to learn of possible tweeks in the code to better the program as a whole.

Regards,
Ed

> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelorm...@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelorm...@lists.ntp.org] On Behalf Of
> David Taylor
> Sent: Monday, May 20, 2013 4:07 AM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>

[David Woolley]

Mischanko, Edward T wrote:>
> The particular client I am monitoring is on an extremely stable corporate
> LAN. The servers are on the same LAN. Changes in network propagation
> are minimal.

On the other hand, it is on Windows, which doesn't have very stable time
measurement.

>
> The 8 stage minimum delay filter is exactly what I am seeing and exactly
> what I would like to disable. When polling above 256 seconds the amount
> of time it takes to make an adjustment is excessive. Setting maxpoll to
> 8 does help, but that defeats what server administrators like to have to
> reduce loading, on a grand scheme.

Defeating this will not have a large effect if you really do have very
consistent measurement errors, as the polling over samples compared with
the needs of the loop filter. If measurement errors are variable, it
will degrade the performance.

>
> I am not sure what jitter will do, but what good is low jitter at the
> expense of poor offset correction?
>

Increased jitter means that your offset measurements span a wider range
of values.

I think you need to provide:

1) a tabulation of the raw offset values, including signs;
2) an analysis of the breakdown of errors between the crystal frequency,
Windows load related errors, and network load related error.

It is important to understand that offset is time error + measurement
error, and in the steady state, measurement error will be the dominant
component.

[David Woolley]

David Woolley wrote:

> Mischanko, Edward T wrote:>

> 2) an analysis of the breakdown of errors between the crystal frequency,
> Windows load related errors, and network load related error.

In particular, unless your main error source is changes in crystal
frequency, in which case the best approach is to improve the thermal
regulation of the environment, even though changes may appear to reduce
the offset, they are unlikely to improve the timekeeping.

[unruh]

On 2013-05-20, Mischanko, Edward T <Edward.M...@arcelormittal.com> wrote:
> Hello friends,
>
> Does anyone know what setting can be changed that will cause
> tighter regulation of the offset. My goal is to get clk_wander to
> equal as close to zero as possible more often. I would also like
> to see the frequency adjusted with every change in offset data;
> it currently does not appear to do that; it seems to be random.

you need to read Mill's book.
a) ntpd uses only that meas of the last 8 that has smallest delay.-- ie
about 7 of every 8 meas are thewn away.That increases the time between
effective meas by a factor of about 8,
This is to handle the network jitter problem, and not knowing f the deay
is inbound or outbound. To get around thic decrease the poll interval.
(eg 10 to 7).
b) To bensure stability only a small fraction of the offset is sed to
alter the discipation.

[unruh]

On 2013-05-20, David Woolley <da...@ex.djwhome.demon.invalid> wrote:
> Mischanko, Edward T wrote:
>
>> Does anyone know what setting can be changed that will cause
>> tighter regulation of the offset. My goal is to get clk_wander to
>
> Why do you want to track network propagation delay changes, at the
> expense of accurate time keeping?
>
>> equal as close to zero as possible more often. I would also like
>> to see the frequency adjusted with every change in offset data;
>> it currently does not appear to do that; it seems to be random.
>
> I think you are seeing the effects of the 8 stage minimum delay filter.
> Defeating this is likely to increase jitter against true time, as it
> will cause the frequency to be adjusted based on low quality measurement
> samples, increasing the variability of the frequency.

Well if the prop delays were wildly varying, the network jitter can be
small, and ntpd will still throw out 7 of 8.

[unruh]

On 2013-05-20, unruh <un...@invalid.ca> wrote:
> On 2013-05-20, David Woolley <da...@ex.djwhome.demon.invalid> wrote:
>> Mischanko, Edward T wrote:
>>
>>> Does anyone know what setting can be changed that will cause
>>> tighter regulation of the offset. My goal is to get clk_wander to
>>
>> Why do you want to track network propagation delay changes, at the
>> expense of accurate time keeping?
>>
>>> equal as close to zero as possible more often. I would also like
>>> to see the frequency adjusted with every change in offset data;
>>> it currently does not appear to do that; it seems to be random.
>>
>> I think you are seeing the effects of the 8 stage minimum delay filter.
>> Defeating this is likely to increase jitter against true time, as it
>> will cause the frequency to be adjusted based on low quality measurement
>> samples, increasing the variability of the frequency.
>
> Well if the prop delays were wildly varying, the network jitter can be
> small, and ntpd will still throw out 7 of 8.

The grammer of that sentence is impossible. What I meant was:
Well, that is correct if the propagation delays were varying wildly.
However, the network jitter can be small, and ntpd will still throw out
about 7 of 8 (the lest delay of the last 8 measurements), wasting a
precious resource-- measurements.

[Mischanko, Edward T]

Below is my loopstats file:

56432 37096.090 0.000000000 0.854 0.000001907 0.000000 5
56432 37193.357 -0.000498569 0.854 0.000176280 0.000000 5
56432 37356.388 -0.000635872 0.459 0.000171892 0.139789 5
56432 37581.427 -0.000141746 0.337 0.000237431 0.137653 5
56432 37587.427 0.000378025 0.346 0.000288265 0.128799 5
56432 37648.439 0.000090557 0.367 0.000288166 0.120711 5
56432 37681.446 0.000138788 0.384 0.000270093 0.113084 5
56432 37878.483 0.000253057 0.574 0.000255859 0.125340 6
56432 37980.503 0.000310133 0.604 0.000240183 0.117729 6
56432 37981.503 0.000062108 0.605 0.000241178 0.110125 6
56432 38181.541 0.000267599 0.656 0.000237011 0.104581 6
56432 38288.562 0.000076744 0.663 0.000231745 0.097866 6
56432 38487.600 0.000248682 0.711 0.000225139 0.093054 6
56432 38622.626 0.000181529 0.734 0.000211933 0.087435 7
56432 38667.636 0.000235950 0.737 0.000199176 0.081793 7
56432 38922.683 0.000130787 0.744 0.000189986 0.076562 7
56432 39022.703 0.000062301 0.746 0.000179358 0.071619 7
56432 39055.709 0.000129679 0.747 0.000169457 0.066994 7
56432 39321.759 0.000117023 0.754 0.000158575 0.062722 8
56432 39436.783 0.000060368 0.755 0.000149680 0.058672 8
56432 39701.839 0.000108307 0.757 0.000141035 0.054886 8
56432 39960.882 0.000098390 0.758 0.000131973 0.051344 8
56432 39992.889 0.000273934 0.759 0.000138172 0.048028 8
56432 40232.939 0.000179768 0.761 0.000133468 0.044935 8
56432 40793.041 0.000068011 0.763 0.000130951 0.042041 8
56432 41042.088 0.000315023 0.768 0.000150438 0.039360 8
56432 42105.292 0.000402223 0.794 0.000144059 0.037905 8
56432 42270.323 0.000482797 0.798 0.000137733 0.035496 8
56432 42530.373 0.000426830 0.805 0.000130348 0.033286 8
56432 42899.444 0.000269420 0.811 0.000134030 0.031206 8
56432 43161.497 0.000508422 0.819 0.000151191 0.029326 8
56432 43399.549 0.000251643 0.822 0.000168058 0.027461 8
56432 43694.611 0.000307997 0.828 0.000158461 0.025758 8
56432 44118.677 0.000434851 0.839 0.000154863 0.024406 8
56432 44220.697 0.000252018 0.840 0.000158629 0.022836 8
56432 44488.749 0.000447339 0.847 0.000163666 0.021510 8
56432 44673.784 0.000480608 0.853 0.000153547 0.020208 8
56432 44912.831 0.000409715 0.859 0.000145801 0.019015 8
56432 45015.969 0.000430309 0.861 0.000136578 0.017812 8
56432 45213.888 -0.000196347 0.859 0.000255752 0.016681 8
56432 45966.031 0.000035297 0.860 0.000252864 0.015614 8
56432 46058.049 0.000027214 0.861 0.000236550 0.014606 8
56432 46327.101 0.000361439 0.866 0.000250848 0.013815 8
56432 46522.137 0.000271551 0.870 0.000236789 0.012971 8
56432 46782.191 0.000165535 0.872 0.000224645 0.012167 8
56432 47140.257 0.000416501 0.881 0.000228101 0.011807 8
56432 47387.303 0.000423688 0.887 0.000213384 0.011262 8
56432 47651.354 0.000353615 0.893 0.000201134 0.010717 8
56432 48099.439 0.000226026 0.899 0.000193476 0.010250 8
56432 48178.455 0.000221129 0.900 0.000180989 0.009595 8
56432 48466.510 0.000226354 0.904 0.000169309 0.009080 8
56432 48892.591 0.000153276 0.908 0.000160468 0.008604 8
56432 49155.642 -0.000035150 0.907 0.000164223 0.008051 8
56432 49411.691 -0.000094805 0.906 0.000155058 0.007548 8
56432 49533.714 0.000134980 0.907 0.000166246 0.007069 8
56432 49673.741 0.000094168 0.907 0.000156177 0.006618 8
56432 49868.778 0.000137419 0.909 0.000146888 0.006217 8
56432 50216.845 0.000273504 0.915 0.000145582 0.006151 8
56432 50582.917 0.000164664 0.918 0.000141512 0.005892 8
56432 50854.967 0.000159718 0.921 0.000132384 0.005587 8
56432 50870.974 0.000029843 0.921 0.000132073 0.005227 8
56432 51124.019 -0.000040755 0.920 0.000126039 0.004894 8
56432 51408.074 0.000281570 0.925 0.000163972 0.004878 8
56432 51657.121 0.000271494 0.929 0.000153423 0.004780 8
56432 52077.201 0.000375792 0.939 0.000148176 0.005573 8
56432 52210.226 0.000174071 0.940 0.000155878 0.005236 8
56432 52337.251 0.000309136 0.942 0.000153431 0.004967 8
56432 52601.301 0.000078924 0.944 0.000164994 0.004667 8
56432 52867.352 0.000372073 0.949 0.000185909 0.004838 8
56432 53136.404 0.000269549 0.954 0.000177640 0.004777 8
56432 53504.474 0.000191223 0.958 0.000168458 0.004708 8
56432 53696.513 0.000163946 0.960 0.000157873 0.004453 8
56432 53949.560 0.000075452 0.961 0.000150955 0.004185 8
56432 54229.613 0.000146821 0.963 0.000143442 0.004010 8
56432 54456.656 0.000098193 0.965 0.000135275 0.003780 8
56432 54718.706 0.000171201 0.967 0.000129144 0.003660 8
56432 54986.758 0.000151420 0.970 0.000121005 0.003529 8
56432 55257.810 0.000102694 0.971 0.000114494 0.003353 8
56432 55524.861 0.000183851 0.974 0.000110876 0.003302 8
56432 55788.912 0.000036062 0.975 0.000116133 0.003095 8
56432 56170.985 0.000172002 0.979 0.000118790 0.003210 8
56432 56260.002 0.000093597 0.979 0.000114523 0.003007 8
56432 56578.062 0.000242474 0.984 0.000119359 0.003249 8
56432 56791.104 0.000306552 0.988 0.000113926 0.003336 8
56432 56877.120 0.000193506 0.989 0.000113816 0.003140 8
56432 57146.172 0.000234188 0.993 0.000107433 0.003223 8
56432 57221.187 0.000108180 0.993 0.000109926 0.003020 8
56432 57503.240 0.000023851 0.993 0.000107062 0.002829 8
56432 57689.275 0.000067595 0.994 0.000101334 0.002659 8
56432 57960.329 0.000094838 0.996 0.000095278 0.002546 8
56432 58308.399 0.000032919 0.996 0.000091773 0.002393 8
56432 58725.476 0.000078545 0.998 0.000087349 0.002343 8
56432 58758.486 -0.000108934 0.998 0.000105212 0.002193 8
56432 58850.502 0.000103938 0.999 0.000123896 0.002061 8
56432 59090.544 0.000068852 1.000 0.000116556 0.001959 8
56432 59451.613 0.000138397 1.003 0.000111766 0.002114 8
56432 59616.645 0.000243010 1.005 0.000110897 0.002150 8
56432 59905.707 0.000123906 1.007 0.000111956 0.002148 8
56432 59974.713 0.000208974 1.008 0.000108959 0.002032 8
56432 60239.764 -0.000063145 1.007 0.000140157 0.001933 8
56432 60370.789 0.000176644 1.008 0.000156128 0.001873 8
56432 60610.836 -0.000067311 1.008 0.000169612 0.001785 8
56432 60988.907 -0.000036894 1.007 0.000159022 0.001695 8
56432 60995.907 -0.000086594 1.007 0.000149785 0.001586 8
56432 61263.959 -0.000262981 1.002 0.000153363 0.002099 8
56432 61480.003 -0.000089409 1.001 0.000156032 0.002005 8
56432 61879.079 0.000079005 1.003 0.000157633 0.001990 8
56432 62280.154 0.000254030 1.009 0.000159911 0.002841 8
56432 62514.199 0.000281317 1.013 0.000149894 0.002998 8
56432 62544.205 0.000337373 1.014 0.000141606 0.002813 8
56432 62776.249 0.000108926 1.015 0.000155143 0.002684 8
56432 63111.314 0.000198659 1.019 0.000148550 0.002876 8
56432 63380.365 0.000249795 1.023 0.000140127 0.003040 8
56432 63516.392 0.000279201 1.026 0.000131488 0.002954 8
56432 63905.466 0.000313190 1.033 0.000123582 0.003772 8
56432 64169.515 0.000089569 1.034 0.000140051 0.003563 8
56432 64345.550 0.000043873 1.035 0.000131998 0.003337 8
56432 64526.584 0.000242494 1.037 0.000142045 0.003256 8
56432 64797.637 0.000181295 1.040 0.000134621 0.003217 8
56432 65069.688 0.000041171 1.041 0.000135321 0.003018 8
56432 65237.720 0.000143173 1.042 0.000131618 0.002868 8
56432 65427.760 0.000073796 1.043 0.000125537 0.002699 8
56432 65695.808 -0.000049883 1.042 0.000125306 0.002541 8
56432 66138.894 -0.000027577 1.042 0.000117478 0.002391 8
56432 66561.975 -0.000074307 1.040 0.000111126 0.002332 8
56432 66767.014 0.000201777 1.042 0.000142594 0.002349 8
56432 67036.065 0.000108803 1.044 0.000137376 0.002282 8
56432 67190.094 0.000071266 1.045 0.000129187 0.002148 8
56432 67327.121 0.000168563 1.046 0.000125644 0.002067 8
56432 67451.146 0.000073987 1.047 0.000122193 0.001943 8
56432 67873.229 0.000000610 1.047 0.000117208 0.001818 8
56432 68116.273 -0.000054530 1.046 0.000111358 0.001723 8
56432 68258.299 -0.000025311 1.046 0.000104677 0.001613 8
56432 68447.338 -0.000010120 1.045 0.000098063 0.001510 8
56432 68679.401 -0.000015061 1.045 0.000091747 0.001414 8
56432 68905.496 0.000075256 1.046 0.000091569 0.001371 8
56432 69053.451 -0.000085121 1.045 0.000102723 0.001309 8
56432 69251.489 -0.000180278 1.043 0.000101808 0.001437 8
56432 69384.514 0.000327300 1.046 0.000203159 0.001628 8
56432 69580.553 0.000425407 1.051 0.000193178 0.002325 8
56432 69642.564 -0.000372410 1.050 0.000334988 0.002229 8
56432 70016.642 0.000444227 1.059 0.000426089 0.004075 8
56432 70207.672 0.000379089 1.064 0.000399235 0.004106 8
56432 70385.706 0.000766143 1.072 0.000397732 0.004797 8
56432 70591.746 0.000455990 1.077 0.000387868 0.004904 8
56432 70765.785 0.000414332 1.082 0.000363116 0.004832 8
56432 71068.837 0.000174693 1.085 0.000350071 0.004656 8
56432 71330.936 -0.000098945 1.083 0.000341454 0.004389 8
56432 71547.932 -0.000086786 1.082 0.000319430 0.004125 8
56432 71789.978 0.000146704 1.084 0.000309993 0.003930 8
56432 72093.034 -0.000201535 1.081 0.000315028 0.003895 8
56432 72331.079 -0.000266342 1.077 0.000295571 0.003881 8
56432 72592.129 -0.000191130 1.074 0.000277757 0.003779 8
56432 72789.168 -0.000166024 1.072 0.000259970 0.003602 8
56432 72934.209 -0.000070023 1.071 0.000245537 0.003376 8
56432 73340.275 -0.000163612 1.067 0.000232050 0.003454 8
56432 73394.282 -0.000166916 1.067 0.000217066 0.003237 8
56432 73664.335 0.000036980 1.068 0.000215464 0.003035 8
56432 74135.424 -0.000134512 1.064 0.000210470 0.003137 8
56432 74195.437 0.000032668 1.064 0.000205558 0.002935 8
56432 74462.487 -0.000159677 1.061 0.000203953 0.002889 8
56432 74494.494 -0.000093734 1.061 0.000192200 0.002703 8
56432 74762.544 0.000009260 1.061 0.000183437 0.002529 8
56432 75225.637 -0.000128364 1.058 0.000178355 0.002677 8
56432 75365.659 -0.000284232 1.055 0.000175702 0.002640 8
56432 76095.801 -0.000501272 1.034 0.000181385 0.008097 8
56432 76138.812 -0.000447739 1.032 0.000170723 0.007585 8
56432 76401.858 -0.000318762 1.027 0.000166079 0.007312 8
56432 76628.903 -0.000181357 1.025 0.000162771 0.006894 8
56432 76806.935 -0.000199283 1.023 0.000152391 0.006492 8
56432 77071.986 0.000021737 1.023 0.000162562 0.006074 8
56432 77479.064 -0.000116562 1.020 0.000159731 0.005769 8
56432 77610.091 -0.000188130 1.019 0.000151542 0.005422 8
56432 77859.137 -0.000137210 1.017 0.000142893 0.005122 8
56432 78117.186 -0.000036177 1.016 0.000138355 0.004795 8
56432 78275.217 0.000120217 1.017 0.000140736 0.004504 8
56432 78451.251 -0.000111734 1.016 0.000155100 0.004233 8
56432 78901.336 0.000069003 1.018 0.000158532 0.004013 8
56432 78975.350 -0.000048623 1.018 0.000154014 0.003755 8
56432 79233.399 0.000092171 1.019 0.000152424 0.003548 8
56432 79451.443 0.000097515 1.021 0.000142592 0.003349 8
56432 79861.520 0.000117785 1.023 0.000133575 0.003294 8
56432 79974.541 0.000042651 1.024 0.000127741 0.003083 8
56432 80245.593 -0.000061922 1.023 0.000125080 0.002905 8
56432 80551.654 -0.000010904 1.023 0.000118383 0.002718 8
56432 80607.664 0.000246355 1.023 0.000143302 0.002559 8
56432 80816.703 -0.000077882 1.022 0.000176380 0.002419 8
56432 81125.762 0.000131575 1.025 0.000180846 0.002419 8
56432 81395.824 0.000037081 1.025 0.000172433 0.002273 8
56432 81440.821 0.000048631 1.026 0.000161348 0.002126 8
56432 81708.873 0.000019280 1.026 0.000151284 0.001992 8
56432 82116.956 0.000005636 1.026 0.000141595 0.001864 8
56432 82490.023 0.000074462 1.028 0.000134667 0.001839 8
56432 82752.075 -0.000039200 1.027 0.000132224 0.001734 8
56432 83073.134 0.000051056 1.028 0.000127734 0.001658 8
56432 83257.181 -0.000228589 1.026 0.000155086 0.001787 8
56432 83434.205 -0.000334489 1.022 0.000149823 0.002086 8
56432 83697.254 -0.000129159 1.020 0.000157833 0.002078 8
56432 83955.303 -0.000000293 1.020 0.000154509 0.001944 8
56432 84298.370 0.000001306 1.020 0.000144532 0.001818 8
56432 84536.414 -0.000043359 1.019 0.000136116 0.001715 8
56432 84852.476 0.000114990 1.022 0.000139090 0.001777 8
56432 85032.509 0.000049897 1.022 0.000132126 0.001673 8
56432 85385.580 0.000162893 1.026 0.000129889 0.001980 8
56432 85605.619 0.000106776 1.027 0.000123109 0.001917 8
56432 85899.676 0.000353078 1.033 0.000144376 0.002828 8
56432 86171.731 0.000195111 1.036 0.000146144 0.002872 8
56432 86372.766 0.000182964 1.038 0.000136773 0.002796 8

> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelorm...@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelorm...@lists.ntp.org] On Behalf Of
> David Woolley
> Sent: Monday, May 20, 2013 8:13 AM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>

[Mischanko, Edward T]

Unruh,

I don't happen to own David Mill's book, but I understand what you are
saying to be true. My concern is that too much data is being thrown away
when polling above 256 seconds and that allows excessive wandering of my
clock. Yes, I can cap the interval to 256, but is that the only answer?
I would rather increase the interval of adjustments not the polling
interval.

Regards,
Ed

> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelorm...@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelorm...@lists.ntp.org] On Behalf Of
> unruh
> Sent: Monday, May 20, 2013 3:14 PM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>

[Steve Kostecke]

On 2013-05-21, Mischanko, Edward T <Edward.M...@arcelormittal.com> wrote:

> My concern is that too much data is being thrown away when polling
> above 256 seconds and that allows excessive wandering of my clock.

The clock filter algorithm processes the offset and delay samples
produced by the on-wire protocol for each peer process separately. It
uses a sliding window of eight samples and picks out the sample with the
least expected error.

http://www.eecis.udel.edu/~mills/ntp/html/filter.html describes
the algorithm design principles along with an example of typical
performance.

> Yes, I can cap the interval to 256, but is that the only answer?
> I would rather increase the interval of adjustments not the polling
> interval.

A general overview of the clock discpline algorithm; along with
discussions of phase-lock loop operations, loop dynamics, and clock
initialization and management; are presented at
http://www.eecis.udel.edu/~mills/ntp/html/discipline.html

--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/

[David Woolley]

> On 2013-05-21, Mischanko, Edward T <Edward.M...@arcelormittal.com> wrote:
>
>> My concern is that too much data is being thrown away when polling
>> above 256 seconds and that allows excessive wandering of my clock.
>

If too much data is being thrown away, it would be because the poll
adjust algorithm has chosen too high a poll interval (or you have too
high a minpoll) for the noise statistics. The samples are, effectively,
put through an IIR digital low pass filter, with a bandwidth that is
sufficiently narrow that variations across the 8 samples are largely
suppressed. However, if you include all the samples, their overall
average is likely to be biassed away from a zero error, and as that is
likely to not change, or only change slowly from one group of 8 to the
next, it will introduce an error that is not filtered out.

It is not throwing out anything like the equivalent of 7 out of eight
samples, because the contributions of the variations between samples are
high frequency noise, which is probably being attenuated by a factor
significantly more than 8.

The way that ntpd chooses the poll interval is by looking at the offset
and jitter (exponential average of sample to sample variations). If the
offset consistently exceeds the jitter, it means that part of the offset
cannot be accounted for by the measurement noise, and more aggressive
correction is needed. Unfortunately, if something make the crystal
frequency change suddenly, after a long stable period, it can take some
time before it realises it needs to do aggressive correction.

[Mischanko, Edward T]

>
>
> > On 2013-05-21, Mischanko, Edward T <Edward.M...@arcelormittal.com>
> wrote:
> >
> >> My concern is that too much data is being thrown away when polling
> >> above 256 seconds and that allows excessive wandering of my clock.
> >
>
> If too much data is being thrown away, it would be because the poll
> adjust algorithm has chosen too high a poll interval (or you have too
> high a minpoll) for the noise statistics.

[Mischanko, Edward T]

This is exactly what I am saying!! This needs to be corrected; I consider it a bug.

The samples are, effectively,
> put through an IIR digital low pass filter, with a bandwidth that is
> sufficiently narrow that variations across the 8 samples are largely
> suppressed. However, if you include all the samples, their overall

> average is likely to be biased away from a zero error, and as that is

> likely to not change, or only change slowly from one group of 8 to the
> next, it will introduce an error that is not filtered out.
>
> It is not throwing out anything like the equivalent of 7 out of eight
> samples, because the contributions of the variations between samples are
> high frequency noise, which is probably being attenuated by a factor
> significantly more than 8.
>
> The way that ntpd chooses the poll interval is by looking at the offset
> and jitter (exponential average of sample to sample variations). If the
> offset consistently exceeds the jitter, it means that part of the offset
> cannot be accounted for by the measurement noise, and more aggressive
> correction is needed. Unfortunately, if something make the crystal
> frequency change suddenly, after a long stable period, it can take some

> time before it realizes it needs to do aggressive correction.
[Mischanko, Edward T]

It takes too long to figure out it needs a more aggressive correction.
If I leave maxpoll at the default of 1024 seconds, my clock drifts outside
of 5 milliseconds consistently.

Too much assumption is made that everyone will have the perfect computer and
the perfect network when configuring these various filters. What works on
the blackboard does not always work in reality. My computer has a
-19 precision but it can't keep time inside 1 millisecond with default
Settings; go figure.

[Charles Swiger]

On May 23, 2013, at 10:02 PM, "Mischanko, Edward T" <Edward.M...@arcelormittal.com> wrote:
> It takes too long to figure out it needs a more aggressive correction.
> If I leave maxpoll at the default of 1024 seconds, my clock drifts outside
> of 5 milliseconds consistently.

Measured by what? If you have a better source of time available, sync ntpd using that.

More importantly, ntpd should be entirely able to compensate for a steady drift of ~50 ppm;
are you saying that not only do you have a long-term drift, but short-term instability
which varies by ~50+ ppm hour-by-hour?

> Too much assumption is made that everyone will have the perfect computer and
> the perfect network when configuring these various filters. What works on
> the blackboard does not always work in reality.

Oddly enough, my ~25 year experience with ntpd suggests a great deal of practical
experience has gone into creating a timekeeping solution that avoids chasing short-term
transients in favor of stable long-term behavior.

However, it's certainly OK if someone decides that some other software provides a better
solution for their particular circumstances….

> My computer has a -19 precision but it can't keep time inside 1 millisecond with default
> Settings; go figure.

Precision of -19 suggests commonly available commodity hardware. Keeping time to around 1ms
should be reasonably doable with a decent network connection, at least 4 reasonable peers
or timesources to query, temperature-controlled systems, and an OS with sane timekeeping;
VMs need not apply regardless of OS.

It might help to setup a subnet local peering of ~4 or so machines, in addition to the
remote timesources or a GPS/ACTS/WWVB or similar stratum-1 source.

Regards,
--
-Chuck

[David Woolley]

Mischanko, Edward T wrote:
>
>>
>>> On 2013-05-21, Mischanko, Edward T <Edward.M...@arcelormittal.com>
>> wrote:
>>>> My concern is that too much data is being thrown away when polling
>>>> above 256 seconds and that allows excessive wandering of my clock.
>> If too much data is being thrown away, it would be because the poll
>> adjust algorithm has chosen too high a poll interval (or you have too
>> high a minpoll) for the noise statistics.
> [Mischanko, Edward T]
>
> This is exactly what I am saying!! This needs to be corrected; I consider it a bug.

How would you modify the algorithm that chooses the poll interval.
Remember that getting too low a poll interval will make ntpd track short
term variations in network latency and prevent it getting an accurate
estimate of the crystal frequency error.

Please provide a detailed specification of your proposed algorithm.

> Too much assumption is made that everyone will have the perfect computer and
> the perfect network when configuring these various filters. What works on

A lot of allowances have been made for the real world. The only
allowance that has not been made is that it assumes that crystal
frequency errors are essentially random, and thus can get into
difficulty if a (normally very cheap) motherboard crystal is in a
thermal environment that exhibits non-gaussian behaviour.

> the blackboard does not always work in reality. My computer has a
> -19 precision but it can't keep time inside 1 millisecond with default
> Settings; go figure.

I figure that you don't understand the various latencies that exists in
the system and network, and the difficulties of interpolating clock
ticks on Windows. The precision figure, for Windows, is almost
certainly optimistic because of the hacks ntpd has to go through to
interpolate the clock in user space.

The reason for the difficulty in interpolating is that Windows does not
achieve anything like the timing resolution in the Windows API
architecture. Earlier versions of Windows NT could only supply time to
applications to a resolution of 16ms (before ntpd started doing user
space interpolation, NT 3.5 would return an ntpd precision of -6).
Intermediate ones had a variable resolution, depending on the use of
multi-media timers, but I don't think it was better than 1ms. I'm not
sure of the exact parameters to the latest generation; but I don't think
ordinary applications will be seeing anything close to 2 microsecond
resolution. (Changes of multimedia timer rates, causes upsets.)
Basically, you may find that the main error component in the time
supplied to ordiary Windows applications is due to the limitations of
the Windows time reading APIs.

Also, I don't remember your ever describing a test rig that is capable
of comparing the system time on your servers to true time. Offset is
not offset from true time. Without special instrumentation, or an
accurate theoretical model, you cannot assume that high NTP offsets
represent errors in the machine time keeping.
>

[John Hasler]

David Woolley writes:
> Offset is not offset from true time.

And that, I think, is the major point of confusion here. If offset was
the offset from true time ntpd would just subtract it out, set the clock
to true time, and we'd all be happy. It isn't. It's one of the pieces
of information ntpd uses to solve the rather subtle problem of
estimating the true time in the presence of noise and variable delays.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[unruh]

On 2013-05-24, Mischanko, Edward T <Edward.M...@arcelormittal.com> wrote:
>
>
>>
>>
>> > On 2013-05-21, Mischanko, Edward T <Edward.M...@arcelormittal.com>
>> wrote:
>> >
>> >> My concern is that too much data is being thrown away when polling
>> >> above 256 seconds and that allows excessive wandering of my clock.
>> >
>>
>> If too much data is being thrown away, it would be because the poll
>> adjust algorithm has chosen too high a poll interval (or you have too
>> high a minpoll) for the noise statistics.
> [Mischanko, Edward T]
>
> This is exactly what I am saying!! This needs to be corrected; I consider it a bug.

And until you take over the running of ntp, it will remain your opinion,
and not that of the supporter.

>
> The samples are, effectively,
>> put through an IIR digital low pass filter, with a bandwidth that is
>> sufficiently narrow that variations across the 8 samples are largely
>> suppressed. However, if you include all the samples, their overall
>> average is likely to be biased away from a zero error, and as that is
>> likely to not change, or only change slowly from one group of 8 to the
>> next, it will introduce an error that is not filtered out.
>>
>> It is not throwing out anything like the equivalent of 7 out of eight
>> samples, because the contributions of the variations between samples are
>> high frequency noise, which is probably being attenuated by a factor
>> significantly more than 8.
>>
>> The way that ntpd chooses the poll interval is by looking at the offset
>> and jitter (exponential average of sample to sample variations). If the
>> offset consistently exceeds the jitter, it means that part of the offset
>> cannot be accounted for by the measurement noise, and more aggressive
>> correction is needed. Unfortunately, if something make the crystal
>> frequency change suddenly, after a long stable period, it can take some
>> time before it realizes it needs to do aggressive correction.
> [Mischanko, Edward T]
>
> It takes too long to figure out it needs a more aggressive correction.
> If I leave maxpoll at the default of 1024 seconds, my clock drifts outside
> of 5 milliseconds consistently.

So lower maxpoll!

>
> Too much assumption is made that everyone will have the perfect computer and
> the perfect network when configuring these various filters. What works on
> the blackboard does not always work in reality. My computer has a
> -19 precision but it can't keep time inside 1 millisecond with default
> Settings; go figure.

That is unfair. Mills has spent a lot of time making sure it works in
the real world. That his priorities are not yours is surely something he
is entitled to. Why do you not use chrony? I know you have tried it.

[David Woolley]

> is entitled to. Why do you not use chrony? I know you have tried it.
>

I'm fairly sure he said Windows up thread.

[unruh]

On 2013-05-24, David Woolley <da...@ex.djwhome.demon.invalid> wrote:
>
>> is entitled to. Why do you not use chrony? I know you have tried it.
>>
> I'm fairly sure he said Windows up thread.

If he did, I missed it, and I apologize for my irrelevant suggestion.
So, decrease the poll interval.

[Mischanko, Edward T]

> -----Original Message-----
> From: Charles Swiger [mailto:csw...@mac.com]
> Sent: Friday, May 24, 2013 1:01 AM
> To: Mischanko, Edward T
> Cc: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>

> On May 23, 2013, at 10:02 PM, "Mischanko, Edward T"
> <Edward.M...@arcelormittal.com> wrote:
> > It takes too long to figure out it needs a more aggressive correction.
> > If I leave maxpoll at the default of 1024 seconds, my clock drifts
> outside
> > of 5 milliseconds consistently.
>

[Mischanko, Edward T]

Measured by the best time sources I have available. I am saying that my
clock will drift to 5 milliseconds at maxpoll 10 and polling does not
decrease to a level that will bring my clock back to an offset of +/- 1
millisecond.

> Measured by what? If you have a better source of time available, sync
> ntpd using that.
>
> More importantly, ntpd should be entirely able to compensate for a steady
> drift of ~50 ppm;
> are you saying that not only do you have a long-term drift, but short-term
> instability
> which varies by ~50+ ppm hour-by-hour?
>
> > Too much assumption is made that everyone will have the perfect computer
> and
> > the perfect network when configuring these various filters. What works
> on
> > the blackboard does not always work in reality.
>

[Mischanko, Edward T]

I your 25 year experience have you ever thought they may be a better way to
achieve the same goals? Or, have you ever looked at your goals and asked
yourself what are the primary goals and what are secondary goals? I am
suggesting that clock offset is primary to clock jitter.

> Oddly enough, my ~25 year experience with ntpd suggests a great deal of
> practical
> experience has gone into creating a timekeeping solution that avoids
> chasing short-term
> transients in favor of stable long-term behavior.
>
> However, it's certainly OK if someone decides that some other software
> provides a better

> solution for their particular circumstances....

>
> > My computer has a -19 precision but it can't keep time inside 1
> millisecond with default
> > Settings; go figure.
>

[Mischanko, Edward T]

I have common PC running Windows XP with 10 peers on my side of a corporate
firewall.

> Precision of -19 suggests commonly available commodity hardware. Keeping
> time to around 1ms
> should be reasonably doable with a decent network connection, at least 4
> reasonable peers

> or time sources to query, temperature-controlled systems, and an OS with

> sane timekeeping;
> VMs need not apply regardless of OS.
>
> It might help to setup a subnet local peering of ~4 or so machines, in
> addition to the

> remote time sources or a GPS/ACTS/WWVB or similar stratum-1 source.
>
> Regards,
> --
> -Chuck

[Mischanko, Edward T]

> >>> On 2013-05-21, Mischanko, Edward T
> <Edward.M...@arcelormittal.com>
> >> wrote:
> >>>> My concern is that too much data is being thrown away when polling
> >>>> above 256 seconds and that allows excessive wandering of my clock.
> >> If too much data is being thrown away, it would be because the poll
> >> adjust algorithm has chosen too high a poll interval (or you have too
> >> high a minpoll) for the noise statistics.
> > [Mischanko, Edward T]
> >
> > This is exactly what I am saying!! This needs to be corrected; I
> consider it a bug.
>

[Mischanko, Edward T]

I would modify the current algorithm with an exception that if offsets
exceed 1 millisecond for more than one polling cycle, then, polling will be
reduced by one interval, else, continue normal operation.

> How would you modify the algorithm that chooses the poll interval.
> Remember that getting too low a poll interval will make ntpd track short
> term variations in network latency and prevent it getting an accurate
> estimate of the crystal frequency error.
>
> Please provide a detailed specification of your proposed algorithm.
>
> > Too much assumption is made that everyone will have the perfect computer
> and
> > the perfect network when configuring these various filters. What works
> on
>
> A lot of allowances have been made for the real world. The only
> allowance that has not been made is that it assumes that crystal
> frequency errors are essentially random, and thus can get into
> difficulty if a (normally very cheap) motherboard crystal is in a
> thermal environment that exhibits non-gaussian behaviour.
>
> > the blackboard does not always work in reality. My computer has a
> > -19 precision but it can't keep time inside 1 millisecond with default
> > Settings; go figure.
>

[Mischanko, Edward T]

Yes, there are many things that I do not understand about the various
latencies, and the difficulties of interpolating clock ticks, and writing
software code. I do know that as great as NTPD is, it doesn't work as well
as I thought the authors intended on my system. I seek improvement and not
to berate anyone.

> I figure that you don't understand the various latencies that exists in
> the system and network, and the difficulties of interpolating clock
> ticks on Windows. The precision figure, for Windows, is almost
> certainly optimistic because of the hacks ntpd has to go through to
> interpolate the clock in user space.
>
> The reason for the difficulty in interpolating is that Windows does not
> achieve anything like the timing resolution in the Windows API
> architecture. Earlier versions of Windows NT could only supply time to
> applications to a resolution of 16ms (before ntpd started doing user
> space interpolation, NT 3.5 would return an ntpd precision of -6).
> Intermediate ones had a variable resolution, depending on the use of
> multi-media timers, but I don't think it was better than 1ms. I'm not
> sure of the exact parameters to the latest generation; but I don't think
> ordinary applications will be seeing anything close to 2 microsecond
> resolution. (Changes of multimedia timer rates, causes upsets.)
> Basically, you may find that the main error component in the time
> supplied to ordiary Windows applications is due to the limitations of
> the Windows time reading APIs.
>

[Mischanko, Edward T]

It is an offset from the best time source I have available. How high of an
offset is intended to be acceptable?

> Also, I don't remember your ever describing a test rig that is capable
> of comparing the system time on your servers to true time. Offset is
> not offset from true time. Without special instrumentation, or an
> accurate theoretical model, you cannot assume that high NTP offsets
> represent errors in the machine time keeping.
> >
>

[Mischanko, Edward T]

Edward T. Mischanko | Maintenance Technician, Electrical
ArcelorMittal Burns Harbor

Finishing | 250 W. US Highway 12
Burns Harbor, IN 46304-9745

T +1 219 787 3601 | F +1 219 787 4510
www.arcelormittal.com

> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelorm...@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelorm...@lists.ntp.org] On Behalf Of
> unruh
> Sent: Friday, May 24, 2013 9:55 AM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>

> On 2013-05-24, Mischanko, Edward T <Edward.M...@arcelormittal.com>
> wrote:
> >
> >
> >>
> >>
> >> > On 2013-05-21, Mischanko, Edward T
> <Edward.M...@arcelormittal.com>
> >> wrote:
> >> >
> >> >> My concern is that too much data is being thrown away when polling
> >> >> above 256 seconds and that allows excessive wandering of my clock.
> >> >
> >>
> >> If too much data is being thrown away, it would be because the poll
> >> adjust algorithm has chosen too high a poll interval (or you have too
> >> high a minpoll) for the noise statistics.
> > [Mischanko, Edward T]
> >
> > This is exactly what I am saying!! This needs to be corrected; I
> consider it a bug.
>

[Mischanko, Edward T]

Are you one of the authors or is this just more unneeded information?

[Mischanko, Edward T]

To lower maxpoll is to defeat the software author's intent.

> So lower maxpoll!
>
>
> >
> > Too much assumption is made that everyone will have the perfect computer
> and
> > the perfect network when configuring these various filters. What works
> on
> > the blackboard does not always work in reality. My computer has a
> > -19 precision but it can't keep time inside 1 millisecond with default
> > Settings; go figure.
>

[Mischanko, Edward T]

Yes, maybe unfair, but equally unfair is the assumption that the user must
be doing something wrong for it to work this way. I need to be as
constructive as possible, as does everyone on this list. I don't know if
Dr. Mills is much involved with the Windows port? As for chrony, I would
try it if they had a Windows port.

[David Woolley]

Mischanko, Edward T wrote:

>
> I would modify the current algorithm with an exception that if offsets
> exceed 1 millisecond for more than one polling cycle, then, polling will be
> reduced by one interval, else, continue normal operation.
>

Whilst I still think the OP is trying to make the statistics look good,
rather than have good time keeping, I can sort of see two feature
requests here:

1) a tinker option to specify an assumed maximum jitter, which will
allow the user to put in a long term jitter statistic for their system,
rather than having ntpd work it out for itself.

2) a tinker option for a panic level of offset, where, it is assumed to
be so improbable, given the specific noise statistics of the actual
system, that it should immediately be considered to be due to a local
clock frequency error. Measurement noise is often non-gaussian, so it
unlikely to be safe to make this a fixed multiple of the value in item
(1). If this is to be used without filtering by the minimum delay
filter, it will need to be a lot higher than the filtered value, as the
minimum delay filter will take out most one off spikes in offset.

I am not volunteering to write the code for these, and I do have concern
that an urban folklore will develop in which in become it becomes common
advice to set them excessively low.

However, I still feel that, if the underlying problem is clock frequency
drift, the primary fix is to address the cause of that drift, and the
stop gap solution is to reduce maxpoll. If it is almost anything else,
the offset changes do not indicate a timekeeping error and should not be
acted upon.

[unruh]

On 2013-05-25, Mischanko, Edward T <Edward.M...@arcelormittal.com> wrote:
>
>> -----Original Message-----
>> From: Charles Swiger [mailto:csw...@mac.com]
>> Sent: Friday, May 24, 2013 1:01 AM
>> To: Mischanko, Edward T
>> Cc: ques...@lists.ntp.org
>> Subject: Re: [ntp:questions] Tighter regulation?
>>
>> On May 23, 2013, at 10:02 PM, "Mischanko, Edward T"
>> <Edward.M...@arcelormittal.com> wrote:
>> > It takes too long to figure out it needs a more aggressive correction.
>> > If I leave maxpoll at the default of 1024 seconds, my clock drifts
>> outside
>> > of 5 milliseconds consistently.
>>
> [Mischanko, Edward T]
>
> Measured by the best time sources I have available. I am saying that my

And maybe it is that "best" that is wrong. Why not give the details so
we can decide?

> clock will drift to 5 milliseconds at maxpoll 10 and polling does not
> decrease to a level that will bring my clock back to an offset of +/- 1
> millisecond.

Note that on maxpoll 10, the clock will freerun for about 7000 sec
between disciplines. 5ms in 7000 sec is about 1PPM. Now if your computer
heats up and cools down by 20C over an hour that could change the clock
by a few ms. And ntpd is slow to respond to changes in clock rate.
What happens if you do maxpoll 6? Give us details, not vague statements.

Also try plotting peerstats and the offset as a function of time.

[Brian Utterback]

On 5/25/2013 5:55 AM, Mischanko, Edward T wrote:
> [Mischanko, Edward T]
>
> I would modify the current algorithm with an exception that if offsets
> exceed 1 millisecond for more than one polling cycle, then, polling will be
> reduced by one interval, else, continue normal operation.

What if 1 millisecond doesn't happen to by the tolerance that some
particular system needs? Ten years ago, I was thrilled if my customers
reported off sets in the 10-20ms range and sub-10ms was rare. Not to
mention that what should be expected in the way of maximum offset is a
function to the polling period and the frequency measurement accuracy,
the latter of which is probably large and unknown when the clock system
starts.

The current algorithm is supposed to use the amount of jitter and the
increase in the offset between polls to determine when to increase the
polling period. If the noise in the samples is greater than the amount
of offset between polls, then there is no way to increase the accuracy
of the clock at the current polling rate. So, if you are seeing large
offsets at a particular poll rate, then that would indicate that your
jitter is too high to prevent it. However, conditions change, and I
believe that the algorithm for reducing the poll rate again is known to
be too "stiff".

So, are you seeing offsets that are large immediately after the poll
rate is increased, or does it cruise along fine for awhile and then you
see increasing offsets? The former would indicate too much jitter, the
latter woudl indicate an actual failure of NTP to respond quickly to
change in clock frequency.

Brian Utterback

[David Woolley]

unruh wrote:

>
> Note that on maxpoll 10, the clock will freerun for about 7000 sec
> between disciplines. 5ms in 7000 sec is about 1PPM. Now if your computer

The time constant for the proportional correction is 16384 seconds, so
only about 35% of the correction would be made over 7000 seconds. In
terms of correcting a random step phase change some time in that
interval, one is only talking about losing an average about 17% of the
total correction required as a result of the lower effective sampling rate.

I think the time for the integral component to remove a frequency step
is even longer (I think it actually rings), except that the rapidly
growing offset will cause the poll interval and time constant to drop.
I suspect, if the poll interval remained constant, the reciprocal of the
loop frequency would be so much longer than 7000 seconds that there
would be little difference between 1024 and 7000 second effective
sampling rates.

As I said above, the real issue is that of correctly identifying a step
in the frequency, or its first derivative, and rapidly turning down the
time constants.

I am also wondering whether setting a lower Allan Intercept would help.
One problem is that it assumes gaussian behaviour of frequency
errors, but the situations where high offsets actually indicate a bad
time generally involve very non-gaussian statistics.

[Mischanko, Edward T]

> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelorm...@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelorm...@lists.ntp.org] On Behalf Of
> David Woolley
> Sent: Saturday, May 25, 2013 7:57 AM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>

> Mischanko, Edward T wrote:
>
> >
> > I would modify the current algorithm with an exception that if offsets
> > exceed 1 millisecond for more than one polling cycle, then, polling
> will be
> > reduced by one interval, else, continue normal operation.
> >
>
> Whilst I still think the OP is trying to make the statistics look good,
> rather than have good time keeping, I can sort of see two feature
> requests here:
>
> 1) a tinker option to specify an assumed maximum jitter, which will
> allow the user to put in a long term jitter statistic for their system,
> rather than having ntpd work it out for itself.
>
> 2) a tinker option for a panic level of offset, where, it is assumed to
> be so improbable, given the specific noise statistics of the actual
> system, that it should immediately be considered to be due to a local
> clock frequency error. Measurement noise is often non-gaussian, so it
> unlikely to be safe to make this a fixed multiple of the value in item
> (1). If this is to be used without filtering by the minimum delay
> filter, it will need to be a lot higher than the filtered value, as the
> minimum delay filter will take out most one off spikes in offset.
>
> I am not volunteering to write the code for these, and I do have concern
> that an urban folklore will develop in which in become it becomes common
> advice to set them excessively low.
>

[Mischanko, Edward T]

The frequency ppm does not oscillate nor does the clock offset over short periods of time. Reducing maxpoll to 8 is effective is solving my issue. I agree that we should not be chasing noise spikes.

> However, I still feel that, if the underlying problem is clock frequency
> drift, the primary fix is to address the cause of that drift, and the
> stop gap solution is to reduce maxpoll. If it is almost anything else,
> the offset changes do not indicate a timekeeping error and should not be
> acted upon.
>

[Mischanko, Edward T]

> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelorm...@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelorm...@lists.ntp.org] On Behalf Of
> unruh

[Mischanko, Edward T]

What details do you want? I am syncing to 10 stratum 4 servers in my case.
Servers outside of my LAN are blocked by the corporate firewall.

> And maybe it is that "best" that is wrong. Why not give the details so
> we can decide?
>
> > clock will drift to 5 milliseconds at maxpoll 10 and polling does not
> > decrease to a level that will bring my clock back to an offset of +/- 1
> > millisecond.
>
> Note that on maxpoll 10, the clock will freerun for about 7000 sec
> between disciplines. 5ms in 7000 sec is about 1PPM.

[Mischanko, Edward T]

I don't believe the room temperature changes much at this computer's
location.

Now if your computer
> heats up and cools down by 20C over an hour that could change the clock
> by a few ms. And ntpd is slow to respond to changes in clock rate.

[Mischanko, Edward T]

If I do maxpoll 8, then I get regulation within 1 millisecond. What other
details would you like? I can post my loopstats in the future if that
would be helpful?

> What happens if you do maxpoll 6? Give us details, not vague statements.
>

[Mischanko, Edward T]

I do not know how to analyze the peerstats file, but I can post it if that
would help?

[Mischanko, Edward T]

> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelorm...@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelorm...@lists.ntp.org] On Behalf Of
> Brian Utterback
> Sent: Saturday, May 25, 2013 12:15 PM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>

> On 5/25/2013 5:55 AM, Mischanko, Edward T wrote:
> > [Mischanko, Edward T]
> >
> > I would modify the current algorithm with an exception that if offsets
> > exceed 1 millisecond for more than one polling cycle, then, polling
> will be
> > reduced by one interval, else, continue normal operation.
>

[Mischanko, Edward T]

I chose 1 millisecond because it appears to be achievable. I don't have
that specific requirement; I don't have any requirements. What is the
expectation, though?

> What if 1 millisecond doesn't happen to by the tolerance that some
> particular system needs? Ten years ago, I was thrilled if my customers
> reported off sets in the 10-20ms range and sub-10ms was rare. Not to
> mention that what should be expected in the way of maximum offset is a
> function to the polling period and the frequency measurement accuracy,
> the latter of which is probably large and unknown when the clock system
> starts.
>
> The current algorithm is supposed to use the amount of jitter and the
> increase in the offset between polls to determine when to increase the
> polling period. If the noise in the samples is greater than the amount
> of offset between polls, then there is no way to increase the accuracy
> of the clock at the current polling rate. So, if you are seeing large
> offsets at a particular poll rate, then that would indicate that your
> jitter is too high to prevent it. However, conditions change, and I
> believe that the algorithm for reducing the poll rate again is known to
> be too "stiff".
>

[Mischanko, Edward T]

Brian, I see the latter.

> So, are you seeing offsets that are large immediately after the poll
> rate is increased, or does it cruise along fine for awhile and then you
> see increasing offsets? The former would indicate too much jitter, the
> latter woudl indicate an actual failure of NTP to respond quickly to
> change in clock frequency.
>
> Brian Utterback

[Mischanko, Edward T]

> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelorm...@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelorm...@lists.ntp.org] On Behalf Of

> David Woolley
> Sent: Saturday, May 25, 2013 4:02 PM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>

> unruh wrote:
>
> >
> > Note that on maxpoll 10, the clock will freerun for about 7000 sec
> > between disciplines. 5ms in 7000 sec is about 1PPM. Now if your computer
>
> The time constant for the proportional correction is 16384 seconds, so
> only about 35% of the correction would be made over 7000 seconds. In
> terms of correcting a random step phase change some time in that
> interval, one is only talking about losing an average about 17% of the
> total correction required as a result of the lower effective sampling
> rate.
>
> I think the time for the integral component to remove a frequency step
> is even longer (I think it actually rings), except that the rapidly
> growing offset will cause the poll interval and time constant to drop.
> I suspect, if the poll interval remained constant, the reciprocal of the
> loop frequency would be so much longer than 7000 seconds that there
> would be little difference between 1024 and 7000 second effective
> sampling rates.
>

[Mischanko, Edward T]

Yes, I agree!

> As I said above, the real issue is that of correctly identifying a step
> in the frequency, or its first derivative, and rapidly turning down the
> time constants.
>

[Mischanko, Edward T]

I tried reducing the Allan Intercept to 7 and the result was wild swings in
frequency ppm. I don't know why? Is the FLL broken? Has anyone else
observed this behavior?

[David Woolley]

Mischanko, Edward T wrote:

>
> I tried reducing the Allan Intercept to 7 and the result was wild swings in
> frequency ppm. I don't know why? Is the FLL broken? Has anyone else
> observed this behavior?

If you are not suffering from wild swings in frequency, you should not
be trying to reduce the measured offsets. There are basically two
causes of high offsets, errors in you own frequency and errors in
measurement of the time. The latter you should be trying to get ntpd to
ignore, and only take the long term average of the time measurement.

[David Lord]

Mischanko, Edward T wrote:

....

> I don't believe the room temperature changes much at this computer's
> location.
>
> Now if your computer
>> heats up and cools down by 20C over an hour that could change the clock
>> by a few ms. And ntpd is slow to respond to changes in clock rate.
> [Mischanko, Edward T]
>
> If I do maxpoll 8, then I get regulation within 1 millisecond. What other
> details would you like? I can post my loopstats in the future if that
> would be helpful?
>
>> What happens if you do maxpoll 6? Give us details, not vague statements.
>>
> [Mischanko, Edward T]
>
> I do not know how to analyze the peerstats file, but I can post it if that
> would help?

My maxpoll settings are internet servers = 12, my public and lan
servers = 10, public and lan peers = 8.

Above is not ideal if ambient temperature or system temperatures
vary too quickly. December-January and June-July are best periods
for minimum temperature change but November-March I often lose my
GPS signal.


In the ntpd distributions I have is "summary.sh" which is a script
to do a summary then delete the peer, loop and clockstats files.


"summary.pps.20130516 gps/pps connected server on lan"

loopstats.20130516
loop 1350, 3+/-34.8, rms 4.9, freq -36.10+/-0.343, var 0.199

peerstats.20130516
ident cnt mean rms max delay dist disp
==========================================================================
127.127.20.2 1350 1.135 18.939 62.924 0.000 2.607 1.873
127.127.22.2 1350 0.001 0.005 0.038 0.000 0.930 0.930
81.187.61.69 310 0.123 0.261 1.057 0.839 6.286 3.056
90.155.53.93 74 0.683 0.283 0.721 16.277 31.016 10.816
81.187.61.74 316 0.512 0.726 2.085 1.530 7.029 3.310
81.187.61.65 66 0.154 0.859 2.502 0.940 22.667 10.039
81.187.61.78 68 0.046 0.500 1.770 0.688 22.090 11.560


"summary.ntp0.20130516 ntp0.lordynet.org.uk"

loopstats.20130516
loop 145, 135+/-1693.8, rms 699.0, freq 2.48+/-0.184, var 0.120

peerstats.20130516
ident cnt mean rms max delay dist disp
==========================================================================
130.159.196.117 69 0.011 0.720 1.914 26.757 34.487 11.098
81.187.61.65 154 -0.379 0.570 1.484 0.611 20.081 4.823
130.88.200.6 75 5.671 2.277 5.958 23.255 34.796 10.529
195.173.57.232 69 0.296 0.711 1.759 16.140 29.913 10.937
81.187.61.69 130 -0.279 0.708 1.697 0.424 19.692 5.287
143.210.16.201 73 0.237 0.619 1.812 24.244 33.428 10.498


David

[Mischanko, Edward T]

> -----Original Message-----
> From: questions-bounces+edward.mischanko=arcelorm...@lists.ntp.org
> [mailto:questions-
> bounces+edward.mischanko=arcelorm...@lists.ntp.org] On Behalf Of
> David Woolley
> Sent: Sunday, May 26, 2013 3:52 AM
> To: ques...@lists.ntp.org
> Subject: Re: [ntp:questions] Tighter regulation?
>

> Mischanko, Edward T wrote:
>
> >
> > I tried reducing the Allan Intercept to 7 and the result was wild swings
> in
> > frequency ppm. I don't know why? Is the FLL broken? Has anyone else
> > observed this behavior?
>

[Mischanko, Edward T]

To be more specific, I get wild adjustments in frequency when polling at or
above the allan intercept setting with current FLL gain settings. Again,
I don't know why? I don't understand how the frequency locked loop works
verses the phase locked loop -- the differences?

> If you are not suffering from wild swings in frequency, you should not
> be trying to reduce the measured offsets. There are basically two
> causes of high offsets, errors in you own frequency and errors in
> measurement of the time. The latter you should be trying to get ntpd to
> ignore, and only take the long term average of the time measurement.
>

[unruh]

It is not the room temp. It is the computer temp. That is determined
almost entirely by what the computer is doing, not the room. Only if the
computer never does anything is the room important.

>
> Now if your computer
>> heats up and cools down by 20C over an hour that could change the clock
>> by a few ms. And ntpd is slow to respond to changes in clock rate.
> [Mischanko, Edward T]
>
> If I do maxpoll 8, then I get regulation within 1 millisecond. What other
> details would you like? I can post my loopstats in the future if that
> would be helpful?

The do maxpoll 8. "doctor -- my head hurts when I bang it against the
wall" "Well, stop banging it against the wall."

>
>> What happens if you do maxpoll 6? Give us details, not vague statements.
>>
> [Mischanko, Edward T]
>
> I do not know how to analyze the peerstats file, but I can post it if that
> would help?

No. I do not particularly want to analyse your file. The important
columns are the time and the offset. -- col 2 (the time) and 5, the
offset.
5
Plot offset vs time for each of the peers you use.

[E-Mail Sent to this address will be added to the BlackLists]

Mischanko, Edward T wrote:> I would modify the current algorithm with an exception

> that if offsets exceed 1 millisecond for more than one
> polling cycle, then, polling will be reduced by one
> interval, else, continue normal operation.

Look at ntp_loopfilter.c {around line 650?}

* Here we adjust the time constant by comparing the current
* offset with the clock jitter. If the offset is less than the
* clock jitter times a constant, then the averaging interval is
* increased, otherwise it is decreased. A bit of hysteresis
* helps calm the dance.

if (freq_cnt > 0) {
tc_counter = 0;
} else if (fabs(clock_offset) < CLOCK_PGATE * clock_jitter) {
tc_counter += sys_poll;
if (tc_counter > CLOCK_LIMIT) {
tc_counter = CLOCK_LIMIT;
if (sys_poll < peer->maxpoll) {
tc_counter = 0;
sys_poll++;
}
}
} else {
tc_counter -= sys_poll << 1;
if (tc_counter < -CLOCK_LIMIT) {
tc_counter = -CLOCK_LIMIT;
if (sys_poll > peer->minpoll) {
tc_counter = 0;
sys_poll--;
}
}
}


--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.