From Newsgroup: comp.protocols.time.ntp

ntp-4.2.8p18 using the pool and coasting along at poll 11.

These entries appeared in protostats yesterday (2024-11-19)
(there are no other entries between them):

07:43:13 178.238.156.140 0013 83 unreachable
11:14:34 178.238.156.140 0014 84 reachable

I had assumed that ntpd would mobilize a few servers and choose
one to replace the unreachable server. Why assume this? If the
server had been removed from the pool then sending packets
forever would be wrong. However, there were no new mobilization
attempts, the server came back with the same association number.

In this instance it was an "internet malfunction", see graphs on
link below.

https://www.ntppool.org/a/markcpowell

Was my expectation wrong?

Did Dave Hart's ntp-dev-3792-msm-v2 contain such code which
didn't yet get into the released code?
--
Roger
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--------------ms040100050004020906060004
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGksDQoNCk9uIFdlZCwgMjAgTm92IDIwMjQgMTA6MzQ6NTAgKzAwMDAgUm9nZXIgd3JvdGU6 DQoNCg0KPiBJIGhhZCBhc3N1bWVkIHRoYXQgbnRwZCB3b3VsZCBtb2JpbGl6ZSBhIGZldyBz ZXJ2ZXJzIGFuZCBjaG9vc2UNCj4gb25lIHRvIHJlcGxhY2UgdGhlIHVucmVhY2hhYmxlIHNl cnZlci4NCg0KSG93IGRpZCB5b3UgY29uZmlndXJlIHRoZSBOVFAgcG9vbCBpbiB5b3VyIG50 cC5jb25mPw0KDQpXaXRoIHRoZSAnc2VydmVyJy1kaXJlY3RpdmUgcGVyaGFwcz8NCg0KSSB3 b3VsZG4ndCByZWNvbW1lbmQgdGhhdC4NCg0KVGhlICdwb29sJy1kaXJlY3RpdmUgaXMgdGhl IHJpZ2h0IHdheSB0byBnbywgYnV0IHVuZm9ydHVuYXRlbHkgdGhlIA0KZG9jdW1lbnRhdGlv biBvZiB0aGUgcG9vbCB3YXMgbmV2ZXIgdXBkYXRlZCBmb3IgdGhpczoNCg0KaHR0cHM6Ly9j b21tdW5pdHkubnRwcG9vbC5vcmcvdC9meWktcmVtb3Zpbmctc2VydmVyLWZyb20tdGhlLXBv b2wvMjQyNA0KaHR0cHM6Ly93d3cubnRwcG9vbC5vcmcvZW4vdXNlLmh0bWwNCmh0dHBzOi8v Y29tbXVuaXR5Lm50cHBvb2wub3JnL3Qvc2hvdWxkLXRoZS1ob3ctdG8tdXNlLXBvb2xzLXBh Z2UtYmUtdXBkYXRlZC13aXRoLWFuLW9wdGlvbi10aGF0LXVzZXMtcG9vbC1pbnN0ZWFkLW9m LXNlcnZlci8yNTE4DQoNCi0tIA0KTWFyY28gRGF2aWRzDQpSZXNlYXJjaCBFbmdpbmVlcg0K DQpTSUROIHwgTWVhbmRlciA1MDEgfCA2ODI1IE1EIHwgUG9zdGJ1cyA1MDIyIHwgNjgwMiBF QSB8IEFSTkhFTQ0KVCArMzEgKDApMjYgMzUyIDU1IDAwIHwgd3d3LnNpZG5sYWJzLm5sIHwg VHdpdHRlcjogQG1hcmNvZGF2aWRzDQpodHRwczovL21hc3RvZG9uLnNvY2lhbC9AbWFyY29k YXZpZHMgfCBNYXRyaXg6IEBtYXJjbzpzaWRubGFicy5ubA0KTm9zdHI6IDExZWQwMWZmMjc3 ZDk0NzA1YzI5MzE4NjdiOGQ5MDBkOGJhY2NlNmYyN2FhZjc0NDBjZTk4YmI1MGUwMmZiMzQN
Cg0K

--------------ms040100050004020906060004
Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-cryptografische ondertekening

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DkUwggbmMIIEzqADAgECAhAxAnDUNb6bJJr4VtDh4oVJMA0GCSqGSIb3DQEBDAUAMIGIMQsw CQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IFJT QSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0yMDAyMTgwMDAwMDBaFw0zMzA1MDEyMzU5 NTlaMEYxCzAJBgNVBAYTAk5MMRkwFwYDVQQKExBHRUFOVCBWZXJlbmlnaW5nMRwwGgYDVQQD ExNHRUFOVCBQZXJzb25hbCBDQSA0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA s0riIl4nW+kEWxQENTIgFK600jFAxs1QwB6hRMqvnkphfy2Q3mKbM2otpELKlgE8/3AQPYBo 7p7yeORuPMnAuA+oMGRb2wbeSaLcZbpwXgfCvnKxmq97/kQkOFX706F9O7/h0yehHhDjUdyM yT0zMs4AMBDRrAFn/b2vR3j0BSYgoQs16oSqadM3p+d0vvH/YrRMtOhkvGpLuzL8m+LTAQWv QJ92NwCyKiHspoP4mLPJvVpEpDMnpDbRUQdftSpZzVKTNORvPrGPRLnJ0EEVCHR82LL6oz91 5WkrgeCY9ImuulBn4uVsd9ZpubCgM/EXvVBlViKqusChSsZEn7juIsGIiDyaIhhLsd3amm8B S3bgK6AxdSMROND6hiHT182Lmf8C+gRHxQG9McvG35uUvRu8v7bPZiJRaT7ZC2f50P4lTlnb LvWpXv5yv7hheO8bMXltiyLweLB+VNvg+GnfL6TW3Aq1yF1yrZAZzR4MbpjTWdEdSLKvz8+0 wCwscQ81nbDOwDt9vyZ+0eJXbRkWZiqScnwAg5/B1NUD4TrYlrI4n6zFp2pyYUOiuzP+as/A Znz63GvjFK69WODR2W/TK4D7VikEMhg18vhuRf4hxnWZOy0vhfDR/g3aJbdsGac+diahjEwz yB+UKJOCyzvecG8bZ/u/U8PsEMZg07iIPi8CAwEAAaOCAYswggGHMB8GA1UdIwQYMBaAFFN5 v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBRpAKHHIVj44MUbILAK3adRvxPZ5DAOBgNV HQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYI KwYBBQUHAwQwOAYDVR0gBDEwLzAtBgRVHSAAMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRydXN0LmNv bS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDB2BggrBgEFBQcBAQRq MGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FB ZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQwFAAOCAgEACgVOew2PHxM5AP1v7GLGw+3tF6rjAcx43D9Hl110Q+BABABg lkrPkES/VyMZsfuds8fcDGvGE3o5UfjSno4sij0xdKut8zMazv8/4VMKPCA3EUS0tDUoL01u gDdqwlyXuYizeXyH2ICAQfXMtS+raz7mf741CZvO50OxMUMxqljeRfVPDJQJNHOYi2pxuxgj KDYx4hdZ9G2o+oLlHhu5+anMDkE8g0tffjRKn8I1D1BmrDdWR/IdbBOj6870abYvqys1qYlP otv5N5dm+XxQ8vlrvY7+kfQaAYeO3rP1DM8BGdpEqyFVa+I0rpJPhaZkeWW7cImDQFerHW9b KzBrCC815a3WrEhNpxh72ZJZNs1HYJ+29NTB6uu4NJjaMxpk+g2puNSm4b9uVjBbPO9V6sFS G+IBqE9ckX/1XjzJtY8Grqoo4SiRb6zcHhp3mxj3oqWi8SKNohAOKnUc7RIP6ss1hqIFyv0x XZor4N9tnzD0Fo0JDIURjDPEgo5WTdti/MdGTmKFQNqxyZuT9uSI2Xvhz8p+4pCYkiZqpahZ lHqMFxdw9XRZQgrP+cgtOkWEaiNkRBbvtvLdp7MCL2OsQhQEdEbUvDM9slzZXdI7NjJokVBq 3O4pls3VD2z3L/bHVBe0rBERjyM2C/HSIh84rfmAqBgklzIOqXhd+4RzadUwggdXMIIFP6AD AgECAhEAmnB4vIupZbIWfSPPv0f0RTANBgkqhkiG9w0BAQwFADBGMQswCQYDVQQGEwJOTDEZ MBcGA1UEChMQR0VBTlQgVmVyZW5pZ2luZzEcMBoGA1UEAxMTR0VBTlQgUGVyc29uYWwgQ0Eg NDAeFw0yNDAxMDkwMDAwMDBaFw0yNTAxMDgyMzU5NTlaMIHRMQswCQYDVQQGEwJOTDETMBEG A1UECBMKR2VsZGVybGFuZDE3MDUGA1UEChMuU3RpY2h0aW5nIEludGVybmV0IERvbWVpbnJl Z2lzdHJhdGllIE5lZGVybGFuZDEXMBUGA1UEYRMOTlRSTkwtNDEyMTU3MjQxIzAhBgkqhkiG 9w0BCQEWFG1hcmNvLmRhdmlkc0BzaWRuLm5sMQ8wDQYDVQQEEwZEYXZpZHMxDjAMBgNVBCoT BU1hcmNvMRUwEwYDVQQDEwxNYXJjbyBEYXZpZHMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQDHIhZewB/RFdtO2ROri1XWRcuHqyBXouCE34AeIThxOBtIAPKopImk815Ep7jQ vYIKlcacL1usfc3ef26pl7m5BIS0Ph7Q0PrLWyvlNb1qaHMuv/XJfPlRBPAuKYFVqqjks5tc OTBL4fmtN52oN4EA7u3XoNzw6QcUa3jCuS1Sf/WWR/cKGDRUfqweh/eKwNrb7AuA4+s4tG1I aAbS/GKF8B41X1moJCYxXGHbnm+IBpyZgFrkxOc4LbxgcSHTmf9pG59dqpBQ3HIgN9QbY9DR S5/SCrZOkq7p6JxhV4c6ckFGt3A8/a/WjHJBKqx5V42BYJj12HGPG+0w0W0FjvIemoOpw/5b k+lnzAY8oRtJljLxOJF99KCkNPkU04MoYxJ74JDSoxsBCK40UZ9pY4ClPrkQwXmAoKfwCy5i kyn8r9Y605qiQIfqamnDSaVSX/x5SEr5wIZ/Oysl+9uubxIgSAUTlu2IqlpiRU+kEES0rKRq u8HVL2LsmLYU/PjtcJOqUItP3K5Rn7R+aNRAxrPRkcG1Ba0ZiPBC/2RR3tgeDoEsMYeKk7In 561h6tZJjqsZE7F5dba7jE8HnAOAf6dSs8+hOioHyctdZModERtbufHoNrDG35cLMi0txKZN wj9Vdjd7ZKCFb7BSYwpRqBrKbOprQd4hMDGMw/JYy25zawIDAQABo4IBsjCCAa4wHwYDVR0j BBgwFoAUaQChxyFY+ODFGyCwCt2nUb8T2eQwHQYDVR0OBBYEFFr+vgLHBkpLfeDBYLMKzi/4 sv3AMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBQBgNVHSAESTBHMDoGDCsGAQQBsjEBAgEKBDAqMCgGCCsGAQUFBwIBFhxo dHRwczovL3NlY3RpZ28uY29tL1NNSU1FQ1BTMAkGB2eBDAEFAwIwQgYDVR0fBDswOTA3oDWg M4YxaHR0cDovL0dFQU5ULmNybC5zZWN0aWdvLmNvbS9HRUFOVFBlcnNvbmFsQ0E0LmNybDB4 BggrBgEFBQcBAQRsMGowPQYIKwYBBQUHMAKGMWh0dHA6Ly9HRUFOVC5jcnQuc2VjdGlnby5j b20vR0VBTlRQZXJzb25hbENBNC5jcnQwKQYIKwYBBQUHMAGGHWh0dHA6Ly9HRUFOVC5vY3Nw LnNlY3RpZ28uY29tMB8GA1UdEQQYMBaBFG1hcmNvLmRhdmlkc0BzaWRuLm5sMA0GCSqGSIb3 DQEBDAUAA4ICAQAhLXzR407ZcmRw5bl1p68z1Ix8NrIi5oN0J9SxjqD3sNMY7LG68eLXyMRF FUZOg2Xc/3yaLEQAEmB8a5APaT6P0w8qUXWCo31MLkTN9YKD4d+eNoAw0av/rJLTf7Mo3ZK/ G1iD4lpfe6nuKFE/xPM0k0DPWTPKzmagsVNIyAyPMhT/fP83N98VWZkjzTvqmApvL98gLHuN J2dgOnkbndGvX6ayxXRnFQpv6oL3dZVElWXaPZksimvnB3qNO33vckD6LvWmYakYJLEI6LtY zHG269YG5F9NIU1gpCL5P/74OlWZLBZwh/VugiN9O3lH5IT1okKVp1MRKLCFPGVggzPjUFe0 CVbTZgAkhHX0zko0u7Ami68SGJh6o3K+VlThkBoYzlxE4LB4KIW8duggn6JvRnUoVQnofLMz Z7qm401o8mj5dPrGLu5oUdgN/0/1lY1iDYk0tUg/GnLCtfcq4N3BdO8+32eg0bDMlObDJeZL Wa/9p1bDmyf1zsOyRmohYOfv/GhSkvQ5owmong8xIJ+a92CrN9BqmpsM1Hh2nltiI2YrQ74v YVovpa5XxV5ElQrAQmn9VkNslO1X9V+XoQxQHqB4Zv94FZrT94IVn8pNs8XwJOj54X4tf0yo QuQigJcTptXqqQTIrMQGXopXyg57bDrsvF9ZRd64EX+UbM2t2jGCBUgwggVEAgEBMFswRjEL MAkGA1UEBhMCTkwxGTAXBgNVBAoTEEdFQU5UIFZlcmVuaWdpbmcxHDAaBgNVBAMTE0dFQU5U IFBlcnNvbmFsIENBIDQCEQCacHi8i6llshZ9I8+/R/RFMA0GCWCGSAFlAwQCAwUAoIICvjAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yNDExMjAxNTQzMDFa ME8GCSqGSIb3DQEJBDFCBEAR46xvHNbu6FU5n+hckEVPAIW6jyZc1MglvPrh40Shf7cI8siG Nl/zroPlBiBWkA2WPmLW7fNNxxIO1Q//VgDRMGoGCSsGAQQBgjcQBDFdMFswRjELMAkGA1UE BhMCTkwxGTAXBgNVBAoTEEdFQU5UIFZlcmVuaWdpbmcxHDAaBgNVBAMTE0dFQU5UIFBlcnNv bmFsIENBIDQCEQCacHi8i6llshZ9I8+/R/RFMGwGCyqGSIb3DQEJEAILMV2gWzBGMQswCQYD VQQGEwJOTDEZMBcGA1UEChMQR0VBTlQgVmVyZW5pZ2luZzEcMBoGA1UEAxMTR0VBTlQgUGVy c29uYWwgQ0EgNAIRAJpweLyLqWWyFn0jz79H9EUwggFXBgkqhkiG9w0BCQ8xggFIMIIBRDAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA0GCCqGSIb3DQMCAgEFMA0G CCqGSIb3DQMCAgEFMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEFMAcGBSsOAwIaMAsGCWCGSAFl AwQCATALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCBDALBglghkgBZQME AgcwCwYJYIZIAWUDBAIIMAsGCWCGSAFlAwQCCTALBglghkgBZQMEAgowCwYJKoZIhvcNAQEB MAsGCSuBBRCGSD8AAjAIBgYrgQQBCwAwCAYGK4EEAQsBMAgGBiuBBAELAjAIBgYrgQQBCwMw CwYJK4EFEIZIPwADMAgGBiuBBAEOADAIBgYrgQQBDgEwCAYGK4EEAQ4CMAgGBiuBBAEOAzAN BgkqhkiG9w0BAQEFAASCAgCLR5CHLpKKdOimKqwhqVUohd/++SrDCB3ulRmA6Y3OopxNGqoo lEP5fVJfWIYQhSY8bsTVF6VtF55tm/r0K8wj1EVhklDvuj+GG3j7We0OtnJ0/LG7rbOzIifo UU7VwK4EDrAJT4N/OejB4zQF/UtEQwADbLAanhKAF1VRWH8/+UojyCmaKWMPNtTGwSJg4orH zPVx1Fs5sHtbFMf7aG132By+Qvzo66mH70J1h9VC5jchMRSyKwdM8GKGHFmuTIr7n9W/H4/b q7beQEEqbWbP9Kej7QOrLkwTQPL13vCpggazSm22t1bdVGl+k474FvVfvyQE9GdUFTVqJ22U n/ALMZ1ENTDtQ4Q6bG1gdz3e6gsgmq5FGpS2M49cp/xloQeCGcTpHG8TL2whKzO6TYXqoym5 uZeWpgVMu0wCKoW0eF3dNZodJZZ3/FXvX7sNDNFM2B/MRmdFwza0V8+rB70eKhP/w0fYgZ8N dYuH/pkl19ZxB9+jVLu2sBNpVcpS7qLJZmZOsqwiKvWptfeUYhLHvjBxTnQ59q3JpHAw7kIp 8qfXXJUZ9MXcn/i0LOMt1gNVMYYuddkHiSlgDYu8cOsa2mx5gtq8t/BH92IkNAbkp/L7pWm3 fvURkzI2KSnpcPQb9591NFmvblFEcDU4FNRuJc8Xpk0exiG8rhj/AHrr2AAAAAAAAA==

--------------ms040100050004020906060004--

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Wed, 20 Nov 2024 15:48:00 -0000 (UTC), "\"Marco Davids
(SIDN)\" via questions Mailing List" <questions@lists.ntp.org>
wrote:

Hi,

On Wed, 20 Nov 2024 10:34:50 +0000 Roger wrote:

I had assumed that ntpd would mobilize a few servers and choose
one to replace the unreachable server.

How did you configure the NTP pool in your ntp.conf?

With the 'server'-directive perhaps?

No, I am using "pool 0.pool.ntp.org poll 11" (and 1. 2. 3. as
well). This is why I thought the non-responding server would
be replaced. If I had used "server 178.238.156.140" then I would
expect ntpd to keep trying to get an answer.
--
Roger
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 2024-11-20 10:11, Roger wrote:

On Wed, 20 Nov 2024 15:48:00 -0000 (UTC), "\"Marco Davids
(SIDN)\" via questions Mailing List" wrote:

On Wed, 20 Nov 2024 10:34:50 +0000 Roger wrote:

I had assumed that ntpd would mobilize a few servers and choose
one to replace the unreachable server.

How did you configure the NTP pool in your ntp.conf?

With the 'server'-directive perhaps?

No, I am using "pool 0.pool.ntp.org poll 11" (and 1. 2. 3. as
well). This is why I thought the non-responding server would
be replaced. If I had used "server 178.238.156.140" then I would
expect ntpd to keep trying to get an answer.

Maybe add "iburst preempt" options and drop "poll 11" or perhaps change to "maxpoll 11" or higher, unless you have very good reasons to require a longer interval than the default maximum, instead of adaptive polling based on the error.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada

La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien |a ajouter not when there is no more to add mais lorsqu'il n'y a plus rien |a retirer but when there is no more to cut
-- Antoine de Saint-Exup|-ry

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Wed, 20 Nov 2024 19:53:00 -0000 (UTC),
brian.inglis@systematicsw.ab.ca wrote:

On 2024-11-20 10:11, Roger wrote:

On Wed, 20 Nov 2024 15:48:00 -0000 (UTC), "\"Marco Davids
(SIDN)\" via questions Mailing List" wrote:

On Wed, 20 Nov 2024 10:34:50 +0000 Roger wrote:

I had assumed that ntpd would mobilize a few servers and choose
one to replace the unreachable server.

How did you configure the NTP pool in your ntp.conf?

With the 'server'-directive perhaps?

No, I am using "pool 0.pool.ntp.org poll 11" (and 1. 2. 3. as
well). This is why I thought the non-responding server would
be replaced. If I had used "server 178.238.156.140" then I would
expect ntpd to keep trying to get an answer.

Maybe add "iburst preempt" options and drop "poll 11" or perhaps change to >"maxpoll 11" or higher, unless you have very good reasons to require a longer >interval than the default maximum, instead of adaptive polling based on the error.

Well, the documentation (confopt) tells me that the pool command
"mobilizes a preemptable pool client mode association for the
DNS name specified." Why would adding "preempt" change anything?

Although I have "pool ... poll 11" the poll does shorten
sometimes, going down to poll 6 if necessary. It seems to be
when the temperature (whether ambient or due to processor load)
changes too quickly.

My question is why would a preemptable server, acquired using
"pool ...", continue to be polled after it has stopped
responding, i.e., the reach has gone to 0? It is a
misunderstanding on my part or is there an bug in the code?
--
Roger
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 2024-11-20 14:32, Roger wrote:

On Wed, 20 Nov 2024 19:53:00 -0000 (UTC), Brian Inglis wrote:

On 2024-11-20 10:11, Roger wrote:

On Wed, 20 Nov 2024 15:48:00 -0000 (UTC), "\"Marco Davids
(SIDN)\" via questions Mailing List" wrote:

On Wed, 20 Nov 2024 10:34:50 +0000 Roger wrote:

I had assumed that ntpd would mobilize a few servers and choose
one to replace the unreachable server.

How did you configure the NTP pool in your ntp.conf?

With the 'server'-directive perhaps?

No, I am using "pool 0.pool.ntp.org poll 11" (and 1. 2. 3. as
well). This is why I thought the non-responding server would
be replaced. If I had used "server 178.238.156.140" then I would
expect ntpd to keep trying to get an answer.

Maybe add "iburst preempt" options and drop "poll 11" or perhaps change to >> "maxpoll 11" or higher, unless you have very good reasons to require a longer
interval than the default maximum, instead of adaptive polling based on the error.

Well, the documentation (confopt) tells me that the pool command
"mobilizes a preemptable pool client mode association for the
DNS name specified." Why would adding "preempt" change anything?

It *may* be required and can never hurt:

$ grep 'pool.*preempt' ~/src/time/ntp/ntp-4.2.8p18/ntpd/complete.conf.in
pool 2.ubuntu.pool.ntp.org. iburst preempt

$ man 5 ntp.conf
...
Configuration Commands
...
*pool* For type s addresses, this command mobilizes a persistent
client mode association with a number of remote servers. In
this mode the local clock can synchronized to the remote server,
but the remote server can never be synchronized to the local
clock.
...
Options:
...
*preempt* Says the association can be preempted.
...
This manual page was AutoGenrCEerated from the ntp.conf option definitions.

4.2.8p18 25 May 2024 ntp.conf(5man)

although the older:

https://www.ntp.org/documentation/4.2.8-series/confopt/#server-commands

says:

"Server Commands and Options
Last update: March 23, 2023 21:05 UTC (6ad51a76f)
...
Server Commands
...
pool
For type s addresses (only) this command mobilizes a preemptable pool client mode association for the DNS name specified. "
...
Server Command Options
...
preempt
Specifies the association as preemptable rather than the default persistent. This option is ignored with the broadcast command and is most useful with the manycastclient and pool commands."

Although I have "pool ... poll 11" the poll does shorten
sometimes, going down to poll 6 if necessary. It seems to be
when the temperature (whether ambient or due to processor load)
changes too quickly.

My question is why would a preemptable server, acquired using
"pool ...", continue to be polled after it has stopped
responding, i.e., the reach has gone to 0? It is a
misunderstanding on my part or is there an bug in the code?

Or a doc bug?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada

La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien |a ajouter not when there is no more to add mais lorsqu'il n'y a plus rien |a retirer but when there is no more to cut
-- Antoine de Saint-Exup|-ry

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Thu, 21 Nov 2024 17:03:00 -0000 (UTC), "Brian Inglis" <Brian.Inglis@SystematicSW.ab.ca> wrote:

HUGE snip

Or a doc bug?

Thank you. That's interesting. I was looking at confopt.html
contained within the ntp-4.2.8p18 source tree. I see that its
file date is 2020-03-03 whereas the man page has a file date of
2024-05-25. I shall now add preempt to my pool lines.
--
Roger
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--000000000000298b9a062779531c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 20, 2024 at 11:51=E2=80=AFAM Roger <invalid@invalid.invalid> wr= ote:

I had assumed that ntpd would mobilize a few servers and choose
one to replace the unreachable server. Why assume this? If the
server had been removed from the pool then sending packets
forever would be wrong. However, there were no new mobilization
attempts, the server came back with the same association number.

In this instance it was an "internet malfunction", see graphs on
link below.

https://www.ntppool.org/a/markcpowell

Was my expectation wrong?

Sadly, yes.

Did Dave Hart's ntp-dev-3792-msm-v2 contain such code which
didn't yet get into the released code?

Yes, that code has not been released yet, and as it's based on the source
code from about two years ago, it's going to be a bit painful to merge into
the current code. The 3792 test release code contains logic to gradually refine the pool servers by removing one at a time when certain conditions
are met, and not responding for 10 poll intervals is one of those
conditions. It may also contain code I worked on around the same time to re-resolve the DNS name of non-pool servers when they haven't responded in
a while, to allow NTP server operators to change the DNS and (eventually,
once the code is widespread) see clients move over to the new IP
address(es). This would also help with folks who have followed the instructions at https://www.ntppool.org/en/use.html which suggest using " server" not "pool" with the *.pool.ntp.org DNS names, as they would also
then move from no-longer-responsive pool servers to a different one.

I haven't attempted to integrate either one because I consider the changes
too disruptive for a stable point release, and since I wrote that code,
there have been only stable point releases. I have been begging NTP
release management to restart ntp-dev testing releases for over two years
now, so I could integrate the code and it could get more widespread testing
of these changes before it hopefully makes it into a stable release in a reasonable timeframe.

I've been told the entire time that ntp-dev would be revived from its 2019 dormancy soon for the past two-plus years, so I'm a bit jaded about the prospects, despite hearing it really is very close to happening now. In
the meantime, I've been kept more than busy fixing bugs and adding less disruptive improvements to the ntp-stable releases.

I'll have another response shortly to a different post in this thread.
Cheers,
Dave Hart

--000000000000298b9a062779531c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><div class=3D"gmail_default" style= =3D"font-family:&quot;trebuchet ms&quot;,sans-serif"></div></div></div><br>= <div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, No=
v 20, 2024 at 11:51=E2=80=AFAM Roger &lt;invalid@invalid.invalid&gt; wrote:= <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I had assumed that ntpd would mobilize a few servers and choose<br>
one to replace the unreachable server. Why assume this? If the<br>
server had been removed from the pool then sending packets<br>
forever would be wrong. However, there were no new mobilization<br>
attempts, the server came back with the same association number.<br>

In this instance it was an &quot;internet malfunction&quot;, see graphs on<=

link below.<br>

=C2=A0 =C2=A0 <a href=3D"https://www.ntppool.org/a/markcpowell" rel=3D"nore= ferrer" target=3D"_blank">https://www.ntppool.org/a/markcpowell</a><br>

Was my expectation wrong?<br></blockquote><div><br></div><div><div class=3D= "gmail_default" style=3D"font-family:&quot;trebuchet ms&quot;,sans-serif">S= adly, yes.</div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd= ing-left:1ex">
Did Dave Hart&#39;s ntp-dev-3792-msm-v2 contain such code which<br>
didn&#39;t yet get into the released code?<br></blockquote><div><br></div><= div class=3D"gmail_default" style=3D""><span style=3D"font-family:&quot;tre= buchet ms&quot;,sans-serif">Yes, that code has not been released yet, and a=
s it&#39;s based on the source code from about two years ago, it&#39;s goin=
g to be a bit painful to merge into the current code.=C2=A0 The 3792 test r= elease code contains logic to gradually refine the pool servers by removing=
one at a time when certain conditions are met, and not responding for 10 p= oll intervals is one of those conditions.=C2=A0 It may also contain code I = worked on around the same time to re-resolve the DNS name of non-pool serve=
rs when they haven&#39;t responded in a while, to allow NTP server operator=
s to change the DNS and (eventually, once the code is widespread) see clien=
ts move over to the new IP address(es).=C2=A0 This would also help with fol=
ks who have followed the instructions at=C2=A0<a href=3D"https://www.ntppoo= l.org/en/use.html">https://www.ntppool.org/en/use.html</a> which suggest us= ing &quot;</span><font face=3D"monospace">server</font><span style=3D"font-= family:&quot;trebuchet ms&quot;,sans-serif">&quot; not &quot;</span><font f= ace=3D"monospace">pool</font><font face=3D"trebuchet ms, sans-serif">&quot;=
with the *.<a href=3D"http://pool.ntp.org">pool.ntp.org</a> DNS names, as = they would also then move from no-longer-responsive pool servers to a diffe= rent one.</font></div><div class=3D"gmail_default" style=3D""><font face=3D= "trebuchet ms, sans-serif"><br></font></div><div class=3D"gmail_default" st= yle=3D""><font face=3D"trebuchet ms, sans-serif">I haven&#39;t attempted to=
integrate either one because I consider the changes too disruptive for a s= table point release, and since I wrote that code, there have been only stab=
le point releases.=C2=A0 I have been begging NTP release management to rest= art ntp-dev testing releases for over two years now, so I could integrate t=
he code and it could get more widespread testing of these changes before it=
hopefully makes it into a stable release in a reasonable timeframe.</font>= </div><div class=3D"gmail_default" style=3D""><font face=3D"trebuchet ms, s= ans-serif"><br></font></div><div class=3D"gmail_default" style=3D""><font f= ace=3D"trebuchet ms, sans-serif">I&#39;ve been told the entire time that nt= p-dev would be revived from its 2019 dormancy soon for the past two-plus ye= ars, so I&#39;m a bit jaded about the prospects, despite hearing it=C2=A0re= ally is very close to happening now.=C2=A0 In the meantime, I&#39;ve been k= ept more than busy fixing bugs and adding less disruptive improvements to t=
he ntp-stable releases.</font></div><div class=3D"gmail_default" style=3D""= ><font face=3D"trebuchet ms, sans-serif"><br></font></div><div class=3D"gma= il_default" style=3D""><font face=3D"trebuchet ms, sans-serif">I&#39;ll hav=
e another response shortly to a different post in this thread.</font></div>= <div class=3D"gmail_default" style=3D"font-family:&quot;trebuchet ms&quot;,= sans-serif"></div><div><div dir=3D"ltr" class=3D"gmail_signature"><div dir= =3D"ltr"><font face=3D"tahoma, sans-serif" color=3D"#666666">Cheers,<br>Dav=
e Hart</font></div></div></div><br class=3D"gmail-Apple-interchange-newline= "></div></div>

--000000000000298b9a062779531c--

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--000000000000a9230e06277965d7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 20, 2024 at 6:10=E2=80=AFPM Roger <invalid@invalid.invalid> wro= te:

On Wed, 20 Nov 2024 15:48:00 -0000 (UTC), "\"Marco Davids
(SIDN)\" via questions Mailing List" <questions@lists.ntp.org>
wrote:

How did you configure the NTP pool in your ntp.conf?

With the 'server'-directive perhaps?

No, I am using "pool 0.pool.ntp.org poll 11" (and 1. 2. 3. as
well). [...]

Are you sure you didn't mean "maxpoll 11"? My reading of the code suggests
the line you provided would be rejected as a syntax error by ntpd.

Cheers,
Dave Hart

--000000000000a9230e06277965d7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>On Wed, Nov 20, 2024 at 6:10=E2=80= =AFPM Roger &lt;invalid@invalid.invalid&gt; wrote:</div></div><div class=3D= "gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 20 = Nov 2024 15:48:00 -0000 (UTC), &quot;\&quot;Marco Davids<br>
(SIDN)\&quot; via questions Mailing List&quot; &lt;<a href=3D"mailto:questi= ons@lists.ntp.org" target=3D"_blank">questions@lists.ntp.org</a>&gt;<br> wrote:<br>
<br>&gt;How did you configure the NTP pool in your ntp.conf?<br>
&gt;<br>
&gt;With the &#39;server&#39;-directive perhaps?<br>

No, I am using &quot;pool <a href=3D"http://0.pool.ntp.org" rel=3D"noreferr= er" target=3D"_blank">0.pool.ntp.org</a> poll 11&quot; (and 1. 2. 3. as<br> well).=C2=A0<span class=3D"gmail_default" style=3D""><font face=3D"monospac= e">[...]</font></span></blockquote><div><br></div><div class=3D"gmail_defau= lt" style=3D""><span style=3D"font-family:&quot;trebuchet ms&quot;,sans-ser= if">Are you sure you didn&#39;t mean &quot;</span><font face=3D"monospace">= maxpoll 11</font><font face=3D"trebuchet ms, sans-serif">&quot;?=C2=A0 My r= eading of the code suggests the line you provided would be rejected as a sy= ntax error by ntpd.</font></div><div class=3D"gmail_default" style=3D""><fo=
nt face=3D"trebuchet ms, sans-serif"><br></font></div><div class=3D"gmail_d= efault" style=3D""><font face=3D"trebuchet ms, sans-serif">Cheers,</font></= div><div class=3D"gmail_default" style=3D""><font face=3D"trebuchet ms, san= s-serif">Dave Hart</font></div></div></div>

--000000000000a9230e06277965d7--

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--00000000000017cf8706277a0a49
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 21, 2024 at 4:56=E2=80=AFPM Brian Inglis < Brian.Inglis@systematicsw.ab.ca> wrote:

On 2024-11-20 14:32, Roger wrote:

On Wed, 20 Nov 2024 19:53:00 -0000 (UTC), Brian Inglis wrote:

Maybe add "iburst preempt" options and drop "poll 11" or perhaps change

to

"maxpoll 11" or higher, unless you have very good reasons to require a longer
interval than the default maximum, instead of adaptive polling based o=

n

the error.

Well, the documentation (confopt) tells me that the pool command
"mobilizes a preemptable pool client mode association for the
DNS name specified." Why would adding "preempt" change anything?

It *may* be required and can never hurt:

In fact it won't change anything. The only options propagated from the "
pool" directive in ntp.conf (and thereby set on the prototype pool
association listed with refid POOL in the peers billboard) to the resulting pool server associations are "iburst" and "noselect". See POOL_FLAG_PMASK
in source code file ntp_proto.c.

The preemptible option is forced on for pool servers, so they are
preemptible with or without that option. However, that option doesn't do
much in 4.2.8 as the code intended to preempt useless servers has an
off-by-one error that's corrected in my test 3792 release, so preemption
only happens in the unusual case where there are more than 2 times as many
pool or manycast client associations as "tos maxclock" which defaults to
10. Arguably this could be fixed in the stable 4.2.8 branch but it would
be a substantial change in behavior without any configuration change that
might break existing setups that depend on the off-by-one error.

As an aside, using "preempt" on a non-pool non-manycastclient association (basically, configured via "server" or "peer") seems quixotic to me, as it allows the association to be removed but nothing is done to replace it. I
have a difficult time imagining where that might be useful. It may have
been useful in the pre-2009 implementation of "pool" which I'm having a
hard time remembering because I thought it was primitive and needed improvement, as it did all its work at startup and never changed the
servers selected once up and running. I re-implemented it to the current iteration, but didn't catch that the preemption was suffering the aforementioned off-by-one error, or it wasn't back then.

If you're wondering why I mentioned "manycastclient", it shares much of the implementation with "pool". They use different approaches to finding
servers, but the rest of the code is common. Both are intended to be
automatic server discovery schemes that discard, or preempt, servers which haven't been useful for 10 poll intervals so that another server can be solicited to replace it.

$ grep 'pool.*preempt' ~/src/time/ntp/ntp-4.2.8p18/ntpd/complete.conf.in
pool 2.ubuntu.pool.ntp.org. iburst preempt

complete.conf.in is part of the "make check" tests and is not intended to suggest useful configurations. Rather it's used both to ensure every
keyword in the configuration file parser is covered, and to ensure a configuration can successfully round-trip through ntpd's reading and
applying the configuration and exporting the configuration via the --saveconfigquit command-line option added specifically for that developer
test to catch changes which break that functionality. It's no coincidence =
it
is ordered exactly the same as the output of ntpq's saveconfig command,
which requires authentication and that a directory for such saved
configuration files has been specified in ntp.conf with "saveconfigdir".

$ man 5 ntp.conf
...
Configuration Commands
...
*pool* For type s addresses, this command mobilizes a persistent
client mode association with a number of remote servers. In
this mode the local clock can synchronized to the remote server,
but the remote server can never be synchronized to the local
clock.
...
Options:
...
*preempt* Says the association can be preempted.
...
This manual page was AutoGen=E2=80=90erated from the ntp.conf option defi=

nitions.

4.2.8p18 25 May 2024 ntp.conf(5man)

although the older:

https://www.ntp.org/documentation/4.2.8-series/confopt/#server-commands

says:

"Server Commands and Options
Last update: March 23, 2023 21:05 UTC (6ad51a76f)
...
Server Commands
...
pool
For type s addresses (only) this command mobilizes a preemptable pool
client
mode association for the DNS name specified. "
...
Server Command Options
...
preempt
Specifies the association as preemptable rather than the default
persistent.
This option is ignored with the broadcast command and is most useful with
the
manycastclient and pool commands."

Despite the timestamps you quoted, the web version is likely newer.
Autogen is run against the documentation source files with every release,
so that timestamp reflects the release date, not the last update of the documentation source files (.html in this case).

Since the overhaul of the www.ntp.org website a few years back, that documentation sadly is maintained in two places, and there's no process to ensure they stay in sync. The web version is considered the more
authoritative source, and is maintained in .md (Markdown) published only
via the converted HTML on the website. It started as a copy of the documentation from the source tarballs' /html directory, but after
conversion to Markdown and subsequent improvements, those changes have generally not been made to the HTML version distributed with the source.
I'm partly to blame because I find writing documentation tedious enough
without having to update it in two places, and I've been kept quite busy
with coding work and haven't wanted to take the time to correct
documentation that no longer reflects the reality of the code. In theory
one day I will have time to dedicate to that, but I welcome anyone who
enjoys documentation work or at least really wants accurate NTP
documentation to please volunteer to help out.

My question is why would a preemptable server, acquired using
"pool ...", continue to be polled after it has stopped
responding, i.e., the reach has gone to 0? It is a
misunderstanding on my part or is there an bug in the code?

Or a doc bug?

A doc bug and an off-by-one bug in the preemption logic.

Cheers,
Dave Hart

--00000000000017cf8706277a0a49
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:&quot;trebuchet ms&quot;,sans-serif"><br></div></div><br><div clas= s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 21, 202=
4 at 4:56=E2=80=AFPM Brian Inglis &lt;<a href=3D"mailto:Brian.Inglis@system= aticsw.ab.ca">Brian.Inglis@systematicsw.ab.ca</a>&gt; wrote:<br></div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:= 1px solid rgb(204,204,204);padding-left:1ex">On 2024-11-20 14:32, Roger wro= te:<br>
&gt; On Wed, 20 Nov 2024 19:53:00 -0000 (UTC), Brian Inglis wrote:=C2=A0</b= lockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt;&gt; Maybe add &quot;iburst preempt&quot; options and drop &quot;poll 1= 1&quot; or perhaps change to<br>
&gt;&gt; &quot;maxpoll 11&quot; or higher, unless you have very good reason=
s to require a longer<br>
&gt;&gt; interval than the default maximum, instead of adaptive polling bas=
ed on the error.<br>
&gt; <br>
&gt; Well, the documentation (confopt) tells me that the pool command<br>
&gt; &quot;mobilizes a preemptable pool client mode association for the<br> &gt; DNS name specified.&quot; Why would adding &quot;preempt&quot; change = anything?<br>

It *may* be required and can never hurt:<br></blockquote><div><br></div><di= v><div class=3D"gmail_default" style=3D""><span style=3D"font-family:&quot;= trebuchet ms&quot;,sans-serif">In fact it won&#39;t change anything.=C2=A0 = The only options propagated from the &quot;</span><font face=3D"monospace">= pool</font><font face=3D"trebuchet ms, sans-serif">&quot; directive in ntp.= conf (and thereby set on the prototype=C2=A0pool association listed with re= fid </font><font face=3D"monospace">POOL</font><font face=3D"trebuchet ms, = sans-serif"> in the peers billboard) to the resulting pool server associati= ons are &quot;</font><font face=3D"monospace">iburst</font><font face=3D"tr= ebuchet ms, sans-serif">&quot; and &quot;</font><font face=3D"monospace">no= select</font><font face=3D"trebuchet ms, sans-serif">&quot;.=C2=A0 See=C2= =A0POOL_FLAG_PMASK in source code file ntp_proto.c.</font></div><br></div><= div><div class=3D"gmail_default" style=3D""><span style=3D"font-family:&quo= t;trebuchet ms&quot;,sans-serif">The preemptible option is forced on for po=
ol servers, so they are preemptible with or without that option.=C2=A0 Howe= ver, that option doesn&#39;t do much in 4.2.8 as the code intended to preem=
pt useless servers has an off-by-one error that&#39;s corrected in my test = 3792 release, so preemption only happens in the unusual case where there ar=
e more than 2 times as many pool or manycast client associations as &quot;<= /span><font face=3D"monospace">tos maxclock</font><font face=3D"trebuchet m=
s, sans-serif">&quot; which defaults to 10.=C2=A0 Arguably this could be fi= xed in the stable 4.2.8 branch but it would be a substantial change in beha= vior without any configuration change that might break existing setups that=
depend on the off-by-one error.</font></div><div class=3D"gmail_default" s= tyle=3D""><font face=3D"trebuchet ms, sans-serif"><br></font></div><div cla= ss=3D"gmail_default" style=3D""><font face=3D"trebuchet ms, sans-serif">As =
an aside, using &quot;</font><font face=3D"monospace">preempt</font><font f= ace=3D"trebuchet ms, sans-serif">&quot; on a non-pool non-manycastclient=C2= =A0association (basically, configured via &quot;</font><font face=3D"monosp= ace">server</font><font face=3D"trebuchet ms, sans-serif">&quot; or &quot;<= /font><font face=3D"monospace">peer</font><font face=3D"trebuchet ms, sans-= serif">&quot;) seems quixotic to me, as it allows the association to be rem= oved but nothing is done to replace it.=C2=A0 I have a difficult time imagi= ning where that might be useful.=C2=A0 It may have been useful in the pre-2= 009 implementation of &quot;</font><font face=3D"monospace">pool</font><fon=
t face=3D"trebuchet ms, sans-serif">&quot; which I&#39;m having a hard time=
remembering because I thought it was primitive and needed improvement, as =
it did all its work at startup and never changed the servers selected once =
up and running.=C2=A0 I re-implemented it to the current iteration, but did= n&#39;t catch that the preemption was suffering the aforementioned off-by-o=
ne error, or it wasn&#39;t back then.</font></div><div class=3D"gmail_defau= lt" style=3D""><font face=3D"trebuchet ms, sans-serif"><br></font></div><di=
v class=3D"gmail_default" style=3D""><font face=3D"trebuchet ms, sans-serif= ">If you&#39;re wondering why I mentioned &quot;</font><font face=3D"monosp= ace">manycastclient</font><font face=3D"trebuchet ms, sans-serif">&quot;, i=
t shares much of the implementation with &quot;</font><font face=3D"monospa= ce">pool</font><font face=3D"trebuchet ms, sans-serif">&quot;.=C2=A0 They u=
se different approaches to finding servers, but the rest of the code is com= mon.=C2=A0 Both are intended to be automatic server discovery schemes that = discard, or preempt, servers which haven&#39;t been useful for 10 poll inte= rvals so that another server can be solicited to replace it.</font></div></= div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
$ grep &#39;pool.*preempt&#39; ~/src/time/ntp/ntp-4.2.8p18/ntpd/<a href=3D"= http://complete.conf.in" rel=3D"noreferrer" target=3D"_blank">complete.conf= .in</a><br>
pool <a href=3D"http://2.ubuntu.pool.ntp.org" rel=3D"noreferrer" target=3D"= _blank">2.ubuntu.pool.ntp.org</a>. iburst preempt<br></blockquote><div><br>= </div><div><div class=3D"gmail_default" style=3D""><font face=3D"monospace"= ><a href=3D"http://complete.conf.in">complete.conf.in</a></font><span style= =3D"font-family:&quot;trebuchet ms&quot;,sans-serif"> is part of the &quot;= make check&quot; tests and is not intended to suggest useful configurations= .=C2=A0 Rather it&#39;s used both to ensure every keyword in the configurat= ion file parser is covered, and to ensure a configuration can successfully = round-trip through ntpd&#39;s reading and applying the configuration and ex= porting the configuration via the </span><font face=3D"monospace">--savecon= figquit</font><font face=3D"trebuchet ms, sans-serif">=C2=A0command-line op= tion added specifically for that developer test to catch changes which brea=
k that functionality.=C2=A0 It&#39;s </font>no coincidence<font face=3D"tre= buchet ms, sans-serif">=C2=A0</font>it is<font face=3D"trebuchet ms, sans-s= erif"> ordered exactly the same as the output of </font><font face=3D"monos= pace">ntpq</font><font face=3D"trebuchet ms, sans-serif">&#39;s </font><fon=
t face=3D"monospace">saveconfig</font><font face=3D"trebuchet ms, sans-seri=
f"> command, which requires authentication and that a directory for such sa=
ved configuration files has been specified in ntp.conf with &quot;</font><f= ont face=3D"monospace">saveconfigdir</font><font face=3D"trebuchet ms, sans= -serif">&quot;.</font></div></div><div>=C2=A0</div><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= 04,204);padding-left:1ex">
$ man 5 ntp.conf<br>
...<br>
Configuration Commands<br>
...<br>
*pool*=C2=A0 For type s addresses, this command mobilizes a persistent<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 client mode association with a number of remote=
servers. In<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this mode the local clock can synchronized to t=
he remote server,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 but the remote server can never be synchronized=
to the local<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 clock.<br>
...<br>
Options:<br>
...<br>
*preempt*=C2=A0 =C2=A0 =C2=A0 =C2=A0Says the association can be preempted.<=

...<br>
This manual page was AutoGen=E2=80=90erated from the ntp.conf option defini= tions.<br>

4.2.8p18=C2=A0 =C2=A0 =C2=A0 =C2=A0 25 May 2024=C2=A0 =C2=A0 =C2=A0ntp.conf= (5man)<br>

although the older:<br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://www.ntp.org/documentation/4.= 2.8-series/confopt/#server-commands" rel=3D"noreferrer" target=3D"_blank">h= ttps://www.ntp.org/documentation/4.2.8-series/confopt/#server-commands</a><=


says:<br>

&quot;Server Commands and Options<br>
Last update: March 23, 2023 21:05 UTC (6ad51a76f)<br>
...<br>
Server Commands<br>
...<br>
pool<br>
For type s addresses (only) this command mobilizes a preemptable pool clien=
t <br>
mode association for the DNS name specified. &quot;<br>
...<br>
Server Command Options<br>
...<br>
preempt<br>
Specifies the association as preemptable rather than the default persistent=
. <br>
This option is ignored with the broadcast command and is most useful with t=
he <br>
manycastclient and pool commands.&quot;<br></blockquote><div><br></div><div= ><div class=3D"gmail_default" style=3D"font-family:&quot;trebuchet ms&quot;= ,sans-serif">Despite the timestamps you quoted, the web version is likely n= ewer.=C2=A0 Autogen is run against the documentation source files with ever=
y release, so that timestamp reflects the release date, not the last update=
of the documentation source files (.html in this case).</div><div class=3D= "gmail_default" style=3D"font-family:&quot;trebuchet ms&quot;,sans-serif"><= br></div><div class=3D"gmail_default" style=3D"font-family:&quot;trebuchet = ms&quot;,sans-serif">Since the overhaul of the <a href=3D"http://www.ntp.or= g">www.ntp.org</a> website a few years back, that documentation sadly is ma= intained in two places, and there&#39;s no process to ensure they stay in s= ync.=C2=A0 The web version is considered the more authoritative source, and=
is maintained in .md (Markdown) published only via the converted HTML on t=
he website.=C2=A0 It started as a copy of the documentation from the source=
tarballs&#39; /html directory, but after conversion to Markdown and subseq= uent improvements, those changes have generally not been made to the HTML v= ersion distributed with the source.=C2=A0 I&#39;m partly to blame because I=
find writing documentation tedious enough without having to update it in t=
wo places, and I&#39;ve been kept quite busy with coding work and haven&#39=
;t wanted to take the time to correct documentation that no longer reflects=
the reality of the code.=C2=A0 In theory one day I will have time to dedic= ate to that, but I welcome anyone who enjoys documentation work or at least=
really wants accurate=C2=A0NTP documentation to please volunteer to help o= ut.</div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"= margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef= t:1ex">
&gt; My question is why would a preemptable server, acquired using<br>
&gt; &quot;pool ...&quot;, continue to be polled after it has stopped<br>
&gt; responding, i.e., the reach has gone to 0? It is a<br>
&gt; misunderstanding on my part or is there an bug in the code?<br>

Or a doc bug?<br></blockquote><div><br></div><div><div class=3D"gmail_defau= lt" style=3D"font-family:&quot;trebuchet ms&quot;,sans-serif">A doc bug and=
an off-by-one bug in the preemption logic.</div></div><div class=3D"gmail_= default" style=3D"font-family:&quot;trebuchet ms&quot;,sans-serif"><br></di= v><div class=3D"gmail_default" style=3D"font-family:&quot;trebuchet ms&quot= ;,sans-serif">Cheers,</div><div class=3D"gmail_default" style=3D"font-famil= y:&quot;trebuchet ms&quot;,sans-serif">Dave Hart</div></div></div>

--00000000000017cf8706277a0a49--

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 11/21/2024 12:28 PM, Roger wrote:

On Thu, 21 Nov 2024 17:03:00 -0000 (UTC), "Brian Inglis" <Brian.Inglis@SystematicSW.ab.ca> wrote:

HUGE snip

Or a doc bug?

Thank you. That's interesting. I was looking at confopt.html
contained within the ntp-4.2.8p18 source tree. I see that its
file date is 2020-03-03 whereas the man page has a file date of
2024-05-25. I shall now add preempt to my pool lines.

The dates can be misleading.

The website is now generated via Hugo, so (as best I understand) Dru
takes the man pages, converts them to Hugo, and that's what's on the
website.

So if the date of a page on the website is more recent than the date on
the man page, that doesn't mean that the content is newer, it just means
it was (at least) formatted more recently.

The intent and expectation is that if a change is made to the Hugo
version of the docs, that change is applied "upstream" as well.

The goal is to get the master documentation formatted for Hugo, and at
that point we'll be generating all of the documentation output targets
from the same (single) source documents, and the dates should then all
match.
--
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Fri, 22 Nov 2024 05:13:05 -0000 (UTC), "Dave Hart"
<davehart@gmail.com> wrote:

On Wed, Nov 20, 2024 at 6:10?PM Roger <invalid@invalid.invalid> wrote:

On Wed, 20 Nov 2024 15:48:00 -0000 (UTC), "\"Marco Davids
(SIDN)\" via questions Mailing List" <questions@lists.ntp.org>
wrote:

How did you configure the NTP pool in your ntp.conf?

With the 'server'-directive perhaps?

No, I am using "pool 0.pool.ntp.org poll 11" (and 1. 2. 3. as
well). [...]

Are you sure you didn't mean "maxpoll 11"? My reading of the code suggests >the line you provided would be rejected as a syntax error by ntpd.

You are correct. ntp.conf does have "maxpoll 11". I was
concentrating on not muddling my "pool"s and "poll"s and
missed out the "max".
--
Roger
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Fri, 22 Nov 2024 07:23:00 -0000 (UTC), "Harlan Stenn via
questions Mailing List" <questions@lists.ntp.org> wrote:

On 11/21/2024 12:28 PM, Roger wrote:

On Thu, 21 Nov 2024 17:03:00 -0000 (UTC), "Brian Inglis"
<Brian.Inglis@SystematicSW.ab.ca> wrote:

HUGE snip

Or a doc bug?

Thank you. That's interesting. I was looking at confopt.html
contained within the ntp-4.2.8p18 source tree. I see that its
file date is 2020-03-03 whereas the man page has a file date of
2024-05-25. I shall now add preempt to my pool lines.

The dates can be misleading.

The website is now generated via Hugo, so (as best I understand) Dru
takes the man pages, converts them to Hugo, and that's what's on the >website.

So if the date of a page on the website is more recent than the date on
the man page, that doesn't mean that the content is newer, it just means
it was (at least) formatted more recently.

The intent and expectation is that if a change is made to the Hugo
version of the docs, that change is applied "upstream" as well.

The goal is to get the master documentation formatted for Hugo, and at
that point we'll be generating all of the documentation output targets
from the same (single) source documents, and the dates should then all >match.

Thank you for the explanation. Unfortunately that hasn't reached
the 4.2.8p18 source tar and so "pool" is preemptable or
persistent according to where one looks. I'm sure I've read
somewhere that writing documentation is everyone's least
favourite pasttime.
--
Roger
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Fri, 22 Nov 2024 05:08:00 -0000 (UTC), "Dave Hart"
<davehart@gmail.com> wrote:

On Wed, Nov 20, 2024 at 11:51?AM Roger <invalid@invalid.invalid> wrote:

I had assumed that ntpd would mobilize a few servers and choose
one to replace the unreachable server. Why assume this? If the
server had been removed from the pool then sending packets
forever would be wrong. However, there were no new mobilization
attempts, the server came back with the same association number.

In this instance it was an "internet malfunction", see graphs on
link below.

https://www.ntppool.org/a/markcpowell

Was my expectation wrong?

Sadly, yes.

Did Dave Hart's ntp-dev-3792-msm-v2 contain such code which
didn't yet get into the released code?

Yes, that code has not been released yet, and as it's based on the source >code from about two years ago, it's going to be a bit painful to merge into >the current code. The 3792 test release code contains logic to gradually >refine the pool servers by removing one at a time when certain conditions
are met, and not responding for 10 poll intervals is one of those
conditions.

Thank you. Hopefully, you'll be successful in getting it
integrated and accepted sooner rather than later.
--
Roger
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Fri, 22 Nov 2024 05:58:00 -0000 (UTC), "Dave Hart via
questions Mailing List" <questions@lists.ntp.org> wrote:

As an aside, using "preempt" on a non-pool non-manycastclient association >(basically, configured via "server" or "peer") seems quixotic to me, as it >allows the association to be removed but nothing is done to replace it. I >have a difficult time imagining where that might be useful.

Something in the ntp.conf man page I can't get my head around is
why one would have "pool ... prefer". If one were using only one
pool line it would, presumably, result in all servers being
preferred.
--
Roger
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 11/22/2024 12:52 AM, Roger wrote:

On Fri, 22 Nov 2024 05:58:00 -0000 (UTC), "Dave Hart via
questions Mailing List" <questions@lists.ntp.org> wrote:

As an aside, using "preempt" on a non-pool non-manycastclient association
(basically, configured via "server" or "peer") seems quixotic to me, as it >> allows the association to be removed but nothing is done to replace it. I >> have a difficult time imagining where that might be useful.

Something in the ntp.conf man page I can't get my head around is
why one would have "pool ... prefer". If one were using only one
pool line it would, presumably, result in all servers being
preferred.

Note that the BUGS section of the ntp.conf man page says:

The syntax checking is not picky; some combinations of
ridiculous and even hilarious options and modes may not be
detected.

In the above case, I'd recommend looking at the code and perhaps seeing
if the description of the "prefer" options could be improved.
--
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On Fri, 22 Nov 2024 11:13:00 -0000 (UTC), "Harlan Stenn via
questions Mailing List" <questions@lists.ntp.org> wrote:

On 11/22/2024 12:52 AM, Roger wrote:

On Fri, 22 Nov 2024 05:58:00 -0000 (UTC), "Dave Hart via
questions Mailing List" <questions@lists.ntp.org> wrote:

As an aside, using "preempt" on a non-pool non-manycastclient association >>> (basically, configured via "server" or "peer") seems quixotic to me, as it >>> allows the association to be removed but nothing is done to replace it. I >>> have a difficult time imagining where that might be useful.

Something in the ntp.conf man page I can't get my head around is
why one would have "pool ... prefer". If one were using only one
pool line it would, presumably, result in all servers being
preferred.

Note that the BUGS section of the ntp.conf man page says:

The syntax checking is not picky; some combinations of
ridiculous and even hilarious options and modes may not be
detected.

I'd forgotten that. I've reached the age where I sometimes feel
as though I've forgotten more than I ever knew.

In the above case, I'd recommend looking at the code and perhaps seeing
if the description of the "prefer" options could be improved.

That might be beyond my capabilities. The pool options given in
the ntp.conf man page are:

pool address [burst] [iburst] [version version] [prefer]
[minpoll minpoll] [maxpoll maxpoll] [xmtnonce]

Removing "[prefer]" would be a good idea.

The explanation of "prefer" seems okay; the words "this host
will be chosen" imply that only one server should be marked
thus.
--
Roger
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--00000000000052e70e06278133f6
Content-Type: text/plain; charset="UTF-8"

...
On Thu, Nov 21, 2024, 21:56 Dave Hart <questions@lists.ntp.org> wrote:

The preemptible option is forced on for pool servers, so they are
preemptible with or without that option. However, that option doesn't do much in 4.2.8 as the code intended to preempt useless servers has an off-by-one error that's corrected in my test 3792 release, so preemption
only happens in the unusual case where there are more than 2 times as many pool or manycast client associations as "tos maxclock" which defaults to
10. Arguably this could be fixed in the stable 4.2.8 branch but it would
be a substantial change in behavior without any configuration change that might break existing setups that depend on the off-by-one error.

I suppose the possibility of preempt causing ntp to kick out the pool entry itself is unthinkable.

As an aside, using "preempt" on a non-pool non-manycastclient association

(basically, configured via "server" or "peer") seems quixotic to me, as
it allows the association to be removed but nothing is done to replace it.
I have a difficult time imagining where that might be useful.

...

I have a couple of toys that set preempt for a development branch of that hostile fork we don't mention here. One queries _ntp._udp.local to add
MDNS? enabled servers. The other digs against a public domain for SRV
records to add NTS-KE servers. I thought they were the best ways to solve
those particular tasks at the time.

--00000000000052e70e06278133f6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">...<br><div class=3D"gmail_quote" dir=3D"auto"><div dir= =3D"ltr" class=3D"gmail_attr">On Thu, Nov 21, 2024, 21:56 Dave Hart &lt;<a = href=3D"mailto:questions@lists.ntp.org">questions@lists.ntp.org</a>&gt; wro= te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"lt= r"><div class=3D"gmail_default" style=3D"font-family:&quot;trebuchet ms&quo= t;,sans-serif"><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"l= tr" class=3D"gmail_attr"><span style=3D"font-family:&quot;trebuchet ms&quot= ;,sans-serif">The preemptible option is forced on for pool servers, so they=
are preemptible with or without that option.=C2=A0 However, that option do= esn&#39;t do much in 4.2.8 as the code intended to preempt useless servers = has an off-by-one error that&#39;s corrected in my test 3792 release, so pr= eemption only happens in the unusual case where there are more than 2 times=
as many pool or manycast client associations as &quot;</span><font face=3D= "monospace">tos maxclock</font><font face=3D"trebuchet ms, sans-serif">&quo=
t; which defaults to 10.=C2=A0 Arguably this could be fixed in the stable 4= .2.8 branch but it would be a substantial change in behavior without any co= nfiguration change that might break existing setups that depend on the off-= by-one error.</font></div></div></div></blockquote></div><div dir=3D"auto">= <br></div><div dir=3D"auto">I suppose the possibility of preempt causing nt=
p to kick out the pool entry itself is unthinkable.</div><div dir=3D"auto">= <br></div><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><div class=3D"gmail_= default"><font face=3D"trebuchet ms, sans-serif">As an aside, using &quot;<= /font><font face=3D"monospace">preempt</font><font face=3D"trebuchet ms, sa= ns-serif">&quot; on a non-pool non-manycastclient=C2=A0association (basical= ly, configured via &quot;</font><font face=3D"monospace">server</font><font=
face=3D"trebuchet ms, sans-serif">&quot; or &quot;</font><font face=3D"mon= ospace">peer</font><font face=3D"trebuchet ms, sans-serif">&quot;) seems qu= ixotic to me, as it allows the association to be removed but nothing is don=
e to replace it.=C2=A0 I have a difficult time imagining where that might b=
e useful.</font></div></div></div></div></blockquote></div><div dir=3D"auto= ">...</div><div dir=3D"auto"><br></div><div dir=3D"auto">I have a couple of=
toys that set preempt for a development branch of that hostile fork we don= &#39;t mention here. One queries _ntp._udp.local to add MDNS? enabled serve= rs. The other digs against a public domain for SRV records to add NTS-KE se= rvers. I thought they were the best ways to solve those particular tasks at=
the time.=C2=A0</div><div class=3D"gmail_quote" dir=3D"auto"></div></div>

--00000000000052e70e06278133f6--

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

On 2024-11-21 22:55, Dave Hart (via questions Mailing List) wrote:

On Thu, Nov 21, 2024 at 4:56rC>PM Brian Inglis <Brian.Inglis@systematicsw.ab.ca
<mailto:Brian.Inglis@systematicsw.ab.ca>> wrote:

On 2024-11-20 14:32, Roger wrote:
> On Wed, 20 Nov 2024 19:53:00 -0000 (UTC), Brian Inglis wrote:

>> Maybe add "iburst preempt" options and drop "poll 11" or perhaps change to
>> "maxpoll 11" or higher, unless you have very good reasons to require a
longer
>> interval than the default maximum, instead of adaptive polling based on
the error.
>
> Well, the documentation (confopt) tells me that the pool command
> "mobilizes a preemptable pool client mode association for the
> DNS name specified." Why would adding "preempt" change anything?

It *may* be required and can never hurt:

In fact it won't change anything.-a The only options propagated from the "pool"
directive in ntp.conf (and thereby set on the prototype-apool association listed
with refid POOLin the peers billboard) to the resulting pool server associations
are "iburst" and "noselect".-a See-aPOOL_FLAG_PMASK in source code file ntp_proto.c.

I saw that and for mcast clients in protos, and it is documented.

But it looks as if the option is set on when flagged in ntp_peer.c.

The preemptible option is forced on for pool servers, so they are preemptible
with or without that option.-a However, that option doesn't do much in 4.2.8 as
the code intended to preempt useless servers has an off-by-one error that's corrected in my test 3792 release, so preemption only happens in the unusual case where there are more than 2 times as many pool or manycast client associations as "tos maxclock" which defaults to 10.-a Arguably this could be
fixed in the stable 4.2.8 branch but it would be a substantial change in behavior without any configuration change that might break existing setups that
depend on the off-by-one error.

I am not seeing anywhere else that preempt is set on for any peers?

As an aside, using "preempt" on a non-pool non-manycastclient-aassociation (basically, configured via "server" or "peer") seems quixotic to me, as it allows the association to be removed but nothing is done to replace it.-a I have
a difficult time imagining where that might be useful.-a It may have been useful
in the pre-2009 implementation of "pool" which I'm having a hard time remembering because I thought it was primitive and needed improvement, as it did
all its work at startup and never changed the servers selected once up and running.-a I re-implemented it to the current iteration, but didn't catch that
the preemption was suffering the aforementioned off-by-one error, or it wasn't
back then.

It can be useful when you have an adequate number of (some local) backup servers
or (former) pools, but some (local) have an annoying habit of going unreachable,
but not being noticed, and support not being responsive to hints for weeks, e.g.

...
server ...
...
server ntp2.cpsc.ucalgary.ca iburst preempt # U Calgary T2N AB CA server ntp1.yycix.ca iburst preempt # YYCIX, Calgary T2P AB CA server ntp2.switch.ca iburst preempt # TELUS, Edmonton T6H AB CA ...
server ...
...
tos minsane 3 minclock 5 maxclock 7

If you're wondering why I mentioned "manycastclient", it shares much of the implementation with "pool".-a They use different approaches to finding servers,
but the rest of the code is common.-a Both are intended to be automatic server
discovery schemes that discard, or preempt, servers which haven't been useful
for 10 poll intervals so that another server can be solicited to replace it.

I noticed those comments.

$ grep 'pool.*preempt' ~/src/time/ntp/ntp-4.2.8p18/ntpd/complete.conf.in
<http://complete.conf.in>
pool 2.ubuntu.pool.ntp.org <http://2.ubuntu.pool.ntp.org>. iburst preempt

complete.conf.in <http://complete.conf.in>is part of the "make check" tests and
is not intended to suggest useful configurations.-a Rather it's used both to ensure every keyword in the configuration file parser is covered, and to ensure
a configuration can successfully round-trip through ntpd's reading and applying
the configuration and exporting the configuration via the -- saveconfigquit-acommand-line option added specifically for that developer test to
catch changes which break that functionality.-a It's no coincidenceit isordered
exactly the same as the output of ntpq's saveconfigcommand, which requires authentication and that a directory for such saved configuration files has been
specified in ntp.conf with "saveconfigdir".

Implies that pool will round trip with iburst preempt?

$ man 5 ntp.conf
...
Configuration Commands
...
*pool*-a For type s addresses, this command mobilizes a persistent
-a -a -a -a client mode association with a number of remote servers. In
-a -a -a -a this mode the local clock can synchronized to the remote server,
-a -a -a -a but the remote server can never be synchronized to the local
-a -a -a -a clock.
...
Options:
...
*preempt*-a -a -a -aSays the association can be preempted.
...
This manual page was AutoGenrCEerated from the ntp.conf option definitions.

4.2.8p18-a -a -a -a 25 May 2024-a -a -antp.conf(5man)

although the older:

https://www.ntp.org/documentation/4.2.8-series/confopt/#server-commands
<https://www.ntp.org/documentation/4.2.8-series/confopt/#server-commands>

says:

"Server Commands and Options
Last update: March 23, 2023 21:05 UTC (6ad51a76f)
...
Server Commands
...
pool
For type s addresses (only) this command mobilizes a preemptable pool client
mode association for the DNS name specified. "
...
Server Command Options
...
preempt
Specifies the association as preemptable rather than the default persistent.
This option is ignored with the broadcast command and is most useful with the
manycastclient and pool commands."

Despite the timestamps you quoted, the web version is likely newer.-a Autogen is
run against the documentation source files with every release, so that timestamp
reflects the release date, not the last update of the documentation source files
(.html in this case).

I go by the ntp.conf.def files and date-time stamps, as the html and other docs
should be Autogen-erated from these masters?

Since the overhaul of the www.ntp.org <http://www.ntp.org> website a few years
back, that documentation sadly is maintained in two places, and there's no process to ensure they stay in sync.-a The web version is considered the more
authoritative source, and is maintained in .md (Markdown) published only via the
converted HTML on the website.-a It started as a copy of the documentation from
the source tarballs' /html directory, but after conversion to Markdown and subsequent improvements, those changes have generally not been made to the HTML
version distributed with the source.-a I'm partly to blame because I find writing
documentation tedious enough without having to update it in two places, and I've
been kept quite busy with coding work and haven't wanted to take the time to correct documentation that no longer reflects the reality of the code.-a In theory one day I will have time to dedicate to that, but I welcome anyone who
enjoys documentation work or at least really wants accurate-aNTP documentation to
please volunteer to help out.

FYI mandoc 1.14.6 (2021) will generate markdown from mdoc or man formats!

I see the sources are in https://git.nwtime.org/websites/ntpwww and require a Go
package Hugo to generate.
Surprised you don't use the option to convert the ancient GIFs to webp and save
space and time, especially on mobiles.

> My question is why would a preemptable server, acquired using
> "pool ...", continue to be polled after it has stopped
> responding, i.e., the reach has gone to 0? It is a
> misunderstanding on my part or is there an bug in the code?

Or a doc bug?

A doc bug and an off-by-one bug in the preemption logic.

--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada

La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien |a ajouter not when there is no more to add mais lorsqu'il n'y a plus rien |a retirer but when there is no more to cut
-- Antoine de Saint-Exup|-ry

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.time.ntp

--0000000000005c592f062aa333fd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 22, 2024 at 7:52=E2=80=AFPM Brian Inglis < Brian.Inglis@systematicsw.ab.ca> wrote:

On 2024-11-21 22:55, Dave Hart (via questions Mailing List) wrote:

As an aside, using "preempt" on a non-pool

non-manycastclient association

(basically, configured via "server" or "peer") seems quixotic to me, as

it

allows the association to be removed but nothing is done to replace it.

I have

a difficult time imagining where that might be useful.

[...]

It can be useful when you have an adequate number of (some local) backup servers
or (former) pools, but some (local) have an annoying habit of going unreachable,
but not being noticed, and support not being responsive to hints for
weeks, e.g.

...
server ...
...
server ntp2.cpsc.ucalgary.ca iburst preempt # U Calgary T2N AB
CA
server ntp1.yycix.ca iburst preempt # YYCIX, Calgary T2P AB
CA
server ntp2.switch.ca iburst preempt # TELUS, Edmonton T6H AB
CA
...
server ...
...
tos minsane 3 minclock 5 maxclock 7

I'm not sure I follow what you're trying to do. I'm still stuck on the
idea that you can't count on any of the preempt-marked servers being around
to meet your minsane and minclock requirements as they can be removed automatically if they're unreachable for a bit but then will never be
restored. So you're down to your "server ..." lines, and those don't
inform me much.

If you're wondering why I mentioned "manycastclient", it shares much of
the

implementation with "pool". They use different approaches to finding

servers,

but the rest of the code is common. Both are intended to be automatic

server

discovery schemes that discard, or preempt, servers which haven't been

useful

for 10 poll intervals so that another server can be solicited to replac=

e

it.

I noticed those comments.

$ grep 'pool.*preempt' ~/src/time/ntp/ntp-4.2.8p18/ntpd/

complete.conf.in

<http://complete.conf.in>
pool 2.ubuntu.pool.ntp.org <http://2.ubuntu.pool.ntp.org>. iburst

preempt

complete.conf.in <http://complete.conf.in>is part of the "make check"

tests and

is not intended to suggest useful configurations. Rather it's used bot=

h

to

ensure every keyword in the configuration file parser is covered, and t=

o

ensure

a configuration can successfully round-trip through ntpd's reading and

applying

the configuration and exporting the configuration via the --
saveconfigquit command-line option added specifically for that develope=

r

test to

catch changes which break that functionality. It's no coincidenceit

isordered

exactly the same as the output of ntpq's saveconfigcommand, which

requires

authentication and that a directory for such saved configuration files

has been

specified in ntp.conf with "saveconfigdir".

Implies that pool will round trip with iburst preempt?

complete.conf.in is part of build-time testing of the configuration file reading and writing code. When I said round-trip, I mean that as part of
the "make" ntpd just after compiling is invoked to read complete.conf and
then write it out using --saveconfigquit and make sure there's no change
except comments. It has nothing to do with recommended configuration of
ntpd.

I go by the ntp.conf.def files and date-time stamps, as the html and other

docs
should be Autogen-erated from these masters?

It's a mess. Traditionally the documentation came from two sources, first
the static html documentation in the html source directory, and secondly
the man pages, html equivalents, and option processing code that comes from Autogen .def files. That documentation was both installed as part of "make install" as well as posted to the udel.edu NTP pages of Dr. Mills. After
he was no longer maintaining those pages, Harlan Stenn initiated a change
to maintain all the documentation on the web only, derived using Hugo. The documentation in the source releases was left to bit-rot, essentially, as
most work went into maintaining the shiny new object. I've never been particularly productive maintaining documentation to match code changes,
and I have no interest in doing all that work twice to get changes done in
both web-only and source-only divergent forms. There's been noise about somehow resolving this forking of the documentation and the need to
maintain it in two places, but no progress I'm aware of.

Cheers,
Dave Hart

--0000000000005c592f062aa333fd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><div class=3D"gmail_default" style= =3D"font-family:&quot;trebuchet ms&quot;,sans-serif"></div></div></div><div=
class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmai= l_attr">On Fri, Nov 22, 2024 at 7:52=E2=80=AFPM Brian Inglis &lt;<a href=3D= "mailto:Brian.Inglis@systematicsw.ab.ca">Brian.Inglis@systematicsw.ab.ca</a= >&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On = 2024-11-21 22:55, Dave Hart (via questions Mailing List) wrote:<br>&gt; As =
an aside, using &quot;preempt&quot; on a non-pool non-manycastclient=C2=A0a= ssociation <br>
&gt; (basically, configured via &quot;server&quot; or &quot;peer&quot;) see=
ms quixotic to me, as it <br>
&gt; allows the association to be removed but nothing is done to replace it= .=C2=A0 I have <br>
&gt; a difficult time imagining where that might be useful.=C2=A0</blockquo= te><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= er-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail_d= efault" style=3D"font-family:&quot;trebuchet ms&quot;,sans-serif">[...]</sp= an><br>

It can be useful when you have an adequate number of (some local) backup se= rvers <br>
or (former) pools, but some (local) have an annoying habit of going unreach= able, <br>
but not being noticed, and support not being responsive to hints for weeks,=
e.g.<br>

...<br>
server=C2=A0 ...<br>
...<br>
server=C2=A0 <a href=3D"http://ntp2.cpsc.ucalgary.ca" rel=3D"noreferrer" ta= rget=3D"_blank">ntp2.cpsc.ucalgary.ca</a>=C2=A0 =C2=A0iburst preempt=C2=A0 =
# U Calgary=C2=A0 =C2=A0 =C2=A0 =C2=A0 T2N AB CA<br>
server=C2=A0 <a href=3D"http://ntp1.yycix.ca" rel=3D"noreferrer" target=3D"= _blank">ntp1.yycix.ca</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0iburst pr= eempt=C2=A0 # YYCIX, Calgary=C2=A0 =C2=A0T2P AB CA<br>
server=C2=A0 <a href=3D"http://ntp2.switch.ca" rel=3D"noreferrer" target=3D= "_blank">ntp2.switch.ca</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 iburst preemp= t=C2=A0 # TELUS, Edmonton=C2=A0 T6H AB CA<br>
...<br>
server=C2=A0 ...<br>
...<br>
tos=C2=A0 =C2=A0 =C2=A0minsane 3=C2=A0 minclock 5=C2=A0 maxclock 7<br></blo= ckquote><div><br></div><div><div class=3D"gmail_default" style=3D"font-fami= ly:&quot;trebuchet ms&quot;,sans-serif">I&#39;m not sure I follow what you&= #39;re trying to do.=C2=A0 I&#39;m still stuck on the idea that you can&#39=
;t count on any of the preempt-marked servers being around to meet your min= sane and minclock requirements as they can be removed automatically if they= &#39;re unreachable for a bit but then will never be restored.=C2=A0 So you= &#39;re down to your &quot;server ...&quot; lines, and those don&#39;t info=
rm me much.</div></div><div><br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= ng-left:1ex">&gt; If you&#39;re wondering why I mentioned &quot;manycastcli= ent&quot;, it shares much of the <br>
&gt; implementation with &quot;pool&quot;.=C2=A0 They use different approac= hes to finding servers, <br>
&gt; but the rest of the code is common.=C2=A0 Both are intended to be auto= matic server <br>
&gt; discovery schemes that discard, or preempt, servers which haven&#39;t = been useful <br>
&gt; for 10 poll intervals so that another server can be solicited to repla=
ce it.<br>

I noticed those comments.<br>

&gt;=C2=A0 =C2=A0 =C2=A0$ grep &#39;pool.*preempt&#39; ~/src/time/ntp/ntp-4= .2.8p18/ntpd/<a href=3D"http://complete.conf.in" rel=3D"noreferrer" target= =3D"_blank">complete.conf.in</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0&lt;<a href=3D"http://complete.conf.in" rel=3D"nore= ferrer" target=3D"_blank">http://complete.conf.in</a>&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0pool <a href=3D"http://2.ubuntu.pool.ntp.org" rel= =3D"noreferrer" target=3D"_blank">2.ubuntu.pool.ntp.org</a> &lt;<a href=3D"= http://2.ubuntu.pool.ntp.org" rel=3D"noreferrer" target=3D"_blank">http://2= .ubuntu.pool.ntp.org</a>&gt;. iburst preempt<br>
&gt; <br>
&gt; <br>
&gt; <a href=3D"http://complete.conf.in" rel=3D"noreferrer" target=3D"_blan= k">complete.conf.in</a> &lt;<a href=3D"http://complete.conf.in" rel=3D"nore= ferrer" target=3D"_blank">http://complete.conf.in</a>&gt;is part of the &qu= ot;make check&quot; tests and <br>
&gt; is not intended to suggest useful configurations.=C2=A0 Rather it&#39;=
s used both to <br>
&gt; ensure every keyword in the configuration file parser is covered, and =
to ensure <br>
&gt; a configuration can successfully round-trip through ntpd&#39;s reading=
and applying <br>
&gt; the configuration and exporting the configuration via the -- <br>
&gt; saveconfigquit=C2=A0command-line option added specifically for that de= veloper test to <br>
&gt; catch changes which break that functionality.=C2=A0 It&#39;s no coinci= denceit isordered <br>
&gt; exactly the same as the output of ntpq&#39;s saveconfigcommand, which = requires <br>
&gt; authentication and that a directory for such saved configuration files=
has been <br>
&gt; specified in ntp.conf with &quot;saveconfigdir&quot;.<br>

Implies that pool will round trip with iburst preempt?<br></blockquote><div= ><br></div><div><div class=3D"gmail_default" style=3D"font-family:&quot;tre= buchet ms&quot;,sans-serif"><a href=3D"http://complete.conf.in">complete.co= nf.in</a> is part of build-time testing of the configuration file reading a=
nd writing code.=C2=A0 When I said round-trip, I mean that as part of the &= quot;make&quot; ntpd just after compiling is invoked to read complete.conf = and then write it out using --saveconfigquit and make sure there&#39;s no c= hange except comments.=C2=A0 It has nothing to do with recommended configur= ation of ntpd.</div></div><div><br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa= dding-left:1ex">
I go by the ntp.conf.def files and date-time stamps, as the html and other = docs <br>
should be Autogen-erated from these masters?<br></blockquote><div><br></div= ><div><div class=3D"gmail_default" style=3D"font-family:&quot;trebuchet ms&= quot;,sans-serif">It&#39;s a mess.=C2=A0 Traditionally the documentation ca=
me from two sources, first the static html documentation in the html source=
directory, and secondly the man pages, html equivalents, and option proces= sing code that comes from Autogen .def files.=C2=A0 That documentation was = both installed as part of &quot;make install&quot; as well as posted to the=
<a href=3D"http://udel.edu">udel.edu</a> NTP pages of Dr. Mills.=C2=A0 Aft=
er he was no longer maintaining those pages, Harlan Stenn initiated a chang=
e to maintain all the documentation on the web only, derived using Hugo.=C2= =A0 The documentation in the source releases was left to bit-rot, essential= ly, as most work went into maintaining the shiny new object.=C2=A0 I&#39;ve=
never been particularly productive maintaining documentation to match code=
changes, and I have no interest in doing all that work twice to get change=
s done in both web-only and source-only divergent forms.=C2=A0 There&#39;s = been noise about somehow resolving this forking of the documentation and th=
e need to maintain it in two places, but no progress I&#39;m aware of.</div= ></div><div>=C2=A0</div><div><div class=3D"gmail_default" style=3D"font-fam= ily:&quot;trebuchet ms&quot;,sans-serif"><span style=3D"color:rgb(102,102,1= 02);font-family:tahoma,sans-serif">Cheers,</span></div><div><div dir=3D"ltr=
" class=3D"gmail_signature"><div dir=3D"ltr"><font face=3D"tahoma, sans-ser= if" color=3D"#666666">Dave Hart</font></div></div></div><br><br></div></div= ></div>

--0000000000005c592f062aa333fd--

--- Synchronet 3.21d-Linux NewsLink 1.2