Re: [ntp:questions] NTP Autokey - who is actively using it?
We were using autokey at our public ntp servers(1) since 2011. We are
now in the middle of a process to deactivate it, since 4.2.8 is broken
(we could not make autokey work with 4.2.8 on Linux, it seems to be some
issue related to the version 1.0.x of openssl).
Probably we will let it deactivated. Maybe we are going back to
symmetric keys (at least between the servers), even if the issue is
fixed. We fostered our users to try and adopt autokey, but it seems
there was no interest in the feature.
[]s
Moreiras.
[1] {a,b,c,a.st1,b.st1,c.st1,d.st1,gps}.ntp.br
On 15/01/15 00h06m, Harlan Stenn wrote:
> I'm trying to figure out if anybody is actively using autokey, in a
> production deployment.
>
> If you are, please let me know - I have some questions for you.
>
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second
Hi. It seems that ftp://time.nist.gov/pub is not available anymore. Is there any other official place for the leapsecond files? []s amm Em 05-01-2012 15:24, Danny Mayer escreveu: > On 1/5/2012 11:38 AM, Rob van der Putten wrote: >> Hi there >> >> >> There's a leap second coming up; >> http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat > > This is the first time that I remember a leap second being added in the > middle of the year instead of the end of December. Am I wrong? > > Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] My extra second ...
The linux kernel bug aparently was found and fixed: related thread: http://lkml.org/lkml/2009/1/2/276 bug analysis: http://lkml.org/lkml/2009/1/2/373 fix: http://lkml.org/lkml/2009/1/2/415 Antonio M. Moreiras. Bill Unruh escreveu: > On Sat, 3 Jan 2009, Danny Mayer wrote: > >> Unruh wrote: >>> George R. Kasica writes: >>> >>>> On Fri, 02 Jan 2009 14:31:34 +0100, Rob van der Putten >>>> wrote: >>>>> Hi there >>>>> >>>>> >>>>> Steve Kostecke wrote: >>>>> >>>>>> All my Linux systems had a fine time. None of them locked up / crashed / >>>>>> rebooted / etc. >>>>>> >>>>>> The kernels involved included: >>>>>> >>>>>> 2.6.24-etchnhalf.1-amd64 >>>>>> 2.6.18-5-486 >>>>>> 2.6.16-2-486 >>>>>> 2.6.18-5-k7 >>>>>> 2.6.18-4-powerpc >>>>>> 2.4.16-k7 >>>>> What about the hardware (Intel /AMD)? >>>> Rob: >>>> Everything in my post above was Intel based, no AMD or otherwise. >>> Why in the world would you then have an amd64 kerenl and two k7 kernels, >>> and one powerpc kernel? None of those is intel. >>> >> He *never* said that. Those are Steve's systems. The post even includes >> that fact. > > Ooops. My mistake-- not reading th > properly > > >> Danny >> > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp survey
Hi, Danny. I can understand your point of view. Nevertheless, I don't have an usenet account and the process to send messages via "questions@lists.ntp.org" is moderated and is a bit slow and unpredictable. Sometimes it takes hours, sometimes it takes days to get the message to the group. I needed to be sure the message would arrive soon. Google gmail is very reliable and gives free access to the usenet. Actually, I do not see it as unacceptable, as it would be possible to verify the authenticity of the message by other means (consulting the IPs, for example, or asking). But, sure, I would feel much more comfortable if sending the message from nic.br. Anyway, thank you for your message and feedback. I will do everything possible to find a better solution for usenet access. If any doubt remained about the authenticity of the message, it was authentic. The survey was actually conducted by NIC.br. The current stage of data collection ended on 26/12. There was a preliminary gathering between 02 and 04 December, and the main collection was taken between 12 and 26 December. We had about 240 thousand responses in "ntpdate" and 170 thousand in "ntpq -c rl" and "ntpq -p". We actually visited 1,141,065 possible ntp servers of a total of 2,516,029 IPs found (on monlist). I'd like to take this opportunity to thank the collaboration of all. We are analyzing the data and will soon publish some results. Best regards, -- Antonio M. Moreiras. Brazilian Network Information Center - NIC.br moreiras at nic.br http://nic.br/english/index.htm http://ntp.br Danny Mayer escreveu: > Antonio, > > If you are really from nic.br please use your email address from that > domain. It is unacceptable to use a gmail account for such notifications. > > Danny > > Antonio M. Moreiras wrote: >> Aiming to collect and analyze data from NTP network, a survey will be >> held at all hosts available for public access on the NTP network, >> using a program developed for this purpose. The survey will start >> today and will last some days. >> >> We plan to make this a permanent study, repeating the survey >> periodically. >> >> The program run the following commands: >>> ntpq -n -c pe -c rl >>> ntpdate -q >>> ntpdc -n -c monlist >> Related work can be found at: >> >> http://www.ntpsurvey.arauc.br/ >> http://www.media.mit.edu/~nelson/research/ntp-survey99/ >> >> The addresses that will make the collection are the 200.160.1.102 (ntp- >> survey.ceptro.br) and 200.160.7.193 (monitor.ntp.br) belonging to >> NIC.br (Núcleo de Informação e Coordenação do Ponto br). Some inicial >> tests were already made from 200.160.1.77 (dubai.ceptro.br). >> >> If you notice any consultation on your NTP server, don´t be worried: >> the data is for statistical purposes only. As all hosts running NTP >> are potentially NTP servers, you can notice packets sent to the IPs of >> NTP clients also. This research doesn´t undermines your network >> security. The collection is unrelated to the purpose of exploiting any >> security breach of NTP servers. >> >> If you do not want your network to be searched, contact us by email >> ntp at nic.br, and let us know what IP or IP range should not be >> consulted. Fell free to contact us also for more information, >> criticisms, sugestions or comments. >> >> The findings will be made available on http://www.ntp.br. >> >> Best regards, >> -- >> Antonio M. Moreiras. >> Brazilian Network Information Center - NIC.br >> moreiras at nic.br >> http://nic.br/english/index.htm >> http://ntp.br > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
So, if I understand, I have to: 1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400 2 - rename the file to ntp.leapseconds and put it in /etc 3 - stop and start ntpd 4 - verify the warning bits It should be done at primary servers and the others would get automatically the file if using autokey. It could be done also at any stratum if one don't trust the references regarding this issue. Don't having the file, and if not using autokey and references with the information, the client will relay at information from the majority of survivor references. If they warn the leapsecond, the client will get it correctly. Is this correct? Thanks. Antonio M. Moreiras. David L. Mills escreveu: > Guys, > > See http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap for what > actually is in the implementation. (...) > As mentioned in the documentation, it is not necessary to run Autokey to > download the leapseconds file from NIST. It is availabe via FTP from the > pub directory and leap-seconds file. > > Dave > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] basic questions about the leapsecond
Hi... I'm a bit worried regarding the leapsecond, since I'm not finding much documentation about it... I have a simple (but unanswered) doubt: Do I have to manually configure something? Could you point some docs? We have the following structure repeated 3 times: +--- --+ 1 PPS ++ IRIG +---+ +---+ |Atomic Ref|-->|IRIG Gen|--->|NTP st1|-->|pub NTP st2| +--+ 10Mhz ++ + 1PPS +---+ +---+ ^^ || other st1other st2 - 1 st1 server is freebsd + ntpd + IRIG audio - 1 st1 server is symmetricom syncserver S250 - 1 st1 server is spectracom netclock 9283 At the IRIG generator we have to manually set the leapsecond bit. Could anyone tell me if these servers could read the leap bit correctly from IRIG signal? Specially IRIG audio? How could I test it at NTP? (Since I have made the adjust at IRIG gen how could I tell if ntp can read it correctly?) We have also 2 systems with GPS: +---+ NMEA +---+ |GPS|--->|NTP st1| +---+ + 1PPS +---+ One of them is a Trimble Acutime 2000, and the other is a Garmin 18LVC. Do I have to worry about these ntp servers? Thank you. Antonio M. Moreiras ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp survey
Hi, Maarten > Well, as per above, I'll be happy to punch a hole in the firewall for > you. It would be nice and we would like it. It also bring us a new problem... To recognize such hosts (normaly closed, but openned for the research) as one of the research goals is to map the ntp network. But we will handle this in time. > Will future scans be run from the same IP addresses? We will try to run future scans from the same IPs. If we have any problem with that, we certainly will announce the new ones... > Will they be > announced again? (Could you do so a few days _before_ it starts?) We can announce every new scan. And we can do it some days before it starts. > > Groetjes, > Maarten Wiltink []s Antonio M. Moreiras [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp survey
Maarten,
We run a program that is a adaptation from that used in the previous
studies. It starts from a list of known servers. Basically, for each
server, it will:
- try to get some information about the quality of the service (ntpdate,
ntpq -c rl, ntpq -p),
- try to get the IPs of its references (ntpq -p) and
- try to get the IPs of its clients (monlist).
It will assume that each new IP is a potential NTP server and will
consult it... It will repeat this process until it can not get new IPs.
Said that, we can eventually reach your gateway, sorry... We would like
to be able to get some information from it, but we know that
(generalizing) it will be impossible. We simply can't be sure that it
isn't a NTP server if we not try to consult it.
Antonio M. Moreiras.
[EMAIL PROTECTED]
Maarten Wiltink escreveu:
> "Antonio M. Moreiras" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>> Aiming to collect and analyze data from NTP network, a survey will be
>> held at all hosts available for public access on the NTP network,
>> using a program developed for this purpose. The survey will start
>> today and will last some days.
>
> My gateway runs NTP ('of course') but it's not available for public
> access. Would you, in general, want to include such hosts?
>
> Groetjes,
> Maarten Wiltink
>
>
> ___
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] ntp survey
Aiming to collect and analyze data from NTP network, a survey will be held at all hosts available for public access on the NTP network, using a program developed for this purpose. The survey will start today and will last some days. We plan to make this a permanent study, repeating the survey periodically. The program run the following commands: > ntpq -n -c pe -c rl > ntpdate -q > ntpdc -n -c monlist Related work can be found at: http://www.ntpsurvey.arauc.br/ http://www.media.mit.edu/~nelson/research/ntp-survey99/ The addresses that will make the collection are the 200.160.1.102 (ntp- survey.ceptro.br) and 200.160.7.193 (monitor.ntp.br) belonging to NIC.br (Núcleo de Informação e Coordenação do Ponto br). Some inicial tests were already made from 200.160.1.77 (dubai.ceptro.br). If you notice any consultation on your NTP server, don´t be worried: the data is for statistical purposes only. As all hosts running NTP are potentially NTP servers, you can notice packets sent to the IPs of NTP clients also. This research doesn´t undermines your network security. The collection is unrelated to the purpose of exploiting any security breach of NTP servers. If you do not want your network to be searched, contact us by email ntp at nic.br, and let us know what IP or IP range should not be consulted. Fell free to contact us also for more information, criticisms, sugestions or comments. The findings will be made available on http://www.ntp.br. Best regards, -- Antonio M. Moreiras. Brazilian Network Information Center - NIC.br moreiras at nic.br http://nic.br/english/index.htm http://ntp.br ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] ntp.br project - how to calculate the discrepancy?
David Woolley escreveu: >> A discrepancy of 16ms in a Internet NTP primary server is acceptable? > > It would exceed modern expectations, even if not necessary for most > applications. People expect this sort of accuracy on end nodes. I have understood that 16ms is unnaceptable and I will review the project. But I need help to know, at first, if I calculated this 16ms correctly. The rubidum clock manufacturer says that: mensal ageing < 5e-11 anual ageing < 5e-10 What would be the correct way to calculate the discrepancy in seconds after a given elapsed time? I calculated the error as 31,536,000,000 ms (1 year) * 5e-10 = 15.765ms, but I think this is not correct, because the 5e-10 is the frequency error after 1 year. This calculation would be correct if the 5e-10 were a constant frequency error along all the year, what is not the case. Calculating in a mensal basis (but considering 5e-11 as a constant freq error within the month, what is wrong too but with a smaller overestimated error): Month Accum AgeingErr(ms) Tot Error(ms) 1 0,005 0,130 0,130 2 0,010 0,259 0,389 3 0,015 0,389 0,778 4 0,020 0,518 1,296 5 0,025 0,648 1,944 6 0,030 0,778 2,722 7 0,035 0,907 3,629 8 0,040 1,037 4,666 9 0,045 1,166 5,832 10 0,050 1,296 7,128 11 0,055 1,426 8,554 12 0,060 1,555 10,109 If this is correct, it means that whith 3 calibrations per year, it would be possible to keep the discrepancy < 1ms. And if we calibrate the system in a monthly basis, the discrepancy would be less than 150us. We are studying, as suggested by some people, using GPS as time reference, but one of primary requisites to our project is to have the servers in sync with the official brazilian time, that is UTC(ONRJ). Considering that we could completely trust the GPS system (can we? it is a us military system...) there would be no practical differences, but yet there would be some legal differences. So we are looking for alternatives to synchronize to UTC(ONRJ) with an acceptable accuracy. The studied alternatives include using cesium reference clocks, instead of rubidium, or calibrate the rubidium ones within shorter periods of time. >> what is the discrepancy of GPS time from UTC (without >> considering the leap seconds)? > > 50 nano seconds at about the 50 percentile, is the official specification. > The constellation needs to be in synch with each other to rather better > than this for GPS to work at all, although it is not strictly necessary > that they match UTC. Even if they don't match UTC exactly, the offset > will be available. > > I seem to remember that typical NTP servers can lock to this to > microsecond accuracies, although typical network delays will degrade > this to around 1 ms. Thanks. []s Antonio M. Moreiras Posted Via Usenet.com Premium Usenet Newsgroup Services -- ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY ** -- http://www.usenet.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] project ntp.br
François Meyer escreveu: > For real time purposes (as NTP), formally this is > UTC(ONRJ), TA(ONSP) and TA(ONBR) (just formal, no > practical consequences if only NTP is concerned). Could you indicate some sources (books, websites) where I could learn more about that? We are writing some documentation in portuguese and I would like to get all the formalities correctly handled. > > I cant see why you need a Rb clock here if UTC(ONRJ) > (or a slightly degraded version in the case of the > secondary observatories) is available locally. > There are issues regarding the ONRJ Internet connections. Because of this, the primary and secondary ntp servers are in other site (althought it is also in Rio de Janeiro). > No remark on the structure below stratum 1, but from > a metrological point of view, in my opinion, the > complete structure could read like this : > > UTC > | > |Circular T BIPM > | > | > UTC(ONRJ) ---> NTP st 1, id 0 ---> down to lower strata > | | > | peer > | | > |__TA(ONSP) ---> NTP st 1, id 1---> down to lower strata > | GPS link | > | peer > | | > |__TA(ONBR) ---> NTP st 1, id 2 ---> down to lower strata >GPS link > Thanks for the suggestion! We are studying alternatives, including this one, as we see that our proposed structure have big problems. []s Antonio M. Moreiras. Posted Via Usenet.com Premium Usenet Newsgroup Services -- ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY ** -- http://www.usenet.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] project ntp.br - questions
Thank you Harlan. I don´t have previous experience with ntp, than since I was assigned to this project, a month ago, I´ve spent a lot of time reading the documentation from ntp.org, from David Mills website, some RFCs, papers, dissertations, etc. Even so, I have a lot of questions yet! This project is very important for us, because there is few public servers in Brazil, and fewer primary servers. Also the majority of the primary servers rely only on one source, the GPS system. Then, more than answers, we are seeking also for advises and considerations of how we can provide this service with high quality. []s Antonio M. Moreiras Harlan Stenn escreveu: > Antonio, > > You ask many good questions. > > Perhaps sadly, I do not have time right now to answer them. > > I will say that the answers to your questions either are or should be > answered on http://support.ntp.org . > > H > From - Thu Posted Via Usenet.com Premium Usenet Newsgroup Services -- ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY ** -- http://www.usenet.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] project ntp.br - discrepancy from UTC
The Cesium clock at observatorio nacional (ON) is UTC. In fact, the ON is one of the metrology laboratories that colaborates with the Bureau International des Poids et Measures (BIPM) in generating the UTC (as NIST does in USA, for example). The Rubidium clocks are synchronized with the UTC at least one time per year and the manufacturer says that the Rubidum reference has a monthly aging less than 5e-11 and a yearly aging less than 5e-10. It gives us a 16ms maximum discrepancy from UTC (31,536,000,000 ms/year * 5e-10 * 1 year = 15.765ms - is this correct?) After one year, with the discrepancy at 16ms it will be probabily of the same order than the half round trip time for the majority of the clients. Given this, do you you think it will be necessary any modification? If so, what would be the maximum discrepancy allowed to not need any modifications? As the primary servers are appliances from Symmetrycom or Spectracom probabily it will be very difficult to get customized firmware versions... Maybe we should study the possibility of synchronize the Rubidium reference clocks more frequently with UTC. I don´t know if I correctly understood what this discrepancy can cause. If a client is using other sources attached directly to GPSs, for example, there is a risk that our servers being considered falsetickers. Is it? Or is there other problems? A discrepancy of 16ms in a Internet NTP primary server is acceptable? In Brazil time stamps should be less than 100ms accurate to be legaly valid (for financial or government institutions, for example). I think it is the same in other parts of the world. Then, 16ms appears to reasonable for an Internet service. The majority of the Internet NTP primary servers are GPS based. For curiosity: what is the discrepancy of GPS time from UTC (without considering the leap seconds)? []s Antonio M. Moreiras. David Woolley escreveu: > In article <[EMAIL PROTECTED]>, > Antonio M. Moreiras <[EMAIL PROTECTED]> wrote: > >> |(periodically assures the >> | accuracy with the official >> | brazilian time - that is >> | in last instance UTC) >> # >>** Rubidium clock ** > > How far is this allowed to get from UTC? If the maximum discrepancy isn't > very small compared with the combination of "precision" and half minimum > round trip time to a client, and given this is a high profile server, you > should modify the source code to add the maximum error into the root > dispersion calculation. > > If you don't do this, someone using your source and something more > directly tied to UTC may find that the error bounds don't overlap, and > one gets thrown out. Posted Via Usenet.com Premium Usenet Newsgroup Services -- ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY ** -- http://www.usenet.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] project ntp.br
Dear Sirs: NIC.br is working on the project ntp.br, that has the goal of improving the quality of time synchronization in (brazilian) Internet hosts and networks and of provide legal brazilian time. Basically we intend to provide stratum 1 and stratum 2 servers, synchronized with legal brazilian time (that is kept by the observatorio nacional - www.on.br - and is, in last instance, UTC). We will have 3 of the following structure (at 3 different sites, at 3 different cities: Sao Paulo, Rio de Janeiro, Brasilia): --- Observatorio Nacional (Cesium clock) | |(periodically assures the | accuracy with the official | brazilian time - that is | in last instance UTC) # ** Rubidium clock ** ** Stratum 0 ** Symmetrycom | |(IRIG) # ** Stratum 1 Server ** Appliance Spectracom -- or Appliance Symmetrycom| | |(Internet) |(Internet or LAN) | # # ** Stratum 2 Server **(stratum 2 "clients") cluster with 2 Dell blade servers (autonomous systems) | (big networks) |(Internet) # (stratum 3 "clients") (home users, small and medium networks) --- The Rubidium clocks and stratum 1 servers will be completely independent of each others, but each of the six stratum 2 servers will be synchronized by the three stratum 1 servers. The project will start with 2 complete sites (Sao Paulo, Rio de Janeiro). The third site (Brasilia) will have only the stratum 2 servers, and in the next year the Rubidium clock and the stratum 1 server will be added. The stratum 2 servers will be open to the Internet, intended to be used by home users, small and medium networks, to synchronize clients or stratum 3 servers.. The stratum 1 servers will have their access restricted, intended to be used only by the Autonomous Systems and big networks to syncronize their own stratum 2 servers. We estimate about 600 clients for each stratum 1 server. We need some help and advise in the following questions: 1 - Is that a good structure or it needs to be improved or corrected? 2 - The Stratum 1 Servers are appliances and do have some limitations at access control configuration. How can we provide access limitation by other means? We are studying the following possibilities: (a) A firewall between the Internet and the Stratum 1 servers, with a per client IP configuration. (b) A vpn (openvpn). What would be better? Is there any other alternative? 3 - About cryptography: - We don´t fully understand the options and implications yet. - It seems to complicate a little the client side configuration. We fear that it will desincourage the potencial users. - It seems that the majority of the servers at public pool don´t uses it. Then: (a) What are the real risks of not implementing the cryptography? (b) What is more recommended: Autokey, or symmetrical keys? Why? (c) Is it possible to implement cryptography as an optional feature: the server configuration accepts clients with and without cryptography? 4 - We are experiencing some degree of difficulty to fully understand Autokey. Is there any documentation with a working configuration example? 5 - At the stratum 2 servers, what is the more advisable OS? FreeBSD? OpenBSD? Linux? Windows? We have read something about freebsd being the best choice, but without an explanation. 6 - Regarding monitoring, we intend to use basically adapted versions of the scripts found at http://www.schlitt.net/scripts/ntp/ and at http://saturn.dennishilberg.com/gathering_data.php. But we would also like to have some statistics about quality of the clients synchronization, specially of the stratum 2 servers at the autonomous systems. Maybe get a "ntpq -c pe" for each one from time to time. Any advise regarding this? Sorry for the long post, and thanks in advance. -- Antonio M. Moreiras Project Engineer at Brazilian Network Information Center - NIC.br [EMAIL PROTECTED] http://www.nic.br Posted Via Usenet.com Premium Usenet Newsgroup Services -- ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY ** -- http://www.usenet.com ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
