Re: [ntp:questions] Looking for a NTP stratum 2 appliance
On 05/26/2017 12:25 PM, Matthew Huff wrote: > You are correct that we don't need OXCO oscillators, and we could drop > that requirement, but it would be a good indicator that the hardware > manufacturer isn't just slapping a regular PC together. I'ld guess that buying a stratum *1* unit with the capability to use a "fallback" NTP source might be a better (and more readily available) indicator for that ... Regards, -- Jochen Bern Systemingenieur Fon:+49 6151 9067-231 Fax:+49 6151 9067-290 E-Mail: jochen.b...@binect.de www.binect.de www.facebook.de/binect Binect ist ausgezeichnet: Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017 Binect GmbH Robert-Koch-Straße 9, 64331 Weiterstadt, DE Geschäftsführung: Dr. Frank Wermeyer, Nils Manegold Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 94685 Umsatzsteuer-ID: DE 221 302 264 MAX 21-Unternehmensgruppe ✁ Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser Nachricht durchzuführen. Wir schließen, außer für den Fall von Vorsatz oder grober Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software oder E-Mail aus. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly prohibited. All Binect GmbH emails are created thoroughly, nevertheless we do not accept any legal obligation for the information and wording contained herein. Binect GmbH has taken precautionary measures to reduce the risk of possible distribution of virus infected software or emails. However, we advise you to check attachments to this email for viruses. Except for cases of intent or gross negligence, we cannot accept any legal obligation for loss or damage by virus infected software. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP under AIX?
On 05/16/2017 11:19 PM, Greg Moeller wrote: > That would imply there are windows. This is one of those places with > trapping passages in case intruders try to storm the datacenter, windows > would be a fatal weakness. :) If so, it would be even *more* fatal a weakness to trust the site's ability to summon reinforcements to terrestrial lines - be they copper or glass - remaining uncut. I.e., you should have an array of antennas *already*. (Also, it'ld suggest that you should ponder the possibility of your adversaries trying to feed you fake signals to falsify your timekeeping. The civilian GPS signals aren't cryptographically signed IIUC.) On 05/16/2017 09:57 PM, Greg Moeller wrote: > Oh, I could imagine the fun trying to install a Pi into the datacentre. :) > "it needs redundant power supplies, dual network, mirrored drives, Gold > support contract (on hardware and OS of course), proper rack mounting > system" [cable-ties half a dozen Pis onto a rack shelf, connects three of them to three different power sources, labels the remaining three "Hyperplutonium Support Preemptive On-Site Replacement Units", and lets the S2 ntpds do the "clustering"] [closes shelf front with duck tape and writes "0 ft³/min strictly front-to-back airflow" on it with the best permanent marker money can buy] Regards, -- Jochen Bern Systemingenieur Fon:+49 6151 9067-231 Fax:+49 6151 9067-290 E-Mail: jochen.b...@binect.de www.binect.de www.facebook.de/binect Binect ist ausgezeichnet: Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017 Binect GmbH Robert-Koch-Straße 9, 64331 Weiterstadt, DE Geschäftsführung: Dr. Frank Wermeyer, Nils Manegold Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 94685 Umsatzsteuer-ID: DE 221 302 264 MAX 21-Unternehmensgruppe ✁ Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser Nachricht durchzuführen. Wir schließen, außer für den Fall von Vorsatz oder grober Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software oder E-Mail aus. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly prohibited. All Binect GmbH emails are created thoroughly, nevertheless we do not accept any legal obligation for the information and wording contained herein. Binect GmbH has taken precautionary measures to reduce the risk of possible distribution of virus infected software or emails. However, we advise you to check attachments to this email for viruses. Except for cases of intent or gross negligence, we cannot accept any legal obligation for loss or damage by virus infected software. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] set server to a non utc time by hand
On 12/23/2015 02:43 PM, h3x32000-sf wrote: > i was also thinking about solving the problem like this: > >> There seem to be ways to actually adapt >> the *device* (though it'll void your warranty) ... >> http://jochen.kirstaetter.name/blog/general/adjust-timezone-of-an-avm-fritzbox-7390.html > > But the way that is shown in the blog unfortunately is not applicable > with the actual firmware fritz!os 6.30 that is installed on my device. There are *two* methods shown in that blog article, and while "Solution 2" (telnet) has been marked as unusable from FW 6.30 on, nobody seems to have reported "Solution 1" (restore a modified config backup) as nonoperational yet ... >> That doesn't strike me as a *good* reason to have manipulated time >> pollute your local net / NTP. > > What are the concrete "pollution-risks"? Other clients getting confused by an NTP server (either the Fritz!Box itself or the one you introduce the offset in) that, contrary to the basic assumptions of the *current* NTP protocol, gives out time that is not based on UTC. I would presume that your Fritz!Box is the defaultrouter of your local network and DHCP server for part of it (the WiFi part in particular, if it's also the AP), which implies a higher risk of clients stumbling over it in an automated setup phase than if it were just another local server. Also, if you only introduce an offset in the NTP server but let the Fritz!Box still believe it's in Germany, it will *start and end DST* according to German rules, which likely doesn't agree with your local DST. Kind regards, Jochen Bern Systemingenieur -- LINworks GmbH Fon:+49 6151 9067-231 Fax:+49 6151 9067-299 E-Mail: jochen.b...@linworks.de Web:http://www.LINworks.de/ NEC IT Infrastrukturprodukte vom Deutschland Distributor Server, Storage, Virtualisierung, Management Software Shop: http://www.NEC-Store.de/ Briefanschrift: Postfach 10 01 21 · 64201 Darmstadt · DE Hausanschrift: Robert-Koch-Straße 9 · 64331 Weiterstadt · DE Geschäftsführer: Metin Dogan, Nils Manegold, Oliver Michel Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 85202 MAX21-Unternehmensgruppe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] set server to a non utc time by hand
On 12/22/2015 09:14 AM, h3x32000-sf wrote: > The idea why i want to do that, is: i am using a router made for the > german market (fritzbox 7360) but i am not in their timezone, utc+1, > what is the firmware-coded timezone in that device. Even though its > impossible to alter the timezone, i can change the timeserver contacted > by the device. So the idea is to set me up my own private ntp-server > that gives back localtime-1 so that the router runs on localtime... That doesn't strike me as a *good* reason to have manipulated time pollute your local net / NTP. There seem to be ways to actually adapt the *device* (though it'll void your warranty) ... http://jochen.kirstaetter.name/blog/general/adjust-timezone-of-an-avm-fritzbox-7390.html Kind regards, Jochen Bern Systemingenieur -- LINworks GmbH Fon:+49 6151 9067-231 Fax:+49 6151 9067-299 E-Mail: jochen.b...@linworks.de Web:http://www.LINworks.de/ NEC IT Infrastrukturprodukte vom Deutschland Distributor Server, Storage, Virtualisierung, Management Software Shop: http://www.NEC-Store.de/ Briefanschrift: Postfach 10 01 21 · 64201 Darmstadt · DE Hausanschrift: Robert-Koch-Straße 9 · 64331 Weiterstadt · DE Geschäftsführer: Metin Dogan, Nils Manegold, Oliver Michel Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 85202 MAX21-Unternehmensgruppe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] set server to a non utc time by hand
On 12/20/2015 11:12 PM, h3x32000-sf wrote: > i would like to set up an ntp-server thats does not give back the > correct utc time, but for example utc-1 or another "wrong" time computed > before. Until now the only way I reached that result was to set the > local clock to the wished time and to sychronize then with 127.127.1.1. NTP-Proxy sits between an actual NTP server and a test client and simulates an upcoming leap second to the latter: https://github.com/AmadeusITGroup/NTP-Proxy/blob/master/ntpproxy.c In order to do that, it needs to not only flip the flag bit, but also shift the time to shortly before a leap second slot - so the functionality you're looking for is *halfway* done in its code ... Kind regards, Jochen Bern Systemingenieur -- LINworks GmbH Fon:+49 6151 9067-231 Fax:+49 6151 9067-299 E-Mail: jochen.b...@linworks.de Web:http://www.LINworks.de/ NEC IT Infrastrukturprodukte vom Deutschland Distributor Server, Storage, Virtualisierung, Management Software Shop: http://www.NEC-Store.de/ Briefanschrift: Postfach 10 01 21 · 64201 Darmstadt · DE Hausanschrift: Robert-Koch-Straße 9 · 64331 Weiterstadt · DE Geschäftsführer: Metin Dogan, Nils Manegold, Oliver Michel Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 85202 MAX21-Unternehmensgruppe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap Second on NTP server at stratum 2
On 06/11/2015 08:41 AM, Kashif Mumtaz Tahir wrote: Dear Jochen, You extracted description is right , we are at stratum 2 and just syncing its time with stratum 1 level GPS device. Litte bit confused with your conclusion. When leap second will happen on GPS what will the impact on our stratum 2 level server and below beyond ( Straum 3 client etc ) The part I cannot answer is whether (and when) the GPS device will forward the information about the upcoming leap second into the data it hands out via NTP. As an example, Meinberg states that their GPS receivers will start announcing the leap second during the last 59 minutes: https://www.meinbergglobal.com/english/info/leap-second.htm#refclocks and confirms that those units which also speak NTP will include the refclock's announcement in their replies: https://www.meinbergglobal.com/english/info/leap-second.htm#ntp-server So, *if* your GPS unit were a Meinberg LANTIME model, your stratum 2 server would be made aware of the upcoming leap second about one hour before it happens. Now, assuming that that *does* happen: ntpd *does* forward this information (because you have no leapsecond files overriding the info received from the server), and ntpds actually start polling their servers more frequently as the leap second slot draws near, so all devices running NTP (not SNTP) will typically have their OS armed (informed that it - the OS, not ntpd - will have to take action to conform to the leap second) in time. That implies that *how* they actually do that is up to every OSes' choices and implementation. The most usual *choice* is to have the OS clock stepped back one second, 23:59:59.999... - 23:59:59.000... . And then there's the possibility that the code, which currently gets executed once every couple *years*, has a bug making it do *something else*. For (a historic) example, freeze the server. :-/ That's why having test machines go through a simulated leap second is a thing. (For sake of completeness, any client doing SNTP will notice a one-second offset the first time it contacts its servers after the leap second, and perform the step *then*. That should IIUC (still) include most of the machines running Windows.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap Second on NTP server at stratum 2
On 06/10/2015 01:27 PM, Kashif Mumtaz Tahir wrote: Dear Macro, We just want to sync seamless with leap seconds. [...] Should we need to change/tune anything. I read your description as: -- There is a GPS device that actually *speaks NTP* (as opposed to, e.g., being connected to a server with a serial cable) -- This device feeds a central stratum 2 server running ntpd -- Everything else of interest is an NTP (not SNTP) client of that central server -- No special configs beyond the above, in particular, -- no additional external NTP servers, -- no leap seconds file, and -- no suppression of stepping configured on any of the machines. My conclusions: -- Whatever announcement the GPS unit makes of the upcoming leap second will be forwarded to the various machines. -- You hopefully have historic records, vendor statements, or whatever indicating that this GPS unit *will* announce a leap second to be *inserted*. (It mistakenly announcing a *negative* leap should be highly improbable, but I have no idea how likely it is to find a GPS unit that flat out doesn't propagate leap second announcements.) -- The job of actually executing the leap second will be left to the OS kernel of every individual machine - if you cannot afford them hitting a historic or new bug that night, you should start testing kernel versions with simulated leap seconds ASAP. -- There is a (very small) chance that in the leap second night, your single-point-of-failure GPS unit will somehow cease to work before any announcement happens and your platform will never learn of the upcoming leap second - in which case you'll find it working but being offset by one second in the morning. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP not syncing to configured servers
On 05/13/2015 01:52 PM, Chandrakanth K wrote: bash-4.2$ ntpq -np -c assoc remote refid st t when poll reach delay offset jitter *127.127.1.0 .LOCL. 10 l 19 64 3770.0000.000 0.001 10.126.142.198 LOCAL(0) 6 u7 16 3770.172 859.844 0.501 10.126.142.204 LOCAL(0) 6 u 15 16 3770.227 1057.22 0.240 ntpd has connected to both remote servers and retrieved data from them, so it's not an outright packet block on some firewall. Instead ... ind assID status conf reach auth condition last_event cnt = 1 26554 9614 yes yes none sys.peer reachable 1 2 26555 9014 yes yes nonereject reachable 1 3 26556 9014 yes yes nonereject reachable 1 ... it saw fit to label them as rejected. I'ld guess that the two servers having an offset of ~0.2 s with respect to each other plays a role in that, and the client having another ~0.9 s offset from their average might be an obstacle until you restart the client ntpd, too. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP sync failing with error: Leap not in sync
On 04/01/2015 10:23 PM, Unknown wrote: 10.0.0.5: Server dropped: Leap not in sync stratum 3, precision -23, leap 11, trust 000 ^^^ 1 Apr 14:28:05 ntpdate[18328]: no server suitable for synchronization found That's indeed an error code labelling your server as unsuitable as a sync source to your clients. I admit I've never seen it together with another stratum than 15 (also an is unsynced marker), though. The stratum being given as 3 suggests that your server considers itself synced to one of its stratum 2 sources, and my first guess would be that that server signals weird flags as well. (Which *should* cause your server *not* to consider it suitable, either.) Running ntpq against your server doesn't output its peers' leap seconds. Try dry-running ntpdate against them from your server. 2 packets reassembled into response NTP packets as used in syncing shouldn't be large enough to trigger any MTU problems short of downright insane pMTUs. Do you have *duplicated* packets happening in your network? server 0.centos.pool.ntp.org iburst server 1.centos.pool.ntp.org iburst server 2.centos.pool.ntp.org iburst *Pool* servers but you *consistently* get mis-synced? Hmmm ... :-/ MfG J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Writing the drift file
On 03/06/2015 10:35 AM, Harlan Stenn wrote: A while ago we got a request from the embedded folks asking for a way to limit the writing of the drift file unless there was a big enough change in the value to warrant this. [...] I'm wondering if we should just let folks specify a drift/wander threshold, and if the current value is more than that amount we write the file, and if the current value is less than that amount we don't bother updating the file. If folks are on a filesystem where the number of writes doesn't matter, no value would be set (or we could use 0.0) and it's not an issue. Thoughts? *Thoughts* I have, but no clear conclusion, I'm afraid ... 0. There's limiting the write ops, and then there's being all out to avoid them. Saying that the value should *never* be written unless the difference exceeds the threshold suggests the latter, is that actually the request? From a sanity POV, *some* timeout (say, a month) and/or writing triggered on orderly shutdowns sound like something we'ld want to do. 1. What about *appending* to the file (up to some length limit) instead of overwriting the exact same bytes within it? Is that something that flash RAM and its specialized fs'es can handle better? 2. What's actually the worst-case scenario here? Let's assume a unit whose drift is correlated with the 24h temperature cycle, -6 ppm at daybreak, +6 ppm in the early afternoon, and the limit is a delta of 10 ppm. Now, if the drift file gets initially written with an intermediate value of abs(x)4, it'll *never* get rewritten - but otherwise, there will be two writes per day for all eternity, as the mechanism doesn't allow the stored value to ever gravitate to the middle ground. Is that something that should be taken care of? 3. What's the purpose of that stored value? IIUC ntpd only ever reads it on startup, and the inherent assumption is that it is a fairly *RECENT* drift value that ntpd can assume to be a proper approximation of the *current* drift, and compensate for it. With the new mechanism, the actual current drift is somewhere within +/-limit of the stored value. Is that still useful, as in minimizing the offset that the starting ntpd will pick up until it has obtained a drift estimate of its own? Or would it be better to have it start with some sort of *average* value of the drift, rather than a current value that actually isn't ... ? Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap-second test with ntpd
On 02/24/2015 01:23 AM, Ask Bjørn Hansen wrote: I am trying to setup an ntpd to use the local clock as the reference source and so I can set the time to late June and verify 1) what ntpd does and 2) what clients do. FYI, I researched the question of how to simulate an upcoming leap second (as announced through NTP) a while back, and the solution I have in the drawer (still waiting for the next firmware release to go into QA) is to set up a dedicated (phony) NTP server with NTP-Proxy. https://github.com/AmadeusITGroup/NTP-Proxy#indirect-ls-simulation-via-ntp Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
On 02/11/2015 10:01 AM, Rob wrote: Terje Mathisen terje.mathi...@tmsw.no wrote: The 500 ppm limit is not at all arbitrary! In fact, it was originally just 100 ppm, but when too many systems turned up with a system clock which was a bit too far out, Prof Mills redid the control loop to allow a 500 ppm range. It could have been a lot more, but the ultimate stability of the control loop is supposed to be better this way. I think it is hogwash. The static drift cannot have any influence on the stability of the control loop. A static drift is just a frequency error that is determined once and can then be forgotten about. The limit is said to be required in the original mathematical proof of the stability of NTP networks. Unlike the typical setup today, this included *fully meshed* networks of nodes *peering* with each other, with ample potential of feedback loops through several of them leading to oscillation. (Disclaimer: I never found it necessary to verify, or even read, the math myself.) I remember that in the past sometimes a specific adjtime command was used to pre-configure a static error so that ntpd would not see it. No idea if this still works. At least on the (Linux) systems where I found it necessary to use it to counter a bad clock, changing the tick value has worked so far. (Bar one stone-age busybox-based server where the devel environment had been lost in time and nobody could compile tickadj or any other tool that'ld allow me to touch tick in the first place.) Note that the default value of tick on Linux boxen is 1, so changing this integer value by one theoretically effects a 100 PPM shift. (For whatever reasons, my practical experience is more like 120 to 150 PPM ...) There's your valid reason why raising the NTP limit from 100 to 500 made more sense than raising it further to 5000 or whatever. However, I've also seen hardware occasionally flip-flopping from -900 to +1100 and back, complete with the developers of the firmware blaming a bug in ntpd for failure to discipline *that*. Would I want ntpd to cater for such cases? Heck, no. It would *never* be able to keep *that* clock in sync to the quality standards of proper NTP servers, and standard tools *refuse* this pile of clockwork rejects provides the push to the only *proper* solution, namely, to fix the hardware. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
On 02/10/2015 06:15 AM, catherine.wei1...@gmail.com wrote: However, when I wait for several minutes, the time can be adjusted to the right time. I couldn't see the gradual changes of offset. Is that normal? Assuming that you're using a minimalistic configuration: Yes. ntpd would take almost three months to *gradually* eliminate (slew) one hour of offset, so as soon as the offset-from-hell-that-struck-us-out-of-the-blue-sky was confirmed, it gave up all hope for the universe and just set the clock hard (step). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd -x and leap seconds
On 02/09/2015 11:49 AM, Miroslav Lichvar wrote: Should be leap seconds threated as a normal offset and not corrected by step when the threshold is larger than 1.0? Should there be a separate option for them? I have practical use cases for *both* variants (*), so I'ld prefer being given the possibility to do either. Whether I have an *option* to do that or can effect it by *config* (setting the limit, which is otherwise unused) is, however, secondary. FWIW, I could also imagine people to be interested in having leap seconds handled by the *kernel* even when steps are generally disabled - *especially* if the method *how* a kernel handles them is going to become a zoo of variants outside ntpd's control in the future ... (*) a) Even leap seconds should be *slews* when the reason to disable steps is that some software cannot handle such behavior of the OS clock. b) We're distributing appliances where the ntpd on the appliance losing sync leads to alerts getting raised with the local admin. The server has steps disabled so as to prevent clients losing sync over a step. However, the clients can and will process leap seconds normally, so the server should do the same. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/27/2015 10:16 AM, Terje Mathisen wrote: Jochen Bern wrote: Because they chose the long window (about one day) and made it exceed the time an NTP peering needs to *act* on the perceived offset, yes. If That's a a key feature of the long adjustment period: The smearing takes so long that the frequency offset is never even close to the 500 ppm limit, and (since the first derivative is smooth) the change is frequency is gradual enough that all the clients will be able to track it, even if they are running at a fixed 1024 s polling interval. OK, but that's assuming that the client will absorb the leap second entirely by having an NTP server dragging it along within the limits of a normal NTP sync, without *ever* informing the client kernel's leap second handling routines that one even occurred. Which means that your client cannot be talking to a normal NTP server with normal NTP client s/w, and if kernels ever would attempt to keep track of past leap seconds on their own, *this* client's kernel would fail in that because it never gets *told* of leap seconds as they happen. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote: The US will soon be considering a means for dissemination of delta T via NTP Does that read there's *several* teams working on NTPv5 and not communicating with each other right now ... ? The ITU has just met in Geneva and discussed the future of leap seconds. The US is in favor of dropping them, the Brits are in favor of keeping the tradition of leap seconds, [...] Leap seconds are an artefact of a) rotation of Earth (which is ever slowing down because of mechanisms that nothing short of pointing a giant disintegrator ray at the Moon can stop, on top of the uncertainty reflected in the unpredictability of current leap seconds), b) the precision we have achieved in measuring - supposedly immutable - physical time, and c) a desire to have time represented in a way that alludes to the traditional apparent position of the Sun right where I stand (on the surface of the Earth) notion. You can quantize and/or distribute leap seconds in a different way, but you can NOT drop them short of kissing one of these three basics goodbye. (If you read through the comments ITU received along with the votes when they put up the poll, you will notice that a great many abolish leap seconds voters proposed schemes that actually do *not* *abolish* the concept of leaps but merely distribute the corrections differently, from infinitesimal leaps to the exceedingly rare leap minute.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/22/2015 07:04 PM, William Unruh wrote: General relativity assures us that time exists and is measured by a metric. Take that metric and define a proper time say at the center of the earth. (Bad choice because relativity says that clocks down the gravity well run faster, but we've been ignoring that fact so far, anyway, so ...) [...] while TAI says that difference is .2 sec, UTC says it is 1.2 sec different. That for all purposes is a discontinuous function of the time as defined by General relativity. Now, it is true that UTC does give a name to that second that lies between the two times, but giving it a name does not make the function continous. Actually I agree with that last sentence, but not in the way you expect. It's the *metric* that UTC defines, along with the representation, that makes the function continuous. Basically, UTC not only says that 23:59:60 is valid and shall be ordered between 23:59:59 and 00:00:00, but that it represents one SI second (as measured with any suitable instrument) wherever it is officially inserted. Hence, the difference between 23:59:59.9 UTC and 00:00:00.1 UTC is 0.2 SI seconds wherever a leap second is *not* inserted, and 1.2 SI seconds where it is, *because that's what you were told how to count it*, and since computing the difference between the two UTC timestamps (with a list of past and present leap seconds at hand) correspondingly results in 0.2 UTC seconds or 1.2 UTC seconds unless the timestamps are in the uncertain future, the two notions still agree down to any resolution you want - continuous, linear, derivative with slope = 1. The fact that UTC publishes a list of when those discontinuities occur is also irrelevant. UTC says that leap seconds are part of the UTC representation of time (i.e., on the conversion function's ordinate) and correspond to an actual SI second of physical time that passes (i.e., it's present on the abscissa as well). Your refusing both punches a square hole, one square second large, into the function's graph - that's not a discontinuity in a strict sense, it's a stretch where the function remains undefined by your refusal to acknowledge the definition. Anyone willing to re-insert that square with the diagonal line on it into the graph gets a straight line from one edge of the paper to the other, and has no reason whatsoever to see a discontinuity. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/26/2015 01:03 PM, Terje Mathisen wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. I noticed that it lends itself to such properties (even if Googles specific implementation fails to do so). However, you pay for it either in a long window needed to perform the smear, on in some of said derivatives going *way* off their normal values. The _huge_ problem with their approach is that they have to make d*** sure there will never be any time leaks between their internal smeared timebase and any external UTC/TAI clocks as long as the adjustment is taking place. Because they chose the long window (about one day) and made it exceed the time an NTP peering needs to *act* on the perceived offset, yes. If it weren't announced that NTPv5 will support labelling the actual timescale used, I'ld propose that future kernels SHOULD not only accept leap second upcoming bits from an NTP client s/w, but also hand leap second handling in progress bits back, so as to allow the s/w to mark itself as unsynced via NTP until the effects are over. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Sorry for the delay, I'm *still* not back to my usual workplace ... On 01/21/2015 11:39 AM, Mike Cook wrote: I couldn’t find a definition of a monotonous function. Does it exist? As David already suggested, I learnt my math in Germany - and switched to CS before taking a shot at a PhD, which would have required me to tear into actual current research, which would have been written in English. So yes, (streng) monoton should have been translated as (strictly) monotonic, not (strictly) monotonous. (Quick terminology recap: A function takes inputs from one set (domain) and assigns an output/result from another set (codomain) to them. In order to define continuous, both domain and codomain need to be ordered and have a notion of distance or difference (metric).) The function can be non-linear. See below. Yes. In particular, implementing a leap second by decelerating your all minutes have 60 seconds clock results in a conversion function that is monotonic and continuous, but not linear. In the case of having it run at half its normal speed for two seconds, it would qualify as piecewise linear - and not have a defined derivative at the switchover points. For the first version, let us assume that the codomain and its metric have leap seconds incorporated in the same way TAI's codomain integrates leap days. In other words, the metric knows that the distance between 31-Mar-2015 23:59:00 and 01-Apr-2015 00:00:00 is 60 seconds but the one between 30-Jun-2015 23:59:00 and 01-Jul-2015 00:00:00 is 61 seconds. The first result would, of course, be that it's now the metric that fails to be fully defined, as (most of) the future leap seconds are not yet known. This does not prevent the metric from being fully defined. The definition of UTC includes the definition of when a leap second will be inserted without limit to time. 1.1 The magnitude of DUT1 should not exceed 0.8 s. 1.2 The departure of UTC from UT1 should not exceed 0.9 s (see Note 1). 1.3 The deviation of (UTC plus DUT1) should not exceed 0.1 s. There must be a field of maths which includes that notion of « fuzziness ». Yes, but traditional functional analysis isn't it. :-} (Statistics or Limitation Theory come to mind, but I don't have a specific concept on the top of my mind.) The definition of continuous involves looking at arbitrarily small intervals around the points in question. A metric saying that the distance between two points in the future cannot be guaranteed to ever get smaller than the uncertainty means that no such intervals exist, and the definition of continuous falls flat on its face. Variant 2b. It is also conceivable to have a mechanical watch with 61 second divisions, a couple of buttons on the side to push for +/- leap seconds and cams which show/hide the relevant tick marks and speed the second hand from 58 through 0 accordingly at the rate of one SI second I doubt we'll ever see such a *mechanic* watch being made. An *analog* (with hands, and supposedly step motors and electronics driving them, or faking hands with an LCD display or somesuch) or outright digital one, sure. Yes, the conversion to the timescale defined by that watch's second hand's movement would be monotonic, continuous, piecewise linear, invertible, etc.. It still needs additional input (the +/- buttons) to remain true, and entirely separate data (historic list of leap seconds, preferably with checkmarks that the buttons *were* pressed) to accurately compute the time that passed between two readings, though. Again, what you are highlighting is the inability or unwillingness of engineers to create sufficiently robust conversion functions. Well, if you want to put it that way, yes. Though unavailability of leap second info within whatever system they're designing (say, a mechanic wrist watch worn by an average human) is a pretty *solid* reason to claim inability to do so. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
defined, as (most of) the future leap seconds are not yet known. Second, however, as far as it *is* defined, the conversion function would be just as monotonous, continuous, and linear as TAI is with respect to leap days. For the second variant, I'll take the opposite extreme (imagine me to be a watchmaker hunched over the face of a mechanic wrist watch with its 60 tick marks for the seconds hand to rotate through) and claim that the representation of 23:59:60 that UTC proposes for the leap seconds plain doesn't exist. What this means for the conversion function is that the claimed representation for the leap second is invalid, and the function is actually left undefined during that second. It is still monotonic outside (23:59:59.99...,00:00:00), and continuous outside [23:59:59.99...,00:00:00], and can be argued to be monotonic globally, but it is *not* globally continuous anymore, because it fails to be at the points in time where a leap second *is* inserted. Third variant: Now I'll take the point of view of a software developer who writes his code in such a way that minutes with a leap second slot in them may have 59, 60, or 61 seconds, but may not assume that the information which length has been pinpointed for the upcoming slot will be *available* in time. So that's for the set of values of the codomain for a leap-second-slot minute (LSSM). What metric can our developer possibly define for it? Chances are that he'll avoid the (worse) error of having one or even two seconds which do not register *at all* with the metric, and decide that LSSMs with their potentially 61 seconds should be assumed to be 61 seconds long (unless and until proven otherwise, which isn't going to happen because sysadmins are lazy). Which is the correct thing to do for LSSMs that actually *have* a leap second inserted, so for those, the conversion function is again monotonic and continuous. However, the conversion function now has to *skip* a second for every LSSM that turns out *not* to have a positive leap, which is still monotonic, but not continuous behavior anymore. Wait a second, what was that? As far as continuity during LSSMs is concerned, we now have a variant 2 and a variant 3 that are the *exact opposite* of each other, in spite of the fact that we're still talking about the same timescale, UTC! How's that possible? Quite simple, actually: We've taken the uncertainty about the actual length of LSSMs and shoved it from the codomain to the conversion function and back in different ways, and whenever and wherever we assigned it to the function, the function ceased to be well-behaved. Big surprise. Whenever and wherever it is assigned to the codomain instead, we're looking at a metric that is underspecified until the IERS bulletin on the LSSM in question is out. The fact that leap seconds aren't nailed down for all future has to be adressed *somewhere*, even in TAI, where function *and* codomain are nailed down - but the offset to sideric/civil time and its approximations isn't. [Steps off soapbox and takes a swig from his Klein bottle] Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
format starting from TAI=t time_t(TAI) is a function *of TAI* that is neither monotonic nor continuous in TAI=t. TAI(time_t) is a function *of time_t* that is ambiguous (and thus, again, not a function) in the interval [ time_t(t-1) , time_t(t) ]. The of ... part is important. Mathematics doesn't put the blame for the function being bad on either time_t or TAI, it's a property of the *function*, i.e., the very *conversion* from one to the other. (*) Of course, the *real* basis of the changing TAI-UTC offset is that the HH:MM:SS notation refers back to the last turn of the day, and *that* got shifted out of its regular interval by the leap second for UTC, but not for TAI. [End of mathematician geek-out.] Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/16/2015 05:41 AM, Chris Adams wrote: I think one problem with OS clocks in TAI is that counting it correctly requires active/on-going maintenance at unknownable intervals for all systems that use any form of timestamps (including for example anything that uses network file systems). Actually, no, it's the very *reason* to try and use TAI for the baseline that a stable oscillator and a simple counter suffice to do *that* correctly, even (to an extent) all the way through the lifetime of the hardware and its users and in absence of external sync/data sources. The problem arises the moment you want to convert to UTC (or *any* timescale trying to approximate Earth's rotation), and it is conceptually unavoidable because the planet is neither a precise oscillator, nor does it have USB ports to provide our devices with true data directly. (And because the long-term development of the Earth-Moon system leads to Earth's rotation getting gravitationally locked to the Moon like the Moon's already is to Earth, at which point a day on Earth will be as long as what, 40 or 50 of our current days?) While I'm ranting, and because you mentioned the problems of distributing what essentially is the (current) leap seconds table: We all know that the current NTP protocol leans toward UTC, and doesn't address any leap seconds except the one that might be at hand right now. In recent posts to this list, I've read about plans for an NTPng that allows for different timescales, but still suggests that the leap second table be distributed, where necessary, through other, general-purpose protocols like FTP and HTTP. I'm running platforms consisting of hardware that ranges from servers (with a general-purpose OS) to switches to simplistic devices like UPSes or environment sensors. I see the latter's firmware doing SNTP (why would you ever need to configure *two* servers, or a custom interval??) and claiming it's proper NTP in the admin UI. I remember them not having any trace of DST support for Germany until after an EU-coordinated DST came into existence. On the other hand, I see server OSes which *claim* that timezones can be chosen at will and thus should be entirely irrelevant to system administration - but actually *still* have one designated one, e.g., to use in their crontabs. And, of course, I'm the one who would need to convince the CISO that device X needs to talk not just NTP but *HTTP* (oh my God, ever heard of drive-by downloads?!?) to the outside. Read my lips: Unless NTPng *includes* features like delivery of the leap second table and announcement of a preferred timezone (which information one would inject into the platform's outside-facing NTP servers by manual config, of course), so that developers of whatever firmware see that the data's right in the reply packets they already have in RAM, syncing time across entire platforms *WILL* remain a problem because there *ALWAYS WILL* be lots of broken clients getting into the way of a solution. Also, you can't properly represent future timestamps (necessary for some things) as seconds since an epoch, and that's pretty widely used. By that I mean that the number of seconds between 2015-06-30 23:59:00 and 2015-07-01 00:00:00 has changed since last month. As others already mentioned, that's a problem of wanting to express those timestamps in a timescale (UTC) that is already incompatible to such proper (predictive) representation before a single computer ever came into play. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/13/2015 09:33 AM, Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, [...] For distributed logging you have to use the same method for every single node, but that is the case today as well. :-( I.e. with one domain smearing and another stepping, the times between them will be skewed over the entire smearing period. I've been pondering this some more. Isn't the consequence that, for the purposes of the NTP protocol, Googleish and non-Googleish systems are *fundamentally incompatible* on the day of the leap? As in, when ntpd looks across that divide, there'll be an apparent offset in the tenths-of-seconds range for the better part of a day, which is long enough that ntpd *will* take corrective action (in a default config, a step) on the client side, and thus completely hose the client OSes' attempt at dealing with the leap second according to its native procedure? Shouldn't it be a *requirement* that, however an OS chooses to implement a leap second, it must keep the timeframe in which its local clock is (likely to be) off the true timescale short enough to not confuse timesyncing protocols (with the obvious exception of discrete hard syncs, a.k.a. SNTP)? Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/12/2015 04:55 PM, William Unruh wrote: So, there are a bunch of proposals. 1. stop the clock a la Mills (delivering times that always increase but very very slowly during that second). 2. double the rate of the clock during the two seconds around the leap. Have the clock run in TAI and put the leapsecond handling into the conversion code. 3. Make the clock run faster, but not twice as fast, during a period around the leap second. Are any of these the right thing? Yes, #1. The others are wrong because you need the computer clock to run *slower* (getting stopped being the extreme) to emulate a leap second. ;-) The fact of the matter is that (typical) computer clocks want to emulate a leap-second-ful timescale (UTC or a local timezone) with counters that do not possess the extra states/values to represent leap seconds (largely due to the fact that the points where they will be inserted are unpredictable). The only way to *truly* get things right is to move the entire leap second handling into the conversion routines and leave the low-level counters tick away in peace (just like atomic clocks provide TAI and the conversion to UTC is done outside them). Of course, there's a penalty (much higher complexity in the conversions, need to always have the list of past leap seconds at hand) to be paid for that. On the other hand, things like correctly determining the time that passed between two time_t's (or whatever equivalent) would suddenly return to being a simple subtraction. Anything that leaves the job of adapting to leap seconds to the counters themselves will be cursed with either a not-strictly-monotonous time, a period of outright wrong clock readings around the leap, conversion routines that effectively are even *more* complex than the ones to get it right, or a combination of the above. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] What to do for clients less than 4.2.8?
On 12/21/2014 12:38 PM, Rob wrote: David Woolley david@ex.djwhome.demon.invalid wrote: On 21/12/14 10:48, Rob wrote: People say disable crypto but there is no clear direction in the docs on how to do that. I would assume by not enabling it. Ok, but in that case why the worry about the millions of vulnerable servers on the internet, I think most users who just want to get and serve time don't spend the week of time needed to get the crypto working and to coordinate with other servers doing the same. According to what I read on http://support.ntp.org/bin/view/Main/SecurityNotice#Resolved_Vulnerabilities -- CVE-2014-9293 *might* be exploitable on ntpd's that do *not* have explicit crypto settings in the config (but might be stopped by proper restrictions, it doesn't say), -- CVE-2014-9294 is irrelevant for non-crypto setups, -- *One third* of CVE-2014-9295 (the crypto_recv() part) requires an autokey setup, but the other two might not, and there's no statement of other requirements beyond basic reachability, and -- CVE-2014-9296 is *probably* unexploitable. As far as I'm concerned, 0.66 * -9295 is enough for me to grab the backports from the repos for our outward-serving ntpds right now ... Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 12/14/2014 09:04 AM, Brian Inglis wrote: Legal civil time in most countries is defined as mean solar time, where it is not still defined relative to GMT, as it is in most countries in the Commonwealth of Nations deriving their common laws from England, and many allied European and Asian countries. Hm. Is that really the case? The current German legislation refers to coordinated world time (which might be taken as referring to TAI just as well as to UTC, as far as I can understand) and assigns the task of distributing the legal time to the PTB (which could be construed as ruling anything besides DCF77-based notions of time not the legal thing; BTW, DCF77 announces leap seconds only about an hour before the fact, with no specs *asserting* so that I could find). http://www.gesetze-im-internet.de/me_einhg/__4.html I am somewhat surprised that no lawyer has, as yet, argued for phone evidence to be discarded because telco equipment uses TAI or GPS time scales which have no legal basis in any country. Too easily countered by actual measurements showing that the equipment's notion of time never strayed more than a worst-case total of X ms (or, a la rigeur, X seconds) from the notion mandated by the legalese, I'ld guess. It's not like the courts would turn a blind eye to evidence just because they'ld prefer an official endorsement by the parliament. (Always assuming that the facts needing confirmation allow for that much deviation, of course. But high-speed trades aren't concluded on devices on a GSM network, are they?) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] three questions about ntpd, kvm-clock and clock speeds
On -10.01.-28163 20:59, Marco Marongiu wrote: On the web many (supposedly) authoritative sources disagree about how clocks should be synced on KVM hosts and VMs. You can find both those who say that ntpd should run on both sides and others that advise for having ntpd just on the host and have the VMs use the kvm-clock clocksource to follow the host's clock (but they don't say what follow exactly means). Indeed they don't. (Warning, half-rant following.) While one of the web pages you already read states: Keeping time in virtual machine is acknowledged as a hard problem. -- https://lkml.org/lkml/2010/4/15/355 those providing us with the building blocks for virtualized computer platforms fail to realize that keeping a network of distributed clocks synchronized is hardly a *new* problem, and has an existing vocabulary. Namely, those clocks can provide each other: An initialization value, frequency (be it as a delta or as interrupts, and it can be either a raw not-quite-known but hopefully stable frequency from an independent oscillator, or a somewhat less stable but true frequency from an already-disciplined clock), and offset; in addition, aspects of the communication (delay, visibility) may come into play. Instead of telling us in *these* terms what the stuff they've built does, we get a) pages and pages of implementation details of the specific building block in splendid isolation, and b) the shortcut recommendations that say thou shalt (not) run ntpd on VMs without explaining (much of) the reasons behind it. I'm no less confused by the metric tons of a) than you are, but let me pick two such documents, *assume* them to be (still) correct, and show you what my translation thereof would be: Again, this LKML posting: https://lkml.org/lkml/2010/4/15/355 speaks about what goes *through* the kvm-clock interface, i.e., the properties of the Linux kernel running as the *host* OS and feeding it. It says that the interface offers the full current time to the best of the host's knowledge, presumably from its OS clock (which is decoupled from the host's HW clock). Now, if the host is running an ntpd (*), its notion of time will - in the long run - be quite correct, which is to say that the interface will offer good information for both frequency and offset. Here's another LKML posting from the same year: https://lkml.org/lkml/2010/11/15/101 This one speaks about what the Linux kernel *takes* from the clocksources, i.e., when running as the guest OS. And lo, the data provided is only assumed to be a *counter* with overflows, with no way to derive the actual time and date. It also makes mention that clocksources may be independent hardware oscillators. Translation: The Linux guest OS takes only the frequency information from the kvm-clock interface, and doesn't trust that frequency to be true, either (so I'ld *guess* that the usual correction mechanisms of the kernel are left in place between that source and the actual OS clock). Conclusion in the case of the host running ntpd: The guest will take and use the (true) frequency of the host, thus having a good frequency itself with no further measures being taken (unless someone manually disturbs the timing on the host), but has no means to correct offsets yet. Which is what you observe in reality. Hey, we may be on to something here! :-} Still *assuming* that all this information is correct, you can now make up your own mind whether correcting the offset (and countering manual intervention on the host) is something you want to run ntpd on the VMs for (which is an option in the first place only because the information from the host does get filtered through the guest kernel's correction mechanisms, whose controls ntpd takes into its hands). (*) I'm also assuming that the host's ntpd will be using *remote* time sources. Since the vendors do not think in terms of clocks getting networked, few, if any, of their HowTos include the explicit statement that *if* you need to put low-stratum clocks onto your virtualized platform itself, you'd better *not* put them on the *VMs*, so as to avoid a feedback loop from the VM through its own host back to the VM. In one project whose VMs got moved from a provider's platform to a dedicated one, lack of such a statement made the management decide that the master clock should stay where it was, on one of the VMs, *and* feed the new systems, i.e., the hosts. One oscillating platform and emergency maintenance later, things are configured like I suggested from square one ... Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel
Re: [ntp:questions] Questions from people whose return address is gmail, googlemail, Yahoo, etc.
On 09/06/2014 02:21 PM, Charles Elliott wrote: Some day, is it going to be important to ISIS to have accurate time to coordinate a massive strike on the electric, railroad, or bridge infrastructure in some Western country? Are list members going to facilitate that? As long as the definition of accurate time in your question is beyond the precision readily available from GPS, GLONASS, etc. devices, and using ntpd running on general purpose computers, my answer to both is no. Any kind of attack with a physical object doesn't need to be coordinated to that precision unless you need to properly destroy a hardened target, and any computer attacking a network using that precision (there *are* a few attacks where you need the packets to arrive at the victim with precise timing) needs specialized computing machinery in the first place. Not to mention an extremely low-jitter network path between both. Mind, I'm not saying that precision timing cannot be used to *prepare* an attack - the prime example being pinpointing the coordinated triggering of the conventional charges in a Pu-based nuke. But if IS were to spend *that* kind of effort, they'ld had something *usuable* for their purposes (dirty bomb) a lot earlier. I propose that in the short term NTP questions list members not respond to inquires from people whose return address is a bulk email provider, and in the long run the NTP list server be made to reject email from bulk providers, [...] and from domains that are not in the whois database or that do not respond to pings. Disabling pings from the Internet is pretty much standard practice to secure organization-internal networks. Proper WHOIS data is primarily the duty of the ISP, not the domain owner, to provide - some just don't. However, domain plus WHOIS plus e-mail (on ISP's machines) is essentially available dirt cheap with no documents or physical appearance anywhere nowadays, even with certain ccTLDs. And all this is going to be rendered useless by the first IS sympathizer having himself hired by a legit organization, anyway. Or even simpler, one *faking* his sender address to include an appropriate domain (and hoping for on-list replies), like spam does literally every microsecond now. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Client using Meinberg NTP can't sync with ntp server problem
On 07/10/2014 10:24 AM, vothanhhun...@gmail.com wrote: Thanks for your explaination. The reason I use NTP because I want my computer clock have the same time as the server. It is always 1 or 2 minutes behind compare to the ntp server. I admit that it *is* odd that ntpd doesn't change that *eventually* ... But as you said nothing should happen before about an hour from when you started. means there is nothing I can do to force it sync every 10 minutes? Except for some (hopefully rare) extreme circumstances, ntpd *does not* sync (= just copy the server's current time to the client, usually called stepping) the local clock. If that's truly what you want to do (and while still using an NTP server), you need to look at SNTP / ntpdate. Imagine having a wrist watch that, when set to the correct time in the morning, has drifted so much in the evening to make you miss your train home. One solution is to adjust the time a couple times during the day as well, and another is to take it to the horologist to have it repaired so that it doesn't drift (so much) anymore in the first place. What ntpd primarily tries to do is the *latter*, and since wildly *setting* the clock interferes with proper measurements of its drift, fixing the time of the clock (by slews instead of steps) has a somewhat lower priority. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Thoughts on KOD
On -10.01.-28163 20:59, Harlan Stenn wrote: This gets a bit more complicated when taking into consideration: - we'll get more traffic from a NAT gateway - - do we need to be able to configure a threshhold for this case? Can't say much about KOD as-is, but here's my .02 on the net-behind-NAT scenario: If -- you want to fine-tune limits according to the number of actual clients behind the NAT, *or* -- want to keep providing service to genuine clients behind a NAT gateway while defending against co-located noncooperative bad apples then you have an interest to make the NATed clients identifiable (beyond what OS fingerprinting can do already). The straightforward approach to doing so would be to send out not plain go DIAFs, but messages along the lines of I'm willing to service your further requests *if* you label them with this random ID (and behave). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On -10.01.-28163 20:59, Miroslav Lichvar wrote: On Mon, Jun 23, 2014 at 11:45:16PM -0500, Mike S wrote: On 6/16/2014 6:05 AM, Jochen Bern wrote: There are four official slots - two primary, two secondary - over the course of the year to insert leap seconds, Those are only preferences. Leap seconds may be inserted at any month boundary. I'm positive that I've *seen* ntpd do the poll-interval-reduce on a *quarterly* base a couple years back. As Miroslav mentioned, the IERS - the guys who *schedule* leap seconds - currently *use* only the primaries, while still *mentioning* the secondaries as well: Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. [...] According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June, and second preference to those at the end of March and September. -- http://www.iers.org/nn_10828/IERS/EN/Publications/Bulletins/directLinks/bulletin__C__MD.html Of course the number of leap seconds required in recent years helped sticking with only the primaries, so it's a bit unclear to me which of all those choices are for the moment and which are long-term ... Sooner or later, not even 12 leap seconds per year will be enough to keep UTC close to UT1. Hopefully they will be abolished long before that. I do not wish to see that day, regardless of whether you're referring to a couple millennia of Earth-Moon tide-locking or a major off-center impact giving the crust a new spin. :-S Practically speaking, beside having to make more than two corrections per year (which is not expected to happen in the next few decades), could there be any reason to do it in other months than June and December? I've browsed the results of the infamous poll and most of the people voting abolish leap seconds apparently didn't mean to actually *abolish* them (as in, decouple UT1 and UTC, or whatever their successors might be called), but to have them *rearranged* into fewer and larger leaps. Of course, one can imagine that to go the other way - i.e., smaller but more frequent leaps. In general, I consider the entire procedure to first and foremost reflect a couple *external* facts - namely, a) the time necessary to propagate the decision on leap [whatever] scheduling to wherever it has to be carried out (NTP is *not* the critical path there, I'd guess) and b) the (ever-improving) quality of *prediction* of Earth's rotation. If those two restrictions were to be removed (assume a giant tooth fairy if you must ;-), I don't see a reason why the current UT1-UTC delta could not be communicated through an NTP-ng in the same way today's NTP shoves server-client deltas around and corrects for them - piecemeal with every poll. (Returning to your question as phrased, and circumstances as of today: IIUC the quality of prediction *would* already suffice to attempt scheduling leap seconds so as to aim for min-sum-of-squares, rather than predefined schedule slots.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On -10.01.-28163 20:59, Miroslav Lichvar wrote: As someone who implemented support for leap seconds in several applications, I'd really like to see them gone. Fixing all software where time is critical to handle them correctly may not be possible So your POV is that of someone managing computers who sees the attempts to sync a technical notion of time to the movement of the planet somewhere under your feet as breaking features like monotonicity and continuity of the computers' genuine clocks. While I may have started from the same setting, I *did* try to put myself into the shoes of astronomers and people operating satellite systems (which, ironically, includes the popular stratum 0 of GPS). There's not much you can do about the fact that users tend to be mostly friction locked to the surface of the planet while satellites and celestial bodies are not, short of outright denial and perpetual puzzlement why your models refuse to work properly. Personally, I'd say that if a computer's clock's best suited to run on TAI (or equivalent) and all data needs to be converted from it to $TZ for the users, anyway, then having it run on TAI and disseminating and handling a TAI-UTC delta along with the sync and timezone deltas seems like the proper approach. But that wish doesn't change gettimeofday() implementations all over the globe with a snap of my fingers, does it. Making smaller but more frequent corrections would probably only make it worse. That depends on your definition of worse. Results in lower max offsets (that mechanisms like NTP will silently take care of) seems to be a quite popular definition of better, FWIW. To me, it seems the reasonable thing to do would be to decouple UTC and UT1 completely and make the adjustment at a higher level like timezones if necessary. Countries adjust their timezones all the time, we can handle that better. I've seen enough platforms allowed access to a (local) NTP server but not updates, enough such platforms being considered secure(d into a world of their own) enough not to be updated, enough devices whose owners never thought of firmware updates to even *exist*, yadda yadda to assert that the better mechanism of making that data part of regular but fundamentally *optional* OS updates (instead of a well-defined, verifiably secure or at least harmless, dedicated on-demand communication protocol) is downright *nonfunctional* often enough. Too many people expect their devices to usually tell them the right time (:= as per local timezone) with naught but an occasional setting it right (:= manually inserting a single delta with no understanding of the background mechanisms involved) to make you should have updated every now and then an accepted excuse for those devices giving themselves airs of being computers instead (caution, irony). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On -10.01.-28163 20:59, John Hasler wrote: Jochen Bern writes: If those two restrictions were to be removed (assume a giant tooth fairy if you must ;-), I don't see a reason why the current UT1-UTC delta could not be communicated through an NTP-ng in the same way today's NTP shoves server-client deltas around and corrects for them - piecemeal with every poll. And have UTC jump around as erratically as does the Earth's rotation? Why? Might as well set up a tranit and set your clock by the sun. The premise of this statement was to describe a scenario where the UT1-UTC offset as known by random devices would be updated as often as imaginable. Whether your local clock should then attempt to approximate UTC, some variant of UTC with different (upstream) leap [whatever] decisions, actual infinitesimal (and locally-known-only) leaps a.k.a. UT1, or a leapful time based on that latter and rules how to quantize the drift into a (again locally-known-only) sufficiently small leap, is a *somewhat* separate question. I don't know of any telecopes, satellite dishes, ... with an aperture / beam so narrow as to being forced to have the tracking mechanism based on UT1 instead of UTC, but that doesn't mean that there *are no* cases where you need a better realtime approximation of UT1 (preferably *without* setting up your own transit observation gear), and possibly *still* having UTC as well (say, for logging). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On -10.01.-28163 20:59, Miroslav Lichvar wrote: On Tue, Jun 24, 2014 at 03:46:15PM +0200, Jochen Bern wrote: While I may have started from the same setting, I *did* try to put myself into the shoes of astronomers and people operating satellite systems (which, ironically, includes the popular stratum 0 of GPS). Do these people work just with UTC? I'd think it's not accurate enough for their purposes and they need to include the current UTC-UT1 offset anyway. I'm pretty sure that you cannot operate a system like GPS without having a better idea of UT1 than UTC, even if (IIRC) the satellites' downlinks do not disseminate that data to the terminal units. No idea whether looking at the USNO data once a week or day does suffice. All I can say is that transit measurements are, by definition, not available as often as one might like. I don't think that anyone dealing with communication satellites (i.e., in orbit around Earth) or a telescope smaller than a house needs to bother with UT1-UTC beyond the max offset guarantees currently in effect, though. Personally, I'd say that if a computer's clock's best suited to run on TAI (or equivalent) and all data needs to be converted from it to $TZ for the users, anyway, then having it run on TAI and disseminating and handling a TAI-UTC delta along with the sync and timezone deltas seems like the proper approach. But that wish doesn't change gettimeofday() implementations all over the globe with a snap of my fingers, does it. Agreed, but wouldn't switching to TAI everywhere be much more difficult than stopping messing with UTC and keep it a fixed offset from TAI? Having computer clocks run on UTC(frozen) instead of TAI makes the adaptation easier today, more difficult tomorrow (do we *really* need to work on that for (n3) seconds of an offset!?), and no less necessary in the long run (when UT1-TAI has grown much larger than UT1-UTC(frozen), and changes much faster as well). I prefer to have the slope right where the ball needs to get rolling. ;-) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Why DNS servers should not be NTP servers
On -10.01.-28163 20:59, kartik.u...@gmail.com wrote: I am encouraging the use of atomic time NTP server devices rather than DNS servers to serve time. I need to justify, not using DNS servers, to serve time. Please advise. Well the *obvious* argument would be that you want your DNS servers to be virtual machines (easier to move onto another iron in case of a failure) while central NTP servers should be hardware based (better timekeeping). Other than that, a DNS server can be all sorts of a thing, from a cacheing resolver serving your own machines, to serving DynDNS (possibly tied to your DHCP), to a (hopefully hardened) authoritative server for your own domains, to an experimental hardware-accelerated-crypto beast for DNSsec. You might want to be more specific. (Since you want to encourage separate NTP servers, you might also want to note that GPS+NTP units - assuming that that satisfies your definition of atomic time - can be *very* cheap with some DIY.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Pool Server Costs me $40/mo in Bandwidth--is
On -10.01.-28163 20:59, Jason Rabel wrote: Yes, every now and then I too, like the OP, will see huge spikes in my packets received/sent that occur at or very close to an on-hour mark at particular times (like midnight or 4 am), my guess is a poor implementation in a router somewhere. I've never had the time to track it down though because it occurs so infrequently I guess that you *would* have noticed if it were *that* regular, but just in case: There are four official slots - two primary, two secondary - over the course of the year to insert leap seconds, and since there (sadly) is no requirement for stratum 1 servers to raise the leap flags early enough to guarantee that that info will drizzle all the way to stratum 14 at maximum poll intervals, (at least some versions of) ntpd poll(s) more frequently as these slots approach. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] About use of PPS in NTP sync
On -10.01.-28163 20:59, jthul...@gmail.com wrote: I'm looking for a way to speed up the ntp convergence of a system which would be restarted after several days being off. Since you seem concerned about additional frequency offset while the system warms up: Can you turn it on (and, say, let it run memtest) a while *before* booting the actual OS? Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Meinberg M200 remote monitoring
On -10.01.-28163 20:59, l...@larsdebruin.net wrote: I am looking for a good method to monitor my Meinberg M200 GPS unit. [...] I would like to poll the NTP server and then make an RRD and then plot an image on my webpage with the statistics. If anybody has an RRD template, don't hesitate to send it to me :) Throwing an RRD template your way doesn't make much sense until it has been pinpointed what data you can get from the unit, what software you use to retrieve it and stuff it into RRD files (*), and the potential (re)format(ting) issues along that chain. (*) Examples: MRTG and Cacti as traffic recording tools (data will be collected in very regular intervals); Nagios, Naemon, Icinga, Shinken, ... with some performance data backend add-on (NDO/IDO, PNP4Nagios, n2rrd, InGraph, ...) as dedicated monitoring solutions (frequency of requests will increase when something is amiss); just take snmpgets and rrdtool updates, roll a shell script, and put it into the crontab; various commercial, SNMP-aware network management/monitoring tools, if you happen to already have one; ... ... and note that the tool that creates the graph *to put onto your webpage* could still be a bare rrdtool graph, instead of whatever mechanism is provided along with the collector solution. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP servers not accessible on some networks
On -10.01.-28163 20:59, Antonio Marcheselli wrote: Apologies, I sent a reply to your personal email by mistake - Thunderbird has it as default. (Are you accessing via USENET, or via mailinglist? The latter's run by MailMan and if I'm not very much mistaken, there's a pertinent setting in your configs there.) xxx-2:/etc# ntpq -p remote refid st t when poll reach delay offset jitter == 130.88.200.4.INIT. 16 u- 6400.0000.000 0.000 xxx-2:/etc# ntpdate 130.88.200.4 20 May 23:30:11 ntpdate[16690]: no server suitable for synchronization found Try ntpdate -d $SERVER and ntpdate -u $SERVER as well. We had someone's client-side firewall block NTP requests with privileged source ports (1024) lately, the telltale symptom being that *those* variants suddenly worked. :-/ Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP servers not accessible on some networks
On -10.01.-28163 20:59, Antonio Marcheselli wrote: I've got some servers which have stopped synchronising on the configured NTP server. [...] I thought the NTP server had gone down, but then found that in another country I could still sync to the same NTP server. [...] Any chance some ISPs are blocking some NTP servers or maybe port 123 on such servers?? GeoIP blocking (google that) today is an established technology to protect your publicly-reachable networks, especially if the services offered aren't meant or even illegal (copyrights) to be offered to the entire planet. Chances are that access to the NTP servers are a collateral of a central firewall having had such a feature activated - not that that'ld help you any ... Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On -10.01.-28163 20:59, Rob wrote: Apparently there is unresolved discussion whether a .h describing a PPS API belongs in the set of kernel include files or in a separate package. There is? Can't say I've ever dealt with PPS, but *if* this .h provides the necessary information that *several* pieces of userland software need to use a kernel API, with the details/version of that API tied to the underlying kernel version and nothing else, then there should be only three kinds of package suitable to provide that .h: a) the kernel itself (i.e., always present), b) the package providing the kernel module providing the API (*if* made into a module for the distributed kernel), or c) a hypothetical devel package that provides the .h, but *not* some set of userland utilities on top unless they're strictly necessary (e.g., to configure the API in some way before it can be used). Of course, if there's some history of this API's development that needs to be taken into account for compatibility reasons, things can get ... complicated. There's no such thing as 'if [ -f foo.h ]; then #include foo.h ; else #include my_foo.h' (post-./configure) ... But the separate package pps-tools which includes this file already exists. I wonder whether we can take the package description: https://packages.debian.org/de/sid/pps-tools as an actual declaration of *intent* from Debian to keep the .h there. I don't understand why this is a problem that can be fixed in a minute. There must be TENS of packages that have to be installed on the build machine to successfully build the binaries in the distribution. Compilers, linkers, packaging tools, libraries, etc etc etc. Can't they add just one simple package to that? Well *there* you're confusing the software installed on it *to make it a build machine* and the packages installed so as to *get built*. Imagine cross-compiling being involved and you'll see how one needs to be kept separate from the other. I'd imagine that the folks dealing with embedded devices would have a couple choice words about forcing the entire pps-tools into *every* installation just so as to make the PPSAPI available, maybe even the IT security people (particularly if there's set[ug]id involved with them). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On -10.01.-28163 20:59, Rob wrote: What I mean is that for building packages they need not only building tools but also -dev packages for many libraries that are going to be used by the packages being built. There is a long list of packages that one is supposed to install before even attempting to build a single package from source, and then the particular package adds more requirements. This timepps.h file is just one tiny little file between many other .h .a and .so files. Ah, I see. So there actually are *three* areas of installed software on a build system that need to be properly set up: The stuff that makes the build machine itself (architecture A) run, the packages that you want it to produce (for architecture B), and the source/devel packages that those latter need only *during compilation*. FWIW, you might find this open Debian bug interesting: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672 It does not only state the problem, but also lists the proper technical term (Build-Depend) and an e-mail address to (supposedly) poke the actual package maintainers through. (And IIRC Debian is the upstream for a fair *lot* of distribs.) But, for sake of completeness: While the Build-Depend needs to point to whichever package contains timepps.h, the question of whether that file *belongs* there is, I gather, rather irrelevant for ntp package brewmasters. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
[Resend to list, rather than non-working(?) sender e-mail address] On -10.01.-28163 20:59, Rob wrote: We are setting up a co-channel diversity network. That means multiple FM transmitters that are transmitting the same signal on the same frequency on different sites, where the receive areas partly overlap. The listeners should enjoy a smooth reception while driving around. So of course there should be no time lag between the modulation signals of the different transmitters. Experts in the field tell us we should be within 12us. I'm afraid I don't get it yet. You're trying to sync waveforms on the HF side (~100 MHz?) instead of switching between two transmitters on the AF side (couple kHz, with that much more leeway for the sync), a la perfectly normal car radio with RDS AF and dual tuners, because ... ? https://en.wikipedia.org/wiki/Radio_Data_System#Content_and_implementation Anyway - if you'ld like to talk to people who apparently have experience with syncing the HF side, at least to *some* degree, you might want to contact the companies operating the (toll) highways in France. They also operate radio stations with traffic announcements, and it's just *one* frequency (107.7 MHz) all across the country (since before the time they adopted RDS at all). I never noticed any transmitter hand-over within any single operator's coverage (while handover from one to another, with a completely different radio programme, is of course rather messy). http://www.autoroutes.fr/en/FM-107-7-radio.htm Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On -10.01.-28163 20:59, Rob wrote: Jochen Bern jochen.b...@linworks.de wrote: I'm afraid I don't get it yet. You're trying to sync waveforms on the HF side (~100 MHz?) instead of switching between two transmitters on the AF side (couple kHz, with that much more leeway for the sync), a la perfectly normal car radio with RDS AF and dual tuners, because ... ? It is not an FM broadcast system, it is an amateur radio repeater system with wide area coverage. Alright, I think I'm closing in on some basic concepts now. :-} You have existing mobile FM transceivers and existing individual repeaters (including the non-equidistant rather far in-between sites they're installed at) and you want to add sort of a central control to the repeaters so that they act in unison, relaying one input to the *entire* coverage area, and in such a way that the mobile transceivers do not have to care (read: QSY) which single repeater they're currently covered by - RX as well as TX. First good news, you won't have much of a problem if a participant getting handed over from one repeater to another experiences a time jump (relative to the master audio stream) even of several tenths of a second. Second good news, the audio stream will likely experience pauses (everytime one OM hands the mic to another) more often than the mobile devices will need to switch over to a new repeater. With tight enough a squelch, your repeaters can actually drop output power during that pause, which might help the mobiles switch over even in the presence of capture effect etc. during the power-up phases. On the not-so-good side, once a random participant finally got the PTT squished, your repeaters will have to have a quorum decision which repeater's *input* to use for the master audio stream of the entire system. (And you might want to modulate the repective repeater's ID over it in CW, or else crocodile hunting will get pretty tedious. ;-) However, that *does* leave me wondering where the 12 us figure comes into play. With the typical distances between 2m and even 70cm repeaters, the mobile transceivers will see shifts *far* beyond that between different repeaters' signals. FWIW, will you have the audio cards output AM (that will then get modulated onto an otherwise unsynchronized HF), or do you plan to have the card generate HF directly into the PA? Regards, DD0KZ -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] TrueTime XL-AK GPS lock satellite take too much time.....
[First reply to a MIME digest, hope the In-Reply-To doesn't end up as broken as the timestamp in the following line :-C ] On -10.01.-28163 20:59, Victor wrote: when I first start the system, it only take about 10 minutes to lock satellites. [...] But the second time I move to another place (about 40 miles away from the first place), it never lock any satellites again. 40 miles PARALLEL TO PLANET SURFACE :-} shouldn't make much of a difference in general sat signal irradiation. You might want to doublecheck, though: http://satpredictor.navcomtech.com/ Do you have any information whether the signals that the device receives (post building-induced interference, nearby machinery, coax cable kinked while moving, ...) have actually gotten *weaker*, rather than same, but just won't lock? Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server with two default routes misbehaving after upgrade
On 22.04.2014 11:45, questions-requ...@lists.ntp.org digested: From: Caecilius nospam@spamless.invalid 1. tcpdump shows that the packet-level behaviour is the same for ntp 4.2.4p4 and 4.2.6p2. Namely packets to a given peer switch from one source IP to the other approximately every 10 minutes. So the packet-level behaviour hasn't changed between NTP versions, but what has changed is that 4.2.4p4 didn't seem to care wheras 4.2.6p2 resets the peer when this happens. FWIW: a) Different OSes have different default behaviors when there are several fully equivalent source IPs (including the routes marking them as suitable for the target IP in question) to use. It's been a while, but IIRC Linux is *not* prone to switching them under your feet. (More precisely, what I remember is: SunOS uses the first to have been set up, Linux the last, and *BSD round-robins.) Your machine flip-flopping instead *might* indicate some problem that the newer ntpd merely made more visible. b) Assuming that both the flip-flopping and ntpd choking on it have good reasons you cannot or should not ignore, you might want to do what EBGP peers do - set up host routes that nail down which ISP connection (and, supposedly, which source IP) will be used for which peer. (Of course, EBGP and other EGPs do that because they need the peering to work *before* they receive information from the peers and populate the local routing tables with it.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] questions Digest, Vol 114, Issue 35
On 21.04.2014 02:15, questions-requ...@lists.ntp.org digested: From: David Woolley david@ex.djwhome.demon.invalid Such digesters normally offer a MIME digest mode. Thunderbird can cope with that and allows you to extract an individual message from that and thread a reply to it properly. Found and flipped (as I don't remember a specific reason to have had it set to Plain Text - which turns out to be largely RFC 1153 compliant - beyond my dislike for HTML e-mails), thanks for the hint. I'll continue to analyze when the next digest's arrived. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Automatic time synchronization of local hw clock
(Sorry, MIME setting didn't have an effect yet.) On 22.04.2014 13:07, questions-requ...@lists.ntp.org digested: From: Mimiko vbv...@gmail.com Asking about some much trouble in time keeping in linux, I meant about not having a out of the box time synchronization with some server on internet, like windows do. Linux doesn't assume out of the box that you *have* Internet access or any other infrastructure to use. *If* you tell it to install ntpd from a current repository/distribution (as opposed to a source install), it will usually come with a config pointing to a pool. In cases where you *pay* for your Linux installation in the first place, it *might* even be a pool of servers operated by, and for the purpose of, your Linux distrib (e.g., RHEL), like Microsoft does with the servers non-AD Windows installations default to. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Automatic time synchronization of local hw clock.
On 20.04.2014 14:00, questions-requ...@lists.ntp.org digested: From: David Taylor david-tay...@blueyonder.co.uk.invalid It would be helpful if the operating systems were to agree on how to use the BIOS clock. Well, if I understand the statements about Win correctly, they *do* now, at least in their current versions. Not every computer travels during the year Traveling computer with a localtime RTC: Problem. Multi-boot computer with RTC using a localtime with DST: Problem. Computer produced abroad having its RTC set to localtime there: May prove a problem. (Very real support cases over here. We're now seriously pondering to have the firmware-generated CAs *lie* and make certs' validity start a day or more *before* what the appliances consider now at the moment the request button's pressed.) Computer with UTC RTC: ... um. Problem? See below ... and not every location has summer-time transitions. Actually the *majority* of places on this planet do *not* use DST *now*: https://en.wikipedia.org/wiki/Daylight_saving_time (Unless you want to split hairs and call Russia using DST, only all year 'round, I suppose.) Doesn't matter, either. Errors are minimized by taking an approach that is 100% *technically* consistent and feasible, and basing computer systems' core time on a global, continuous, non-overlapping notion of time (*) *independently* of whether the local legislator sees the same light is just that. (*) The issue of leap seconds notwithstanding. Most users would likely be very confused were they to see the BIOS clock time in UTC! Any user feeling a need to correct the RTC to his local time would also immediately agree (but hopefully not *remember*) that he should check back when DST switching occurs, and effect that himself if it doesn't occur automagically (which it won't while he's in the BIOS monitor). Please elaborate on how you want an RTC-is-localtime OS to successfully counteract *that* act of sabotage. Teaching users that things like a world time exist may prove easier IMHO. (Might be a suggestion to have such a hint added to the BIOS tools, though.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Header-tiquette (was: NTP.log interpretation)
On 19.04.2014 14:00, questions-requ...@lists.ntp.org digested: From: David Woolley david@ex.djwhome.demon.invalid On 18/04/14 21:15, Jochen Bern wrote: [Unthreaded reply.] Are you aware that you mail/news client is broken and is not threading your replies properly. If you are using the mail list, you need an In-Reply-To header. If you are using the newsgroup, you need a References header. [Directed back to the list/newsgroup due to lack of valid sender address to reply to directly] You might want to note from the very first line in my replies that I'm subscribed to the mailing list in digest mode, and chances are that a quick inspection of the headers on your end would have shown you not only In-Reply-To: and References: headers, but also a User-Agent: header mentioning Thunderbird. The problem is, of course, that Thunderbird will (correctly) fill in the former ones with the Message-Id: of the digest it receives and displays, not references to the pre-digestion mails/postings. I actually once *tried* to add In-Reply-To to the mail.compose.other.header config so as to manually fill it in with the original Message-Id: (quoted in the digests' body), but found that the autogenerated one would invariably replace my manual input instead. I admit that I haven't searched for an *add-on* to shoehorn into my Thunderbird that might further grok digest mails, though. Anyway, if failure to produce normal threading headers is as verboten as you claim, then it's not my user agent that is broken but the fact that the mailinglist server offers digest-mode subscriptions in the first place. (And, by the way, prefixes them with only this set of explicit instructions: When replying, please edit your Subject line so it is more specific than Re: Contents of questions digest... Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Header-tiquette
On 20.04.2014 22:35, Jochen Bern wrote: I haven't searched for an *add-on* to shoehorn into my Thunderbird that might further grok digest mails, though. (FWIW, I found Undigestify 0.8 https://addons.mozilla.org/en-US/thunderbird/addon/undigestify/ which would probably allow for correct In-Reply-To: headers, but generates dubitable References: headers and floods your mail folders with *both* original digests and N+2 reconstructed pseudo-originals.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP.log interpretation
On 18.04.2014 20:45, questions-requ...@lists.ntp.org digested: From: GregL greg.leibfr...@gmail.com What about the idea of going to only one entry, but that entry is served by a DNS load balancer to choose one of two internal time servers to check. Well, that will [...] I'm wrestling with that very question. With 100+ systems, we have a far greater problem if some systems are *off* and others are not. Am I missing something, or will the setup described above (and assuming that the two servers disagree again) *force* your clients to do what you just called the far greater problem? Namely, being randomly split 50/50 between the two servers, not even *knowing* of the other one? (FWIW, ntpd does the DNS resolution *once* when loading its config and works with the one IP obtained from then on, plans of implementing automatic rotation/selection of pool servers in future versions notwithstanding. And having potentially disagreeing NTP servers put behind a V*IP* load balancer is discouraged as well.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Automatic time synchronization of local hw clock.
On 17.04.2014 14:00, questions-requ...@lists.ntp.org digested: From: Martin Burnicki martin.burni...@meinberg.de Usually it is sufficient to set the RTC on system shutdown, so that it keeps time while the machine is powered off That is, of course, assuming that the machine in question *has* an *orderly* shutdown every now and then. Servers in well-protected internal networks may well see far more crashes (and WTH is the RTC set to!? questions by not-yet-initiated operators) than intentional shutdowns. (Never tried it, but wouldn't laptops that get suspended and then somehow are forced to go through a full reboot instead of a wakeup circumvent that sync schedule, too?) From: William Unruh un...@invalid.ca I do not believe that ntp ever considers it its job to write the rtc. If I'm not *very* much mistaken, very old versions of (x)ntpd (predating Linux' support of localtime RTCs to allow for a dual-boot setup with Win, if not predating Linux altogether) contained code to do periodic updates to x86 RTCs directly (assuming them to run on UTC, of course), said functionality *missing* in the back-then Unixoid OSes on x86. Of course, that went down in flames when non-UTC RTCs came a-knockin' and required the OS to join in and do the UTC-localtime conversion for the non-zone-aware players. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On 10.04.2014 14:00, questions-requ...@lists.ntp.org digested: From: Terje Mathisen terje.mathi...@tmsw.no Rob wrote: OF COURSE ntpd should simply listen for SIGHUP and when it is received re-read the config file. Like almost all Unix daemons do. Here's the crux of the matter: ntpd is _not_ a Unix daemon, or at least not just that: The same code runs on many different operating systems, some of which don't implement SIGHUP at all, or at least not in a compatible manner. Now this sounds dangerously close to ntpd cannot possibly use a config file, because it is supposed to be running on various OSes with incompatible character and end-of-line encodings ... From: Harlan Stenn st...@ntp.org Amongst the many reasons why we did not let SIGHUP restart the daemon was that back in the old days we used modem drivers a lot more often. The HUP signal was generic - it was not really associated with any specific device. I wouldn't be surprised if spurious SIGHUPs were still occuring (and possibly reaching unrelated daemon processes) today - just think of how many DSL routers happen to have a unixoid OS and are actually running a pppd (whose manpage mentions HUPs a lot). Point is, for daemons *other* than ntpd, rereading the config that nobody did edit will likely have no noticeable effect at all. For ntpd, with the round robin DNS pools yielding different servers every time you resolve, and possibly losing status even for those servers that did *not* change ... things might look different. Then again, it's not like there are no established unixoid methods *other* than HUP - from USR1 (no example whose name I'd remember off the top of my head) to polling the config file's stat() periodically (a la /etc/crontab) to a simple CLI via local special files (a la Nagios command pipe, or even echo 1 /proc/sys/foo/bar) to opaque IPC hidden behind a dedicated util's command line options (a la apachectl, or fetchmail --quit). At the end of the day, lots of people - and the most important clustering solutions - won't care to look past the OS' meta-command, be it service mumblefoo reload or svcadm restart mumblefoo, as long as that *works*. :-} Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On 08.04.2014 20:30, questions-requ...@lists.ntp.org digested: From: Arthur Lambert lambertarthu...@gmail.com Hi David, I don't get your point. You know that we can live just with fire ? Why do we invent electricity And computer ? This is exactly the same here. I change the channel on my tv, I dont want to reboot it to get the new tv channel It's worked ok but it a very strange choice of architecture. But I can guess with your answer that I cannot handle modification on my ntp conf without restart it. I will try to patch it to get it work with my need. As Paul already noted, there *are* mechanisms to change aspects of the configuration during runtime, but they've gotten *quite* disparate from the effects that a restart with a changed config file has, up to and including downright missing functionality. In other words, you *do* have an interest to check whether the changed config file does work as expected while you're still sitting there with the editor at hand. Or else, to stay in your analogy, you might find that your TV happily changed channels for years on end, but flat out fails to turn on after a power failure (or OS update, or ...) finally rebooted it for you. From a theoretical point of view, restarting ntpd on a single server will force it to drop its working stratum and associations for a while, but its system clock should continue to be fine-tuned according to the latest results (loaded from the drift file) with virtually no interruption. That shouldn't be a problem unless other hosts sync against that one - in which case having more than one local server for your clients would be the proper fix. There's no genuine advantage (caches loaded, more statistic Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On 08.04.2014 22:28, Jochen Bern wrote: There's no genuine advantage (caches loaded, more statistic ...al data gathered, priorization through higher uptime, ...) for an ntpd in having a higher runtime. (Sorry, badly placed touchpad sent the original mail prematurely.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] questions Digest, Vol 114, Issue 2
On 01.04.2014 22:00, questions-requ...@lists.ntp.org digested: From: Sander Smeenk ssme...@freshdot.net | dns2.dns.dmz.bi 172.2.53.81 2 u 421 1024 2770.882 -0.418 0.362 | dns3.dns.dmz.bi 172.2.53.81 2 u 547 1024 3761.227 -0.577 0.386 Random idea, did you grep through your /etc/hosts and split horizon DNS (if any) configs for that IP? Just in case it's some lookup generating that string by means of a typo-ridden entry there. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd access restrictions: Server allowed works only with ipaddress
On 29.03.2014 13:00, questions-requ...@lists.ntp.org digested: From: Witt, Stefan stefan.w...@dataglobal.com Hello, looking for an answer of the following misbehaviour: Server entries are only valid and accepted if I use ip-address and not if I user fqdn of the timeserver1/2! Resolving of Timeserver-fqdn is successful! And what *do* they resolve to? Single A or RR? Several? CNAME? Other RR types? Any odd characters or unusually long parts in the FQDNs that might trigger different implementation limits in different resolver libraries? Does your resolver library support the search keyword in /etc/resolv.conf ? Any chance that your searchlist (if yes) / suffixes of your local domain as configured in the hostname (if not) lead to an unintended match when combined with the FQDNs? From: David Lord sn...@lordynet.org Ntp works with ip addresses because fqdn can sometimes map to more than one ip address. If that's the case, and assuming that they're *external* servers, it should be assumed that the server operators *want* clients to automagically get distributed over those IPs by means of round-robin DNS, and would frown upon client admins counteracting that (by entering IPs into ntp.conf and/or /etc/hosts). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Graphing NTP bandwidth usage?
On 27.03.2014 10:50, questions-requ...@lists.ntp.org digested: From: Jason Rabel ja...@extremeoverclocking.com One of the graphs of particular importance to me was where they showed NTP specific inbound outbound bandwidth. For the life of me I can't figure out how they did it though. Too many possibilities to list, I'm afraid. :-} Since I'm dealing almost exclusively with Linux servers, *I* would have the NTP packets matched by iptables ACCESS rules on the host itself (in whatever detail you'ld like to see in the final graphs), read the rules' counters in regular intervals (using cron, MRTG, Nagios, whatever), and graph from there. ... we *are* talking about the *NTP peer's interfaces'* bandwidth, not the totals at your Internet uplink, aren't we ... ? Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On 23.03.2014 03:24, questions-requ...@lists.ntp.org digested: From: Daniel Quick daniel.qu...@gmail.com Do we want a Netspeed setting that assists with taking the load off some of the more heavily, higher-speed servers? or do we want to keep a setting where we serve fewer clients with the highest resolution of time given specific setup and let the client queries grow from there? I suppose this also takes into the smart dns load-balancing that goes on in the background. IMHO the answer to that question changes *a lot* for different kinds of clients. To take one extreme example, if we're talking about appliances which can possibly run for years without a reboot and decades without getting updates installed (but still shall be supported indefinitely), the appropriate precaution would IMHO be to avail yourself of a good-sized chunk of PI IP addresses and have the clients distributed over them DNS-round-robin-style right from day one. The option of having all those different addresses NATed (*) to a farm of servers whose numbers adapt to the actual load follows trivially. If those same appliances are manufactured in numbers you can control, and will mostly or forcibly-all receive and install updates you publish, on the other hand, you can plan for and maintain hardware- and/or firmware-generation-specific sub-platforms on the server side. Note that that also allows you to cleanly transition clients between incompatible server versions - made-up example, switch data *signing* cryptalgorithms - if and when required. Off the other end of the spectrum, dealing with very few software-based senior-sysadmin-shepherded clients that have very high quality requirements IMHO strongly suggests that you want to invest the extra work to set them up with cryptographic authentication and individual key(pair)s, thus making a who the $#§ set up the FQDN 'pool.evil-ntp-underground.ddos.me' to point to our server!? scenario a lot less probable. Then there's possibilities like regional anycasts, running a *pool* of only your own sites, whether you have to deal with restrictive/static/non-DNS-aware client-side firewall configurations (or can have your appliances run a P2P NTP network to take load off your actual *own* servers ;- ), ... Regards, J. Bern (*) Or, if you're afraid that the initialization of NAT with the first client - server packet may introduce a net asymmetric delay, set up each server with umpteen public IPs. -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] questions Digest, Vol 113, Issue 20
On 14.03.2014 05:30, questions-requ...@lists.ntp.org digested: From: Mauricio Tavares raubvo...@gmail.com If you look at the website for time.gov it does display the time being off by 4 min. It's correct within wristwatch-and-eyeball accuracy for me right now. Call me odd, but being off by 4 minutes does not seem to be bad. I mean, even a default kerberos install would be cool with that. Well, that depends entirely on what you want to *do* with your synchronized time. I don't know why Oliviers students would find a 4m offset on their cell phones so outrageous (missing the bus? Or wasting an extra 4m in the classroom waiting for a teacher whose arrival times likely have more jitter than that?), but the computing center guys back at my university installed their GPS receiver when they had to debug a problem that repeatedly killed a pair of Cisco routers. The tens-of-ms precision provided by a central ntpd with DCF77 reception wasn't enough to correctly correlate the logs collected from each unit's NVRAM after resuscitation. Do you remember the headlines a couple months ago when physicists thought they had measured particles traveling a percent or so faster than the speed of light? That was a clock out of sync by some fraction of a second, too. They had miscalculated the correction needed to counter the GPS signal's propagation delay from the surface to the cavern where the particle detector's master clock sits. And prepare to use *several* pool servers instead of one, recommended precisely to avoid such a scenario. I always thought the best thing to do is to have your own ntp servers which then are used by your servers. And then those ntp servers can query whatever pool you want to use. It is, but as long as *one* randomly selected pool server may turn out to have all sorts of issues, you want your gateway server(s) to use *several* pool servers nonetheless. (Or several pools, or several types (pool and non-pool), or a local clock on top, or whatever avoids the SPoF.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time of by 4 min
I work for a college and a lot of my students are complaining that their cell phones are off by 4 min. My servers poll us.pool.ntp.gov. (I trust that that's org .) The cell phones poll from time.gov. If you look at the website for time.gov it does display the time being off by 4 min. It's correct within wristwatch-and-eyeball accuracy for me right now. Would be nice if pool.ntp.org would display it's time on the site so I can see if it's actually an internal issue. *.pool.ntp.org entries are *pools* of NTP servers run by whoever owns a particular one, so technically, the pool doesn't *have* a single inherent time (available from all members equally) that the website could display. Identify the (single ... ?) *IP* your servers currently poll so that *that one* public server can be scrutinized. And prepare to use *several* pool servers instead of one, recommended precisely to avoid such a scenario. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] When can I get leap second indicator by ntpd
On Fri, 7 Mar 2014 14:02, Michael Tatarinov wrote: 2014-03-07 13:52 GMT+04:00, Harlan Stenn st...@ntp.org: Williams Catherine writes: I want to know when I can get the leap second indicator by tool ntpq. Up to a month in advance. but not ntp4.2.7, it's up to a day. NTP peerings merely *forward* the indication (except for some rare exceptions, i.e., ntpd with installed leapseconds file), so you'll get it whenever your current sync path's ultimate source (clock) gets aware of the upcoming leap second, plus propagation delay. IIRC DCF77 starts broadcasting a leap announcement about one hour prior (historic observation, not an official spec), some other distribution systems (that I don't remember by name offhand) do not provide such an indicator at all, etc.. Note, too, that ntpd (at least the somewhat elder-lish versions I've seen) does contact its peers more often as one of the four yearly leap second slots approaches, so as to speed dissemination of leap indication. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] need option to ignore 'leap not in sync error'
On 16.01.2014 08:00, Arjun Sanal wrote: The setup is a blade server, which has one master blade server which runs the ntp server. All other blades sync the time from this master. The master itself gets it time from a higher ntp server. The problem is when the master says that it is not suitable for synchronization, the client blades shouldn't reject it. If they, do all the blades will end up with different time. FWIW, that's the prototypical case where I'ld turn the master's local clock into a pseudo server (a la # Undisciplined Local Clock. This is a fake driver # intended for backup and when no outside source of # synchronized time is available. server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 7 ), in spite of the problems it causes. (*One* of the problems being that you'll need to ensure that the master boots up with its time initialized sufficiently close to the true time that the offset won't prevent it from syncing over to the real servers. And/or that your monitoring will alert you when that happens.) Kind regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How is the NTP build tested?
On 14.01.2014 18:53, William Unruh wrote: On 2014-01-14, Terje Mathisen terje.mathi...@tmsw.no wrote: The entire NTP ensemble, from the current machine and up to all its sources, constitute a distributed control loop, right? This means that the stability and eventual precision of any given clock depends upon exactly how all the source (server/peer) clocks behave, it is easy to come up with scenarios that will become unstable and lead to oscillating clocks. Well, no. It is precisely to stop feedback loops that the whole issue of stratum was set up. A stratum x system cannot use a stratum yx as a source or it becomes a stratum y+1 system. Without feedback you are not going to get instability. If this were possible, it would be a problem even with the ntpd algorithm. Sorry, no. It's perfectly possible for an ntpd to cycle its sync source through several different-strata servers, rather *common* even if you're using 127.127.1.0 for a high-stratum one AFAICT. That's a huge delay buffer in the feedback loop through your peered systems, sure, but a loop it still can be(come). Kind regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Brian Utterback wrote: On 12/27/2013 5:50 PM, Jochen Bern wrote: On 27 Dec 2013, Brian Utterback wrote: Is a peer list really a big problem? It generally doesn't make sense to have much beyond 10 peers. Are there really a lot of servers with a lot of peers? If you mean to ask whether such a setup exists at all, here's a real world example: # ntpdc -n -c monlist | wc -l 602 But monlist doesn't work with the latest software. It was replaced by mrulist which requires a handshake at the beginning, so the request address can't be spoofed. That's what I meant by having to upgrade no matter what we do. Well, in this specific instance, the use of noquery on our server supposedly disables all problematic request types without disabling any functionality that the appliances need to have available, so the question remains somewhat academic in any case - for now. Also, I don't see the appliances using any functionality beyond client mode synchronization - a very small, well-tested, likely pretty problem-free subset of the NTP protocol - anytime soon. (I'ld be grateful if someone could point me to case studies on large-scale autokey deployments, in particular using MV, though. Our server's *not* forcing use of NTPv3 keys for auth because we would have risked problems of scale with that.) However, having that said: Back when I was asked how we could provide out-of-the-box time sync for our appliances, I remembered a couple horror stories and told RD that the company'd better be prepared to run the server(s) themselves, on IPs as unchanging as possible (no re-resolving of FQDNs by the client 'til restart), providing support (including backward compatibility, of course) for *years* beyond the EOL of the relevant models/versions, yadda yadda. Now you tell me that, lest we become an unwilling contributor to online attacks, we have no other choice than to keep(?) updating the entire system to ntpd versions that are actually *ahead* of what the upstream OS distrib hands us, dropping entire request types on the floor when they're found to initially(!) have been implemented in an insecure manner. In our ears, that translates to much more QA effort with considerably less-tested 3rd-party-software versions, customers will complain about us effectively throwing a kill switch on their not-quite-new but still working appliances all the time, and the newest and bestest version will force customers to update even the most well-protected internal servers of theirs accordingly before they can successfully configure our appliance to use these instead of our default server. We see local sysadmins flat out *refusing* to update their appliances (sitting in well-protected internal networks) for fear of stumbling over some incompatible change in the actual production process. You're saying that if a problem-solving update is *available*, it's ipso facto the only countermeasure *needed*? Well, you're betting your reputation on *those* people updating faster than the security hole *on our server* will get exploited, then. (Or at least faster than other effective countermeasures.) My hopes would rather be on having fine-grained control of what requests the server does or doesn't answer, beforehand. And ideally a thought or two having been given about clients degrading *gracefully* as I'm forced to cut down on their server-side support. Kind regards, J. Bern ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
Charles Elliott wrote: I looked up amplification attack. [...] But the same website that defined amplification attack also described the solution: Use TCP/IP. Is not that just one more reason to switch ntpd, nptq, and ntpdc from UDP to TCP for query processing? I'ld like to make another - possibly *mostly* identical - suggestion along more immediately relevant technical dependencies: -- Any requests where the timing of query and answer are relevant should use UDP (so as to keep the OS' TCP stack's packet resends out of the picture). -- Any requests where packets beyond the Internet's minimum usable MTU (current consensus 400 Byte IIRC) may be created should use TCP (so as to benefit from path MTU discovery without having to reimplement it). -- (Corrolary: Any requests that require both assembly of a lot of data *and* relevance of timing are a problem in and of themselves.) -- The remainder can be distributed in such a way as to smoothen the big picture. -- (Nonetheless, admins should be allowed to enable backward compatibility modes.) From the POV of amplification attacks mitigation, all challenge-response systems should work more or less the same - whether the challenge is a TCP sequence number, a random number, a HMAC(request,current time,PSK) that allows well-known requestors to know the PSK beforehand and solve the challenge right with the *first* request, a normal auth system of NTP, or whatever. Greg Troxel wrote: Do people think that simply replying to the basic time measurement protocol exchange is a security bug? If so, why? (Probably not what you meant, but there are platforms where manipulating the machines' time is a possible preparatory step for an attack - think CA. If so, being able to read back whether that step succeeded is, of course, helpful to the attacker.) Kind regards, J. Bern ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] simulate leap second
On 27 Dec 2013, Williams Catherine wrote: I want to simulate leap second case. I have one linux server as NTP server. How can I make the server get leap second indicate? The first question you'll need to answer is whether you can run the machine(s) in question with their time set to a completely fake one. If not, your experiments are limited to the actual leapsecond slots - 23:59:60 UTC on the last day of each quarter. (Only the primary slots on 31-Dec and 30-Jun have ever seen *real* leap seconds, but last I checked, ntpd (still?) did increase the request rate for the secondary slots as well.) Note that the next such slot is in only ~100h. You didn't say what exactly you want to find out, but *if* you cannot use a fake time *and* the goal is to replicate the mechanisms that will get triggered in a real leap second while your ntpd is running with its normal setup, I'ld recommend that you inject the fake leap second into ntpd. (As opposed to second-guessing the ntpd-to-kernel mechanisms and injecting the fake leap second directly into the kernel.) Having that said, the easiest method to inject a fake leap second into an ntpd is to fake it into a leapseconds file, as ntpd having one set overrides most of the network announcements mechanisms. http://www.eecis.udel.edu/~mills/ntp/html/leap.html Regards, J. Bern ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 27 Dec 2013, Brian Utterback wrote:
Is a peer list really a big problem? It generally doesn't make sense to
have much beyond 10 peers. Are there really a lot of servers with a lot
of peers?
If you mean to ask whether such a setup exists at all, here's a real
world example:
# ntpdc -n -c monlist | wc -l
602
We ship appliances to SMBs whose factory-default setup points them to
this NTP server (i.e., no filtering by client IP). The local admin's
supposed to change the config to local NTP, SMTP, etc. etc. servers, but
not all of them do, to put it mildly. :-{
Typical? Certainly not. *Lots* of such servers? Hmmm, let's say
possibly enough (to still allow such attacks to happen unless they can
be prevented by careful configuration).
(FWIW, in the meantime, I added nopeer, which I had initially left out
in favor of several setvar ... defaults.)
Regards,
J. Bern
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 4.2.4p8 - 4.2.6p5 less frequent driftfile updates?
On 19 Dec 2013 16:54 +0100, Terje Mathisen wrote: This is intentional, in order to lace less load on the hard drive/flash drive of embedded/small servers. :-) I see. I admit that our SAN admin *did* complain about high IOPS figures lately ... ;-D On 19 Dec 2013 22:47 +, Harlan Stenn wrote: Also see the nonvolatile directive in the ntp.conf file (described in the miscopt.html page). And *that* explains why the age alerts didn't appear until the drift estimates had settled again, half a day or so *after* the update. The driftfile having a resolution of milliPPM suggests that with the default value of nonvolatile, an update should be written at least every eight hours unless the difference happens to stay at *zero* within that resolution. I'll see what limits of WARN=9h CRIT=24h will do, thanks for the pointers. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] 4.2.4p8 - 4.2.6p5 less frequent driftfile updates?
Hello everyone, about 40h ago, I updated half a platform from CentOS 6.4 to 6.5, which includes updating ntpd from ntp-4.2.4p8-3.el6.centos.x86_64 to ntp-4.2.6p5-1.el6.centos.x86_64. One of the updated machines holds the platform's Internet-bound NTP connections, and has some extra monitoring for that - which now alerts us to the fact that by now, the driftfile gets updated only every 6+ hours, rather than every hour (modulo sync problems) as before. A quick scan seems to confirm that the update frequency is tied to the ntpd version running on the machines: $ date ; for MACHINE in $INTERNETFACING ; do echo ; ssh $MACHINE \ rpm -q ntp ; ls -l /var/lib/ntp/drift 2/dev/null ; done Mi 18. Dez 19:03:06 CET 2013 ntp-4.2.6p5-1.el6.centos.x86_64 -rw-r--r--. 1 ntp ntp 7 18. Dez 15:18 /var/lib/ntp/drift ntp-4.2.6p5-1.el6.centos.x86_64 -rw-r--r--. 1 ntp ntp 7 18. Dez 18:20 /var/lib/ntp/drift ntp-4.2.4p8-3.el6.centos.x86_64 -rw-r--r--. 1 ntp ntp 7 18. Dez 18:11 /var/lib/ntp/drift ntp-4.2.4p8-3.el6.centos.x86_64 -rw-r--r--. 1 ntp ntp 7 18. Dez 18:29 /var/lib/ntp/drift ntp-4.2.4p8-3.el6.centos.x86_64 -rw-r--r--. 1 ntp ntp 7 18. Dez 18:21 /var/lib/ntp/drift ntp-4.2.6p5-1.el6.centos.x86_64 -rw-r--r--. 1 ntp ntp 7 18. Dez 14:13 /var/lib/ntp/drift ntp-4.2.6p5-1.el6.centos.x86_64 -rw-r--r--. 1 ntp ntp 7 18. Dez 13:22 /var/lib/ntp/drift Is this change of behavior intentional? Kind regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
