[ntp:questions] Are mode 6 responses rate controlled?
We are getting customer inquiries about Mode 6 packets and DDOS packet amplification issues. It seems that security audit vendors have started checking to see if NTP is allowing mode 6 packets. I am getting some pressure to disable them by default. I notice that some vendors have indeed done that, but others rate limit mode 6 packets to prevent them from being useful in a DDOS. Does the stock NTP distro have such rate limiting already built in? If not, is there anything to mitigate the problem by default? -- -- I haven't lost my mind, it is backed up in the cloud somewhere. Oracle <http://www.oracle.com> Brian Utterback, Principal Software Engineer Phone: +16038973049 , Mobile: +16035577683 https://oracle.zoom.us/s/2728168892 <https://oracle.zoom.us/s/2728168892> One Oracle Drive, Nashua, NH 03062 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [External] : Best method to measure NTP performance/drift. Loopstats or Peerstats
> which is the difference between loopstats and peerstats for evaluating the > drift respect a given timing source? The peerstats file is written each time a new packet is received. Be careful, it represents the what NTP has calculated the information to be using the data from the eight most recent samples, not necessarily the latest one. If you want the actual data from each packet you need to use the "rawstats" file, which records the actual timestamps from each packet. The loopstats file is written every time the kernel clock loop is updated, which generally is when a packet is received, but not always. It represents the data that NTP has calculated using the current set of data it has at that moment after updating all the data with the new packet. > > In my configuration, the NTP server is configured with just one additional > source (GPS) always available. > Should this stats file report the same data? I am not exactly sure what you mean by "the same data". > > How can I increase the frequency of the log lines in the stats? Is there a way > to have one line per second or should I "interrogate" the ntp daemon with > ntpq, ntpdc commands? If there hasn't been a triggering event like a new packet arriving, then the data hasn't changed so there is not much point in writing more data log lines. You could certainly use ntpq (ntpdc is deprecated) but the data would be the same each time until something changed. > > Thank you so much for the support. Of course. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Does "writevar" work?
I have a customer running 4.2.8p11 who is doing some leap second testing. They gave me the procedure they followed, which was essentially to set the leap second flag on the up stream server and observe if the leap second flag on the client eventually set and if the kernel processed the leap second correctly. They observed some failures by the client to detect the flag. I am attempting to recreate their test. The procedure they gave me to set the leap flag is to use the command "writevar 0 leap=01" in ntpq, with proper keys of course. My problem is that when I run this command it always returns "***Server returned an unspecified error" When I looked at the code for "write_variables" in ntp_control.c, I don't see how the writevar could ever work. There are two lists of variables, a static one in the array sys_var and a user defined one in the array ext_sys_var. When the name of the variable is processed it looks first in sys_var, and if it is not found it then looks in ext_sys_var. But the subsequent processing only sets the variable if it is in ext_sys_var. The variable "leap" is in sys_var, so it looks to me as if there is no way to set the leap flag to add a second. Yet my customer says they just did it. What am I doing wrong? I know I can do this with a fiddled leap seconds file, but that is much less convenient than just running a command. If anyone has any hints on working with the leap seconds file, I would appreciate that, since it looks like I will have to bite the bullet and do that unless someone here can point me to the error of my ways. Thanks. -- All working systems eventually start to exhibit their own agenda. Oracle <http://www.oracle.com> Brian Utterback | Principal Software Engineer Phone: +16038973049 https://oracle.zoom.us/s/2728168892 https://myoracle.webex.com/join/brian.utterback Oracle Systems/Solaris Networking 1 Oracle Dr. | Nashua, NH 03062 I have not lost my mind. It's backed up in the cloud somewhere. Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Many new messages in test results.
f=0.03usec m_expr which is -1.50 and n_expr which is -1.54 are not close; diff=0.04usec m_expr which is -1.99 and n_expr which is -1.95 are not close; diff=0.04usec m_expr which is -1.99 and n_expr which is -1.96 are not close; diff=0.03usec m_expr which is -1.99 and n_expr which is -1.102 are not close; diff=0.03usec m_expr which is -1.99 and n_expr which is -1.103 are not close; diff=0.04usec m_expr which is 0.01 and n_expr which is 0.18446744073709551613 are not close; diff=0.04usec m_expr which is 0.01 and n_expr which is 0.18446744073709551614 are not close; diff=0.03usec m_expr which is 0.01 and n_expr which is 0.04 are not close; diff=0.03usec m_expr which is 0.01 and n_expr which is 0.05 are not close; diff=0.04usec m_expr which is 0.50 and n_expr which is 0.46 are not close; diff=0.04usec m_expr which is 0.50 and n_expr which is 0.47 are not close; diff=0.03usec m_expr which is 0.50 and n_expr which is 0.53 are not close; diff=0.03usec m_expr which is 0.50 and n_expr which is 0.54 are not close; diff=0.04usec m_expr which is 0.99 and n_expr which is 0.95 are not close; diff=0.04usec m_expr which is 0.99 and n_expr which is 0.96 are not close; diff=0.03usec m_expr which is 0.99 and n_expr which is 0.102 are not close; diff=0.03usec m_expr which is 0.99 and n_expr which is 0.103 are not close; diff=0.04usec m_expr which is 1.01 and n_expr which is 1.18446744073709551613 are not close; diff=0.04usec m_expr which is 1.01 and n_expr which is 1.18446744073709551614 are not close; diff=0.03usec m_expr which is 1.01 and n_expr which is 1.04 are not close; diff=0.03usec m_expr which is 1.01 and n_expr which is 1.05 are not close; diff=0.04usec m_expr which is 1.50 and n_expr which is 1.46 are not close; diff=0.04usec m_expr which is 1.50 and n_expr which is 1.47 are not close; diff=0.03usec m_expr which is 1.50 and n_expr which is 1.53 are not close; diff=0.03usec m_expr which is 1.50 and n_expr which is 1.54 are not close; diff=0.04usec m_expr which is 1.99 and n_expr which is 1.95 are not close; diff=0.04usec m_expr which is 1.99 and n_expr which is 1.96 are not close; diff=0.03usec m_expr which is 1.99 and n_expr which is 1.102 are not close; diff=0.03usec m_expr which is 1.99 and n_expr which is 1.103 are not close; diff=0.04usec m_expr which is 2.01 and n_expr which is 2.18446744073709551613 are not close; diff=0.04usec m_expr which is 2.01 and n_expr which is 2.18446744073709551614 are not close; diff=0.03usec m_expr which is 2.01 and n_expr which is 2.04 are not close; diff=0.03usec m_expr which is 2.01 and n_expr which is 2.05 are not close; diff=0.04usec m_expr which is 2.50 and n_expr which is 2.46 are not close; diff=0.04usec m_expr which is 2.50 and n_expr which is 2.47 are not close; diff=0.03usec m_expr which is 2.50 and n_expr which is 2.53 are not close; diff=0.03usec m_expr which is 2.50 and n_expr which is 2.54 are not close; diff=0.04usec m_expr which is 2.99 and n_expr which is 2.95 are not close; diff=0.04usec m_expr which is 2.99 and n_expr which is 2.96 are not close; diff=0.03usec m_expr which is 2.99 and n_expr which is 2.102 are not close; diff=0.03usec m_expr which is 2.99 and n_expr which is 2.103 are not close; diff=0.04usec Are these something I need to worry about? -- Oracle <http://www.oracle.com> Brian Utterback | Principal Software Engineer Phone: +1 6038973049 Oracle Systems Server & Cloud Engineering 1 Oracle Dr. | Nashua, NH 03062 All working systems eventually start to exhibit their own agenda Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] More than one PPS source on Raspberry Pi?
Doesn't adding a second PPS signal mean that the accuracy can only go down? If the two PPS signals are really in sync then they will be clocking essentially simultaneously. They won't get serviced simultaneously so one will either be ignored or will be serviced after a delay. On 12/4/2017 12:02 PM, Paul J R wrote: The answer is no and yes (and also maybe).. no because the current pps-gpio driver only loads a single pin (though it could be extended to load more than one, but i dont think anyones done that). yes because the other way it could be achieved is to create a second module called pps-gpio2 and then init that with a different pin config, and that wouldn't be overly hard and possibly easier than trying to extend the existing driver (depending on knowledge of kernel drivers). Lastly, maybe because im unaware of what hardware limits the rpi might have which might get in the way of doing something like that (from what i've read, every pin is capable of being configured for interrupts, so it sounds like it should be possible) On 05/12/17 03:35, Frank Wayne wrote: Has anyone tried to use more than one PPS source at the same time on a Raspberry Pi? The device tree overlay pps-gpio does not seem to support more than one instance. That is, if my config.txt specifies two instances of pps-gpio for different GPIO pins, only /dev/pps0 is created. The documentation for pps_gpio is limited or missing, and the Raspberry Pi forum and the LinuxPPS list have not helped. If pps-gpio cannot do it, is there another way to get PPS devices for Raspbian or another OS that will run on a Pi? Frank Wayne ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- Oracle <http://www.oracle.com> Brian Utterback | Principal Software Engineer Phone: +1 6038973049 <tel:+1%206038973049> Oracle Systems Server & Cloud Engineering 1 Oracle Dr. | Nashua, NH 03062 All working systems eventually show their own agendas. Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Which time source is ntp using
Strictly speaking, it is using both. A PPS signal can only be used on a system clock that is within half a second of the correct time. In essence the part of the timestamp that is of a precision of one second and up is coming from the 176.9.72.17 system, while the part of the timestamp that is in fractions of a second is coming from the PPS. Hope that helps. On 7/11/2017 10:53 PM, Chip wrote: All, I have set up a raspberry pi as a NTP server. The Pi is performing flawlessly. when I run the ntp -pn, I get the following output remote refid st t when poll reach delay offset jitter == 127.127.1.0 .LOCL. 10 l 27h 640 0.000 0.000 0.000 o127.127.20.0.GPS.0 l 58 64 377 0.000 0.007 0.004 *176.9.72.17 192.53.103.104 2 u 44 64 377 136.644 1.221 0.720 +46.254.216.989.109.251.212 u 58 64 337 177.067 0.041 2.734 -69.10.161.7 144.111.222.81 3 u 36 64 377 69.135 15.589 0.680 +96.244.96.19192.168.10.254 2 u 46 64 377 58.373 0.809 13.308 Is the pi using the GPS pps signal as the reference clock or the clock at 176.9.72.17 which has the * infront of it? Thanks ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- Oracle <http://www.oracle.com> Brian Utterback | Principal Software Engineer Phone: +1 6038973049 <tel:+1%206038973049> Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 All working systems eventually show their own agendas. Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] what is refid in ntpq -pn [sorta OT: field sizes]
On 5/7/2017 7:22 PM, Richard Thomas wrote: > While we’re on the topic of the ’ntpq -p’ display, the days of 80x24 screens > are long since gone. How much work would it be to increase the size of the > first column of the output so that it had enough space for a full IPv6 > address? The width of the field is not the problem. The refid is a field in the packet and is only 32 bits. -- Oracle <http://www.oracle.com> Brian Utterback | Principal Software Engineer Phone: +1 6038973049 <tel:+1%206038973049> Oracle Systems, SPARC & Solaris System Software Engineering 1 Oracle Dr. | Nashua, NH 03062 All working systems eventually start to exhibit their own agenda Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP 128ms
The maximum adjustment allowed by default is 17 minutes. If you control enough of the system's upstream servers you can set the clock to anything you want eventually. The only question is how fast you can do it. On 10/6/2016 2:16 PM, Brian Inglis wrote: > On 2016-10-06 06:49, MORRIS, Joe J wrote: >> Probably a simple answer, but I don't seem to be able to find it. I >> understand that any difference between the time source and expected >> time on the client below 128ms will result in the local time being >> changed to reflect the new time. What safeguards are there in place >> to stop the time source (either through fault or malicious attack) >> changing the time by say 100ms every time its polled? Assuming a poll >> every minute, over 10 minutes, the time could be changed by a >> second. > > With an offset below the step threshold (default 128ms), system time > will be slewed to discipline it towards UTC; above the step threshold, > system time will be stepped to set it to UTC: this is normally done only > once at startup; if any offset exceeds the panic threshold (default > 1000s), ntpd will exit: this may be bypassed once only at startup with > option -g (panicgate); see: > https://www.eecis.udel.edu/~mills/ntp/html/discipline.html > https://www.eecis.udel.edu/~mills/ntp/html/clock.html > > Much of the ntpd code is sanity checking to ensure that bad data is > ignored, and only truechimers are selected to estimate UTC; see: > https://www.eecis.udel.edu/~mills/ntp/html/warp.html > https://www.eecis.udel.edu/~mills/ntp/html/poll.html > https://www.eecis.udel.edu/~mills/ntp/html/filter.html > https://www.eecis.udel.edu/~mills/ntp/html/select.html > https://www.eecis.udel.edu/~mills/ntp/html/cluster.html > https://www.eecis.udel.edu/~mills/ntp/html/prefer.html > > If the number of sources deemed truechimers are not greater than the > number of sources deemed falsetickers, no majority clique exists, and > the system time adjustment is not changed: see select above Figure 2. > > Many default operating parameters may be changed by the configuration > tos statement; see: > https://www.eecis.udel.edu/~mills/ntp/html/miscopt.html#tos > N.B. RTFM: "HERE BE DRAGONS!" > > For greatest accuracy and consistency, a timing quality GPS with PPS > can be connected to a low latency serial port or other IO connector > on a system running with kernel PPS and NTP API support (most Unix). > With a good sky view this keeps time within us of UTC; use a good > GPSDO (with OCXO) supporting NTP and you can stay within ns of UTC. > -- Oracle <http://www.oracle.com> Brian Utterback | Principal Software Engineer Phone: +1 6038973049 <tel:+1%206038973049> Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 All working systems eventually start to exhibit their own agenda Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How to specify interface for multicastclient
On 1/13/2016 11:03 PM, Danny Mayer wrote: On 1/13/2016 4:30 PM, brian utterback wrote: I am sure this has been asked before but I can't find the answer. On a multihomed system, is there anyway to specify which interfaces you want multicastclient to listen on? If so, how. If not, why not? I would have expected it to listen on all interfaces, but it doesn't do that. Unfortunately no. The server tries to figure out which interface to use and sometimes it's wrong. I've had development code to allow admins to specify in the config file where to listen but that's not in the current code and I'd need to rework it to get it in there. I'm not sure you can bind more than one interface to a multicast address as you are asking as I don't think that the O/S would allow it. Does Solaris all something like that? Danny No, you would have to have a socket for each interface. I would have to look, but I think that a socket can join a multicast group without affecting its non-multicast traffic, i.e., it might just be a matter of joining the multicast group on every interface socket that we already bind. Maybe not, it is too early in the morning for me to be sure, the caffeine hasn't kicked in yet. -- Oracle <http://www.oracle.com> Brian Utterback | Principal Software Engineer Phone: +1 6038973049 <tel:+1%206038973049> Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 All working systems eventually show their own agendas. Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] How to specify interface for multicastclient
I am sure this has been asked before but I can't find the answer. On a multihomed system, is there anyway to specify which interfaces you want multicastclient to listen on? If so, how. If not, why not? I would have expected it to listen on all interfaces, but it doesn't do that. -- Oracle <http://www.oracle.com> Brian Utterback | Principle Software Engineer Phone: +1 6038973049 <tel:+1%206038973049> Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 All working systems eventually start to exhibit their own agenda Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Observation with ntp4.2.8@p4-request inputs
On 12/14/2015 12:15 PM, Sowmya Manapragada wrote: > Log the exact timestamp of when client sync with the server ( banking > on the rv 0 status word) That is not a well defined event. You can't log an exact timestamp for an inexact event. If you want to log an event you need to define what that event is. -- Oracle <http://www.oracle.com> Brian Utterback | Principle Software Engineer Phone: +1 6038973049 <tel:+1%206038973049> Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 All working systems eventually start to exhibit their own agenda Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Observation with ntp4.2.8@p4-request inputs
Perhaps it would be best if you told us what you are trying to do, what exactly is the event you are trying to trap? On 12/12/2015 2:26 AM, Sowmya Manapragada wrote: > Thanks all for your comments, but if that's expected , I need to depend on > something other than the system / peer status words for trapping the > correct sequence of events? > what I mean is even when my server is not reachable and system status word > rv 0 = 0615 ..it means to the client (0 leap_none, 6- sync_ntp,1 event, > 5-clock_sync).. and only after 7 to 8 minutes rv 0 status changes and > gives the correct status that the "server peer" is unreachable, same with > the client associations status: only after 6 to 8 minutes client shows it > has lost the server peer ( not reachable) ..am I missing something here ? > > thanks, > Shyam > On Sat, Dec 12, 2015 at 12:52 PM, Sowmya Manapragada <skoga...@gmail.com> > wrote: > >> Thanks all for your comments, but if that's expected , I need to depend on >> something other than the system / peer status words for trapping the >> correct sequence of events? >> what I mean is even when my server is not reachable and system status word >> rv 0 = 0615 ..it means to the client (0 leap_none, 6- sync_ntp,1 event, >> 5-clock_sync).. and only after 7 to 8 minutes rv 0 status changes and >> gives the correct status that the "server peer" is unreachable, same with >> the client associations status: only after 6 to 8 minutes client shows it >> has lost the server peer ( not reachable) ..am I missing something here ? >> >> thanks, >> Shyam >> >> On Fri, Dec 11, 2015 at 5:30 PM, <questions-requ...@lists.ntp.org> wrote: >> >>> Send questions mailing list submissions to >>> questions@lists.ntp.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://lists.ntp.org/listinfo/questions >>> or, via email, send a message with subject or body 'help' to >>> questions-requ...@lists.ntp.org >>> >>> You can reach the person managing the list at >>> questions-ow...@lists.ntp.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of questions digest..." >>> >>> >>> Today's Topics: >>> >>>1. Re: Observation with ntp4.2.8@p4-request inputs (brian utterback) >>> >>> >>> -- >>> >>> Message: 1 >>> Date: Thu, 10 Dec 2015 08:01:14 -0500 >>> From: brian utterback <brian.utterb...@oracle.com> >>> To: elliott...@comcast.net, "'Sowmya Manapragada'" >>> <skoga...@gmail.com>, questions@lists.ntp.org >>> Subject: Re: [ntp:questions] Observation with ntp4.2.8@p4-request >>> inputs >>> Message-ID: <5669779a.7040...@oracle.com> >>> Content-Type: text/plain; charset=windows-1252 >>> >>> Yes, that is the expected behavior. >>> >>> On 12/10/2015 6:55 AM, Charles Elliott wrote: >>>> FWIIW, I have seen a similar phenomenon, only with one server. If the >>> time >>>> server on my network stops dispensing time for some reason, the >>> computers on >>>> the LAN will still stay sync'ed to its last observation long after the >>> reach >>>> indicator goes to zero. Not sure if that is right. >>>> >>>> Charles Elliott >>>> >>>> -Original Message- >>>> From: questions >>>> [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On >>> Behalf Of >>>> Sowmya Manapragada >>>> Sent: Wednesday, December 9, 2015 10:26 PM >>>> To: questions@lists.ntp.org >>>> Subject: [ntp:questions] Observation with ntp4.2.8@p4-request inputs >>>> >>>> Hello All, >>>> Just wanted to check if what I am observing with4.2.8p4 is as expected >>> or I >>>> missed out something because I don't see this with older 4.2.8p2/p3 :I >>> have >>>> a client having 2 NTP servers (both servers in my LAN ), client makes >>> one as >>>> a peer ( to which it is currently synced) and other as a candidate; the >>> peer >>>> (server) goes down, my client at least waited 7 to 8 min to reject this >>> peer >>>> server and choose the available one... Checked in Mein berg monitor tool &
Re: [ntp:questions] Observation with ntp4.2.8@p4-request inputs
Yes, that is the expected behavior. On 12/10/2015 6:55 AM, Charles Elliott wrote: > FWIIW, I have seen a similar phenomenon, only with one server. If the time > server on my network stops dispensing time for some reason, the computers on > the LAN will still stay sync'ed to its last observation long after the reach > indicator goes to zero. Not sure if that is right. > > Charles Elliott > > -Original Message- > From: questions > [mailto:questions-bounces+elliott.ch=comcast@lists.ntp.org] On Behalf Of > Sowmya Manapragada > Sent: Wednesday, December 9, 2015 10:26 PM > To: questions@lists.ntp.org > Subject: [ntp:questions] Observation with ntp4.2.8@p4-request inputs > > Hello All, > Just wanted to check if what I am observing with4.2.8p4 is as expected or I > missed out something because I don't see this with older 4.2.8p2/p3 :I have > a client having 2 NTP servers (both servers in my LAN ), client makes one as > a peer ( to which it is currently synced) and other as a candidate; the peer > (server) goes down, my client at least waited 7 to 8 min to reject this peer > server and choose the available one... Checked in Mein berg monitor tool > also and rv0 command ... The status word just don't show that client > rejected server until 7 to 8 minutes... Wire shark correctly shows no > packets exchanged between my clint and peer ( right from moment when server > which is down)..my client ntp.conf is standard with an iburst... > Thanks in advance > Shyam > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions -- Oracle <http://www.oracle.com> Brian Utterback | Principle Software Engineer Phone: +1 6038973049 <tel:+1%206038973049> Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 All working systems eventually start to exhibit their own agenda Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp4.2.8p3 on Solaris11.2 (Sun Netra-T4)
I would suggest running ntpd again using truss: truss -faled -o /tmp/ntp.truss -vioctl /usr/local/libexec/ntpd -D 8 Once you have the truss file, you could post it here or send it to me or post what you think are the relevant sections, whichever you are comfortable with. On 7/13/2015 4:15 AM, AOKI Tetsuo wrote: Hi lists, I'm running ntp4.2.8p3 on Solaris11.2 (Netra-T4). Now, I'm trying to enable ATOM module (PPS) I complied sh configure --enable-ATOM --enable-LOCAL-CLOCK --disable-ipv6 --with-ntpsnmpd=no and installed successfully. Because Netra-T4 lacks serial interface, I bought a perl serial card which support Solaris11 https://www.perle.com/products/ultraport-serial-card.shtml It seems to be working, but when I tried to enable ATOM module by adding server 127.127.22.0 to /etc/ntp.conf there appeared an error message 13 Jul 16:55:10 ntpd[11162]: refclock_ppsapi: time_pps_create: Bad file number And this is the part of debug messages with /usr/local/libexec/ntpd -D 8 refclock_ioctl: TIOCSPPS failed:: Invalid argument 13 Jul 17:05:56 ntpd[27590]: refclock_ppsapi: time_pps_create: Invalid argument What should I check to enable ATOM module? Any help would be greatly appreciated. Regards, T. Aoki ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- Oracle http://www.oracle.com Brian Utterback | Principal Software Engineer Phone: +1 6038973049 tel:+1%206038973049 Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 All working systems eventually start to exhibit their own agenda. Green Oracle http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] reachability register
On 4/8/2015 9:23 AM, MAYER Hans wrote: Dear all, I have a question about the reachability register. For my opinion this is a left shift 8-bit register. I looked in one of our internal ntp-server with ntpq and found a value of 376 to a peer configured internal server. After waiting the time difference between poll and when I can find the value of 377. How is it possible ? For my understanding this could only happen after 8 times the poll interval. The next value should be 375 and after that 373. And so on shifting the 0-bit to the left. You are mostly correct. You are missing only one small detail. The register gets shifted when NTP sends a packet and ORs in a one when it receives a packet. Thus, if the low order bit were zero because a packet got dropped, then your reasoning would be correct. However, if the low order bit were zero because you happened to look between the time a request was sent and a reply was received then what you observed is correct. -- Oracle http://www.oracle.com Brian Utterback | Principal Software Engineer Phone: +1 6038973049 tel:+1%206038973049 Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 This space for sale or rent Green Oracle http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Proposal: Change the default memlock rlimit to 0
Just to complicate things, does it really make sense to memlock on a system with receive timestamps and no refclocks? -- Oracle http://www.oracle.com Brian Utterback | Principal Software Engineer Phone: +1 6038973049 tel:+1%206038973049 Oracle Systems/RPE Solaris Network 1 Oracle Dr. | Nashua, NH 03062 This space for sale or rent http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Writing the drift file
On 3/6/2015 4:35 AM, Harlan Stenn wrote: 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. I am not sure I understand. Do you mean if the delta us more than the threshold, or the actual current value? In any case, I would always write the current value on an orderly shutdown. -- Brian Utterback Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP offset doesn't change.
On 2/11/2015 2:12 AM, Harlan Stenn wrote: William Unruh writes: On 2015-02-10, Terje Mathisen terje.mathi...@tmsw.no wrote: William Unruh wrote: No. It only does that for offsets from Hades. The Ones from Hell, ntpd abandons all hope and quits. ( Hades is 128ms to 1000 sec, Hell is 1000 sec) Ie, for 128ms, ntp will try to slew the clock ( at a max of 500PPM- as far as I can see a completely arbitrary limit Mills decided on decades 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. My own control theory math was back around 1980, so I have forgotten most of it. :-( As you state, it is arbitrary. Is not! Is so! ... If it can be changed from 100 to 500 after complaints, it indicates that the number was not picked to optimise anything. I'm not sure that logically follows... Well, it indicates that it can be changed, not how easy it is nor what it entails nor the consequences. As I recall, the choice of PPM limit directly affects the maximum error budget. In Mills book he explains that the control loop is carefully crafted to simplify the calculations and to be provably correct and stable. With today's systems I am not sure simplifying implementation at the expense of clarity is necessary and provably correct is a goal that most of us worry about. Dr. Mills crafted a wonderful piece of software, amazing for its time, but he no longer actively engages us much at all. I understand, that isn't his fault. But no one who does actively engage really understands it or knows how to improve it. Unruh has a point, we don't know if there isn't a better way built on statistical analysis. Perhaps a hybrid between the two approaches would be better still. But we don't even know the consequences of changing a single constant with any degree of certainty. -- Brian Utterback Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/12/2015 6:29 AM, Mike Cook wrote: Not true. That would violate POSIX. There is no properly implements, or right thing. Perhaps you're unaware that POSIX isn't the One True Operating System specification. Properly implements means it follows the well defined, 40 year old normative specification for handling leap seconds, which requires supporting minutes with 59 or 61 seconds. That's something POSIX doesn't properly implement. Agreed. It is often overlooked that leap seconds were implemented from 1972 and POSIX only saw the light of day in 1988. So POSIX is just plain wrong here IMHO. Of course I am aware that POSIX isn't the one true operating system specification. But it certainly is a specification. And for a very large number of people in the world, POSIX conformity is more important than the UTC specification. I agree that POSIX was wrong, but it is what it is. What is the right thing to do if you have two conflicting standards? Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/11/2015 9:44 PM, Mike S wrote: On 1/11/2015 7:16 PM, William Unruh wrote: If that public source is responsible it will pass on to your system the fact that there is a leapsecond, and your system will stop for a second at the last second of June. A system which properly implements leap seconds will do no such thing. It will properly account for a minute with 61 seconds, and will tick from 23:59:59 to 23:59:60 then to 00:00:00. There is no stopping, or any other discontinuity. Not true. That would violate POSIX. There is no properly implements, or right thing. There is only best of a bad lot, and depends on your goals. There is no solution that meets all possible goals in this regard. -- Brian Utterback Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/11/2015 10:40 PM, William Unruh wrote: On 2015-01-12, Mike S mi...@flatsurface.com wrote: On 1/11/2015 7:16 PM, William Unruh wrote: If that public source is responsible it will pass on to your system the fact that there is a leapsecond, and your system will stop for a second at the last second of June. A system which properly implements leap seconds will do no such thing. It will properly account for a minute with 61 seconds, and will tick from 23:59:59 to 23:59:60 then to 00:00:00. There is no stopping, or any other discontinuity. Well, actually as I understand it, ntpd does stop the cclock for that second, making sure that every successive read of the clock during that time is later than the one before by a few microseconds. until the second ends. That is not the case. That is the behavior that the kernel reference code implements which is not part of ntpd. It is up to the individual OS leap second implementers to determine the behavior they implemented, which may or may not behave this way. -- Brian Utterback Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/11/2015 4:56 PM, Rob wrote: Michael Moroney moro...@world.std.spaamtrap.com wrote: If I have a system synchronized with a public NTP source, which is synchronized with an atomic clock that provides leap second info, and I am watching carefully, what will happen when the leap second hits? Will my system suddenly find its clock off by 1 second and slowly drift to the accurate time provided by the NTP server? That depends on what kind of system it is. Carefully designed systems will do the right thing. Define the right thing. To eloaborate, there is no right thing. There are a whole bunch of things that are right for some people and not for others. That is the very reason that there isn't a right thing, because if there was one right thing all the vendors would have fixed their operating systems to do it. -- Brian Utterback Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ 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/22/2014 11:05 PM, Harlan Stenn wrote: Martin Burnicki writes: Rob wrote: Martin Burnicki martin.burni...@meinberg.de wrote: And of course, the information flow was really bad here, so that it is very hard to figure out which systems are affected. Indeed. Only after 3 days there was a statement on the pool mailing list that the problem only affected servers that can be queried. Well, that had better be stated in the original release, so that 99.9% of the users of ntpd could immediately move it to not for me and not be worried. Yes. I agree that this information should have been available immediately with the first alert. This would have avoided much trouble. And if we had realized all of this at first alert we would have. The announcement came out 3 days' later than I wanted. I'd been working on this for 2 solid weeks by then. So, can we get a definitive statement, perhaps as an update to http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/NEWS as to what an admin can do to mitigate the problem until an update can be performed and whether or not the same CVE's apply to xntpd? -- Brian Utterback Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Jesus Christ! - even internet time-sync (NTP) is vulnerable to exploitation?
On 12/21/2014 8:13 PM, David H. Lipman wrote: From: Virus Guy Virus@Guy . com David H. Lipman wrote: (Dave Lipman posted examples from his router logs of incoming traffic to port 123) Nope. There is no reason to believe that the LAN behind the static IP does anything but syncs time periodically. You've included news:protocols.time.ntp We'll see if anyone form that NG has some input/information. How stateful is your router firewall? The NTP protocol only uses UDP and firewalls often have trouble distinguishing UDP replies. So, one scenario is that you have computer's using the pool directive sending out queries and the replies coming back are getting logged. However, one thing I notice is that the the logs seem to indicate that the actual target port is not the NTP port (123), but instead is the chargen port (19). Unless you have some weird NAT thing going on, I would say that you are not the target of an attack, someone instead is trying to use your network as a pawn in an attack against those NTP Pool servers. If you were not dropping these packets and logging them, they would arrive at a system and if it actually was running the chargen service a response packet filled with data would be sent to the source IP and port, i.e. port 123. Since these are NTP servers, the chargen packet would be delivered to NTP on the server where it would be flagged as a malformed packet. Hopefully such a packet would be immediately dropped but it would be possible that instead it would get an error packet returned to your system's chargen service which would respond with another chargen packet and so on and so on. So, I think it is very likely that someone is sending you those packets with a spoofed source address and port in the hope that your system will start sending packets to the NTP servers possibly forming a nasty data loop and taking them off the error. Just my two cents. -- Brian Utterback Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Jesus Christ! - even internet time-sync (NTP) is vulnerable to exploitation?
On 12/21/2014 11:11 PM, brian utterback wrote: loop and taking them off the error. Just my two cents. Doh! air. -- Brian Utterback Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ 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/4/2014 6:56 PM, William Unruh wrote: One source is fine, unless it either dies or goes nuts. Two are fine, unless on goes nuts. Define goes nuts. Two are not fine if they don't agree on the time, and in my experience the many of the admins that consider using only two servers are unable to get those two servers to agree on the time. Three are fine, as long as only one dies or goes nuts. Again, define goes nuts. You don't seem to like the term falseticker, so how do you define goes nuts? If one goes nuts or even goes offline, if the remaining two do not agree then it is like having no server at all. Brian Utterback ___ 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/3/2014 5:33 PM, William Unruh wrote: On 2014-12-03, Jan Ceuleers jan.ceule...@computer.org wrote: On 12/03/2014 02:58 PM, Brian Utterback wrote: I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. It takes three servers *at all times* to enable clients to use majority voting. So if you want to guard against a single failure (i.e. not a single falseticker, a single server that goes offline), then you need four. Offline IS a false ticker. And no, you need three. In fact to gaurd against offline, you only need two. Guarding against falseticking is harder than guarding against offline. Just as it is harder to guard against a liar than a dead man. I remain unconvinced. I believe that it takes three correct servers to outvote a single falseticker, meaning that if you want to be safe against one of your servers becoming a falseticker and still being accepted as the system server by a client, the client needs at least four servers. Remember that a vote is not for a single offset, it is for a single offset plus or minus the error, which in our case is the dispersion. Be definition a truechimer is a server whose range of offset-disp to offset+disp includes the actual time, while a falseticker is a server whose range does not include the actual time. Now suppose you have three servers, two truechimers and one falseticker, call them T1, T2 and F. The actual time is a bit above the T1 offset, meaning it is in the interval between T1off and T1off+T1disp. The actual time is also in the interval T2off-T2disp and T2off, which is to say that they both overlap with the real time but neither overlaps the other's offset. Now imagine that the falseticker has a similar overlap with T1, but on the interval T1off-T1disp to T1off. That interval does not include the real time, so F is indeed a falseticker. So, we have a completely symmetric situation, with T1 and F voting for an interval that does not include the real time and T1 and T2 voting for an interval that does include the real time. By what mechanism are we to presume that the client will choose the interval that includes the real time? -- Brian Utterback Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ 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/4/2014 12:13 PM, Miroslav Lichvar wrote: On Thu, Dec 04, 2014 at 10:46:17AM -0500, brian utterback wrote: I remain unconvinced. I believe that it takes three correct servers to outvote a single falseticker, meaning that if you want to be safe against one of your servers becoming a falseticker and still being accepted as the system server by a client, the client needs at least four servers. Four (or any larger number) of servers still doesn't guarantee the source selection algorithm will mark one bad source as a falseticker. There was a very similar discussion about this few years ago, including an example: http://lists.ntp.org/pipermail/questions/2011-January/028313.html Now imagine that the falseticker has a similar overlap with T1, but on the interval T1off-T1disp to T1off. That interval does not include the real time, so F is indeed a falseticker. So, we have a completely symmetric situation, with T1 and F voting for an interval that does not include the real time and T1 and T2 voting for an interval that does include the real time. By what mechanism are we to presume that the client will choose the interval that includes the real time? The intersection interval determined in the source selection algorithm will be equal to the interval of T1 and all three servers will pass as truechimers. Adding a third good server may not be enough to change the result. I think we are in violent agreement. The point I am trying to make is that for a long time we recommended four servers then started saying that three was enough but four is better. I think that we should stick with recommending four, at least if you actually care about the time on your systems. Brian Utterback ___ 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/2/2014 4:00 AM, Rob wrote: The whole have 3 servers to select a majority thing is absolutely not required when your servers are accurately synchronized themselves and your requirements are only within-a-second. It is true that when you have two servers the clients cannot know which one is right, but it is trivial to keep servers within a millisecond of eachother with GPS and within 10 milliseconds using only network peering. To that is two orders of magnitude better than you require. Be careful with this generalization. While it may be trivial, it isn't automatic. I deal with customers all the time that have configured exactly two servers on their clients and then are surprised later when all of the clients become unsynchronized and start free drifting. I always recommend against it. I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] problem with pool directive?
I believe that the number of pool servers used is determined by the minclock and maxclock parameters. Brian Utterback. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP server not reducing polling interval on upstream hosts
On 10/18/2014 2:21 AM, Phil W Lee wrote: I'm not going to bother, since discovering that the author refuses to accept the problematic behaviour is a bug, so it ain't getting fixed anyhow. I'll just keep running my otherwise perfectly behaving version of ntpd. We could turn it around and say that you refuse to accept that it isn't a bug. Perhaps the better tack to take is that both sides accept it as problematic and try to understand why and how to fix it. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On 7/9/2014 11:40 PM, Paul wrote: On Wed, Jul 9, 2014 at 8:05 PM, Null wrote: [stuff] Please check the links provided. It would seem the most common problem people have is not being able to think about a network attached reference clock that uses NTP responses rather than PPS + serial stream as a solution to time transfer. It's a Reference Clock not an instance of NTPD. On my campus all critical infrastructure is behind multiple firewalls which manage access control so that's a solved problem. We have no need to restrict access to our NTP service from on-campus hosts but we could. You still have the keys problem. Keys authenticate the NTP server to the client. How would you manage keys? Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On 7/10/2014 9:26 AM, Paul wrote: On Thu, Jul 10, 2014 at 9:07 AM, Brian Utterback brian.utterb...@oracle.com wrote: You still have the keys problem. Keys authenticate the NTP server to the client. How would you manage keys? Are you asking if it supports autokey? It currently doesn't, according to the doc there's one symmetric key slot. I don't manage keys. In my case anyone that can get past the firewalls is entitled to talk to the servers and I'm not invested in mutual authentication as a solution to poor system management. Well, at least it supports the one key and it is apparently changeable. But NTP authentication is not mutual authentication, nor does it have anything to do with entitlement of the client. It is about the client trusting the server, and your firewall doesn't help much with that. That having been said, there are an awful lot of people in the world that simply go on blind trust without any authentication at all. But they are simply relying on the lack of people that would wish to subvert the time in their environment. That works well until it doesn't. Brian Utterback Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Has anyone thought about this?
I think you are missing a very important point. As the frequency correction gets closer and closer to the true correction, the difference between the system clock timestamps and the actual timestamps gets smaller and smaller, meaning that the error introduced by the frequency correction likewise gets smaller. If we assume a situation where the offset actually reaches zero at the same time that frequency correction becomes correct, then that situation is stable as long as nothing changes. Your idea of using the performance counter would then introduce errors at this point and would not be stable or possibly have a node at some point other than the zero offset and perfect correction point. So the answer to your question is yes, there is a way that using the PC timestamps will not be more accurate. The PC is only more accurate as long as the difference between its calculated frequency and it's actual frequency is smaller than the difference between system clock's adjusted frequency and its actual frequency. Brian Utterback On 4/14/2014 9:34 AM, Charles Elliott wrote: Ntpd on my system uses a frequency offset (according to NTP Plotter, thank you very much) of -26 to -28 ppm fairly consistently. If I understand it correctly, that corresponds to a correction of 26 to 28 microseconds on every clock tick. Is there any way that measuring t4p = PC(t4) - PC(t1) is not going to be more accurate, given that the PC driven by the HPET has a resolution of ~70 ns, than t1 = system time and t4 = system time? It would be easy to test. Just record the PC value when p_org (= t1) is set, and record the PC again when p_rec (= t4) is saved. Then send the difference between the new PC values (as t4p, say) to the rawstats log at the end of the line. It would only take a few hours to see if t4 t4p. My new DIY NAS has ntpd running on FreeBSD. It keeps pretty good time. I recorded the ping time (pinging constantly for 5 minutes) from the NAS to two computers here. Below is a table of average ping times and delay as computed by ntpd: Avg. pingntpd Computertimedelay 1 0.264681 0.236 ms (Win 7, Core i7 3820, GA-X79-UD3 (rev 0) mobo, Gigabit Ethernet) 2 0.337169 0.321 ms (win 8, Core i7 3820, GA-X79-UD3 (rev 1) mobo, Gigabit Ethernet) Note that they are different. Charles Elliott -Original Message- From: questions-bounces+elliott.ch=verizon@lists.ntp.org [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On Behalf Of Terje Mathisen Sent: Thursday, April 10, 2014 10:21 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Has anyone thought about this? Brian Utterback wrote: On 4/10/2014 3:22 AM, Terje Mathisen wrote: The maximum ntpd slew is 500 ppm, which means that the absolute maximum possible slew between UTC and the local clock would be 1000 ppm (i.e. the clock is maximally bad, at +500 ppm, and we are currently slewing at -500 ppm), in which case the maximum error component from this would be 1/1000th of the actual time delta. (In real operating systems the actual errors are several orders of magnitude less! Typical clock frequency adjustments due to temperature cycling are in the single ppm range, but even a few tens of ppm gives relative errors in the 1e-4 to 1e-5 range, which doesn't impact the control loop at all. I am pretty sure that the 500 ppm is absolute and is already the sum of the frequency correction and the current clock slewing. But one of Oh sure, that is why I wrote that this is the theoretical maximum possible, with real-life servers being at least an order of magnitude better behaved. the reasons for having a maximum in the first place is to put a cap on the error introduced because if the instantaneous frequency corrections taking place at the time the timestamps are taken. This is all covered in chapter 11, Analysis of Errors, in the first edition of Das Buch (Computer Network Time Synchronization, Mills, 2006). I am pretty sure that it is also in the 2nd ed, but I don't have access to that one. Neither do I, but I am absolutely sure Dr Mills included this error component in his stability and convergence calculations. :-) If you do allow far higher slew rates, like some other programs do, then you would indeed have to separate the offset slew from the frequency correction, and use the frequency clock only to measure delta-Ts. The easiest way to do this is of course to keep a sw delta clock around, this one would start out the same as the OS clock, but then only include any frequency adjustments to its rate, and not any slew adjustments. At this point either HPET or RDTSC could be used as the common frequency source for both clocks. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo
Re: [ntp:questions] Has anyone thought about this?
On 4/10/2014 3:22 AM, Terje Mathisen wrote: The maximum ntpd slew is ± 500 ppm, which means that the absolute maximum possible slew between UTC and the local clock would be 1000 ppm (i.e. the clock is maximally bad, at +500 ppm, and we are currently slewing at -500 ppm), in which case the maximum error component from this would be 1/1000th of the actual time delta. (In real operating systems the actual errors are several orders of magnitude less! Typical clock frequency adjustments due to temperature cycling are in the single ppm range, but even a few tens of ppm gives relative errors in the 1e-4 to 1e-5 range, which doesn't impact the control loop at all. I am pretty sure that the ± 500 ppm is absolute and is already the sum of the frequency correction and the current clock slewing. But one of the reasons for having a maximum in the first place is to put a cap on the error introduced because if the instantaneous frequency corrections taking place at the time the timestamps are taken. This is all covered in chapter 11, Analysis of Errors, in the first edition of Das Buch (Computer Network Time Synchronization, Mills, 2006). I am pretty sure that it is also in the 2nd ed, but I don't have access to that one. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Three NTP servers, one strange IP-address in 'refid'
On 03/31/14 14:44, Sander Smeenk wrote: Quoting Rob (nom...@example.com): | root@dns1:~# ntpq -c lpeers | === | *someserver.tld .PPS. | +someserver2.tld .GPS. | -someserver3.tld .PPS. | dns2.dns.dmz.bi 172.2.53.81 | dns3.dns.dmz.bi 172.2.53.81 | +someserver4.tld .PPS. So in the above, dns2 and dns3 (two separate servers) both take their time from 172.2.53.81 This is not a server you are talking to, but a server they are talking to. Well, yes. You would say that. But dns2 and dns3 *also* sync to someserver.tld primarily(*), with two reference/fallback sources(+) and one not considered(-). They both show either dns1 and dns2 or dns1 and dns3 as syncing to 172.2.53.81. I can't find this IP, or any hostname resolving to this IP, in any of my configs. So i'm inclined to go with David Woolley's comment: 'refids are opaque'. Opaque as that remark may be. ;-)) -Sndr. The IP is coming from somewhere. When David said they are opaque he means in general. The refid is overloaded and has different interpretations under different circumstances and sometimes ntpq can get confused about what circumstances are currently in effect. But it seems very likely that the IP address is the correct one particularly since the first octet matches the first octet of your address space. It would be helpful if you posted the whole peers output, particularly for dns2 and dns3. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Problem facing with Ntp client Configuration
On 3/27/2014 8:46 PM, William Unruh wrote: Yes. Argument through hyperbole. There is an argument for more than 1 sever, but you should recognize what that argument is. Three are more than enough(that guards against one going crazy.) If you really think that there is chance that more than one will go crazy 5 is good, but if there is resonable chance of 2 going crazy, then the probabilities become high that more than 2 will as well, at which point you enter an arena of dimishing returns. You need to fix your sources, not rely on more and more servers. So, one is fine, recognizing that there is no way of noticing if that one goes crazy. Two are no better than one, and have the danger of hopping from one to the other if one goes crazy, so three is a protection against one going crazy. If it is more than that, you have problems that needs a human to fix. It is true that hard disks have almost half of the bits being parity bits, but they also impliment a rather more sophisticated error identification and correction algorithm than does ntpd. And if one of your sources is going crazy, ntpd should send you a message to that effect so you can fix it, or use a different server. One is fine if all you care about is that the human readable clock has the right time so you are not late to your meetings. Two is never fine, and not just because of clock hopping. Like the old adage, a man with a watch knows what time it is, a man with two watches is never sure, NTP will often refuse to set the time with just two upstream sources if the two sources do not agree and the dispersion intervals do not overlap. That means that two servers can agree on the time to within a millisecond of each other, but is the dispersion is less than a half of a millisecond, NTP will not set the clock by either of them. With three you guarantee that there will always be an acceptable interval from any three truechimers. But you are susceptible to a falseticker here, and remember a falseticker just means that the offset interval doesn't overlap with the correct time. As I pointed out above, a server only has to be a little off to be a falseticker, but if you can't detect it, then your potential for error in your offset grows in relation to how far off the falseticker is. Sure, you are better off fixing your sources, but it doesn't take much perturbation to throw a server off, at least for a while. I always say if you are serious about time synchronization, then you need at least four server, for the reasons given above. You are not taking advantage of all of NTP algorithms until you have four servers. So, I agree with you that adding more after four is an exercise in diminishing returns. Going from four to five might be worthwhile, but beyond that doesn't generally add much in my experience. But I would like to point out something to you. You often remind us that NTP only uses one in eight data points. But each server you add means one more data point used, which means that if eight servers were used then NTP would be using the same number of data points that it would be if it only had one server and used all the data points. The fewer servers you think are needed to get adequate time sync means the fewer data points out of the eight you think are optimal. If one server is really enough, then one out of eight is enough. If four servers are enough, then four out of eight samples are enough. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] [Android+NTP] synchronise time with millisecond accuracy
On 3/26/2014 8:00 AM, mike cook wrote: Le 26 mars 2014 à 12:09, Coiso22 a écrit : Hi all, I am trying to synchronise the time of an Android device with a local machine, for test purposes, using ntp. However, the difference between the time of the device and the ntp server is always around 5 milliseconds. Is there any way to synchronise the device with milliseconds accuracy? Here is my test scenario configuration: Android Server: This is a machine running Debian that will be used as the ntp server and will send traffic to the Android device. This machine is connected with an Ethernet cable to have internet access Android AP: This machine is running Debian and acts as an Access Point. It is also connected to the Android Server with an Ethernet cable. Android Device: An Android device with root access. It is connected to the Android AP via WiFi. This device will receive the traffic generated by the Android Server, and must be synchronised with it. Some notes: I do not need the Android Server to be synchronised with an external ntp server. Therefore, I changed the ntp.conf to have only server 127.127.1.0. In order to synchronise the Android device I use the ntpd and have also tried with ntpclient. However, the results are very similar. You could take out any network transmit/receive asymmetry by having the server broadcast and configure the android device as a broadcast client. As a quick test I pulled the ethernet cable on my laptop and configured wifi so I have a similar topology to you , though BSD. It is configured in standard client/server mode. en0: flags=8863UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether 34:15:9e:01:e5:9c inet 192.168.1.12 netmask 0xff00 broadcast 192.168.1.255 media: autoselect (100baseTX full-duplex,flow-control) status: active electron:~ mike$ ntpq -pn remote refid st t when poll reach delay offset jitter == *192.168.1.4 .PPS1. 1 u 49 64 3770.938 -0.284 0.037 # pull the ethernet cable and configure wifi en1: flags=8863UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether f8:1e:df:e4:49:41 inet 192.168.1.14 netmask 0xff00 broadcast 192.168.1.255 media: autoselect status: active # wait until the dust settles. NTP takes a bit of time to get to a clean state. electron:~ mike$ ntpq -pn remote refid st t when poll reach delay offset jitter == *192.168.1.4 .PPS1. 1 u 20 64 3771.6000.131 14.759 As you can see the delay and jitter (which is very variable ) go up, but the offset stays 1ms. So it should be possible for you to do better. If you have another non Android wifi client on your net, what do you see with that as a client? Mike, what makes you think that this is any more accurate than it was before? It surely is the case that NTP thinks that it has less offset, but with a jitter value that high is it almost certainly wrong about that, but it has no way to know what the real value is, so it displays only what the latest calculated offset of the moment was. Essentially you went from an offset of -0.284+/-0.037 to an offset of 0.131+/-14.759 I don't think that is an improvement. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] CVE-2013-5211 and xntpd
On 2/7/2014 3:14 AM, Martin Burnicki wrote: Harlan Stenn schrieb: Brian Utterback writes: I did test it and saw indications that it would be vulnerable. I don't have exploit code so I didn't actually get an exploit going, but I saw enough to convince me. If xntpd responds to the mode 7 monlist command it's vulnerable, and the easy fix is to add a 'restrict default noquery' line to the config file. I agree xntpd is probably also vulnerable, but did it already support the restrict keywords necessary to fix this? Martin I just checked version 3.4y and yes, it has the necessary restrict noquery capability. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] CVE-2013-5211 and xntpd
I recently received a question from a customer about CVE-201305211, the monlist amplification attack. Specifically they asked if the attack affected xntpd. They had another vendor that said no, that the attack only affects ntpd. This surprised me since as far as I know the monlist mechanism is the same in xntpd. I thought the vendor was merely incorrect. However, I then read the CERT and NIST versions of the CVE and there is no mention of xntpd. Indeed, a literal reading of the CVE does indeed imply that xntpd is not vulnerable. I don't think I am wrong about xntpd being vulnerable. If I am, please correct me. But if I am not, we should probably see about getting the CVE amended. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] CVE-2013-5211 and xntpd
On 2/6/2014 10:31 AM, mike cook wrote: I think you are right. My reading of the CVE gives me to believe that xntpd is vulnerable. xntp is a full implementation of NTP V3 and the CVE indicates all versions of ntp earlier than 4.2.7 are vulnerable. It is very easy for you to test as xntpd is(or was) distributed with with Solaris. I did test it and saw indications that it would be vulnerable. I don't have exploit code so I didn't actually get an exploit going, but I saw enough to convince me. The problem is that the CVE doesn't say that all versions of ntp before 4.2.7 are vulnerable, it says that all versions of *ntpd* before 4.2.7 are vulnerable. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] CVE-2013-5211 and xntpd
On 02/06/14 17:05, Dennis Ferguson wrote: On 6 Feb, 2014, at 07:39 , Danny Mayer ma...@pdmconsulting.net wrote: On 2/6/2014 9:26 AM, Brian Utterback wrote: I recently received a question from a customer about CVE-201305211, the monlist amplification attack. Specifically they asked if the attack affected xntpd. They had another vendor that said no, that the attack only affects ntpd. This surprised me since as far as I know the monlist mechanism is the same in xntpd. I thought the vendor was merely incorrect. However, I then read the CERT and NIST versions of the CVE and there is no mention of xntpd. Indeed, a literal reading of the CVE does indeed imply that xntpd is not vulnerable. I don't think I am wrong about xntpd being vulnerable. If I am, please correct me. But if I am not, we should probably see about getting the CVE amended. If this is about NTP v3 then that version hasn't been supported in something like 15 years. I believe that it is very likely vulnerable but noone is going to go into the code to look assuming that they can find the source for something like that. I believe it was Dennis who wrote the mode 7 code and tools, so NTP v2 is likely vulnerable as well but that's not in the CERT either. xntpd claimed to be NTP v3 from its inception, and had both xntpdc and ntpq by the time anyone other than me saw it. It was implemented from a moving-target draft of the NTP version 3 standard that was available as early as 1988 (i.e. before the NTP version 2 RFC was published; that was done late since there was resistance to the postscript format). Fuzzballs also claimed to be version 3 by then too, though there was an existing Unix daemon called ntpd implementing NTP v2 only, this being the reason that xntpd got an 'x'. The mode 7 protocol was implemented as a debugging tool during development, the mode 6 protocol was implemented after that got added to the version 3 draft and supported by the fuzzball servers, so you could ask fuzzballs about their peers too. That said, when I stopped work on xntpd there was no monlist query since there was no monitor list. If you wanted to know who your clients were it used a much heavier duty (but cheaper to implement) method, a knob telling it to keep peer state for all peers rather than just the configured ones. When I left it, I don't believe there were any queries in either protocol which would result in more than one response packet per query packet, and I had tried to keep responses under 520 bytes of payload (or whatever the number was which guaranteed no fragmentation then) for mode 7 since I lived at the end of a very overloaded Internet connection and it worked better with single packet request/responses. I had less control over mode 6, though. If there's something called xntpd which supports monlist it must have been added after me, but before the name of the program was changed to ntpd. I don't know when that was. Dennis Ferguson The oldest NTP v3 distro I have around is 3.4y, and it has monlist. It looks to date from about 1994 or so. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP request retry?
On 1/26/2014 2:08 PM, Rob wrote: On a very quiet network, I observe that ntpd sometimes has a very high loss rate: reach is 6, for example. When using ping or any other protocol, no packet loss at all is observed. My hypothesis is that the ARP entry for the NTP server has timed out, and when ARP has to resolve an entry in some implementations the first packet is always lost (it is not cached pending a reply). When the cycle is 1024 seconds, the ARP entry has again timed out the next poll cycle and the issue is the same. Is there a way, short of switching to burst mode, to make ntpd retry a request when no reply is received e.g. within a second? It should only retry when there is no reply, and not more than e.g. 3 times (when still no reply it should simply wait for the next poll cycle) I don't know about lost packets. It seems to me that dropping the packet that triggered an ARP request is not very robust, in fact it is down right fragile. Are you sure that there really are such implementations? On the other hand, I have definitely observed that phenomenon as a source of asymmetric round trip time. The outgoing request packet gets delayed for ARP request and reply at each hop, but the return packet has no such delay. Quite a while ago I suggested a special burst mode where two packets were sent, one shortly after the other and the first one would be ignored. Dr. Mills said that the first would generally be ignored because of the longer round trip time (delay), but I thought that treating the first packet as a throw away would be better because otherwise you end up with half the number of good samples in the billboard. Anyway, nothing every came of the discussion. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] strange ntptrace behaviour on different ntp-clients
What version of Solaris were you using? If you were using Solaris 10, then the ntptrace command is the old version that uses the ref field as the IPv4 address of the server. Since it does not rely on control or private packets it can work even if noquery was specified on one of the servers in the chain. Since the ref field cannot hold an IPv6 address, the ntptrace program was changed in NTP version 4 to use control packets to find out the IP address of each server. This works with both IPv4 and IPv6, but requires all the servers to allow control packets. On 1/23/2014 2:52 AM, ardi wrote: I have tried to set up 3-level for ntp-setting: xx.xx.xx.aa stratum 1 server (taking time from GPS) --- xx.xx.xx.b1 xx.xx.xx.b2 are stratum 2 servers acting as ntp-servers xx.xx.xx.c1 xx.xx.xx.c2 are stratum 3 ntp-clients NOTE: all clients have stratum 2 servers defined as ntp-server time sources. a) when doing ntptrace from a client (without parameter), I am getting Timed out : NOK: client.c1 # ntptrace localhost: stratum 3, offset -0.33, synch distance 0.000230 xx.xx.xx.b1: timed out, nothing received ***Request timed out client.c1 # NOK: client.c1 # ntptrace xx.xx.xx.b1 #towards stratum 2 server xx.xx.xx.b1: timed out, nothing received ***Request timed out OK: client.c1 # ntptrace xx.xx.xx.aa #stratum 1 ntp-server aa.dfdsf.sdff.lab: stratum 1, offset -0.02, synch distance 0.00, refid 'GPS' client.c1 # doing it from another client, which is solaris: OK: bash-3.00# ntptrace localhost: stratum 3, offset 0.26, synch distance 0.01694 xx.xx.xx.b1: stratum 2, offset 0.000160, synch distance 0.00133 aa.dfdsf.sdff.lab: stratum 1, offset 0.000315, synch distance 0.00021, refid 'GPS' bash-3.00# NOTE: for xx.xx.xx.b1 the first line of ntp.conf is the following: restrict default noquery nomodify notrap b) when i remove noquery parameter on stratum 2 ntp-server xx.xx.xx.b1 and restart ntpd: for xx.xx.xx.b1 the first line of ntp.conf is the following: restrict default nomodify notrap then ntptrace from client.c1 is ok What causes that solaris clients work in both cases and for client.c1 only in case, when noquery is removed from stratum 2 server? Peter ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] simple nt.conf cases for ntp-client
On 1/23/2014 8:06 AM, Marco Marongiu wrote: If you have just two references, the step 2) doesn't bring you anywhere as it is impossible to reach a majority. It's like you're skipping step 2), and the results lose accuracy. Not to put too fine a point on it, but if you have two servers and one of them has the correct time and one is way off, with only two servers the one that is far off is just as likely to be chosen as the correct one. Worse still is you are subject to clock hopping, where each of the two servers are chosen alternately. Most news versions of NTP have a certain amount of server stickiness built in to suppress clock hopping, but it can still occur, especially if your servers reboot frequently. Clock hopping can destabilize the frequency correction feedback loop which in turn can lead to increasingly large clock offsets. Not what you want. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] strange ntptrace behaviour on different ntp-clients
On 1/23/2014 10:00 AM, peter knezel wrote: I presume rstr means relative stratum: 0 means xx.xx.xx.aa is above xx.xx.xx.b1 1c0 means all others are clients 1 level lower to xx.xx.xx.b1. Is that so? No. The rstr field displays the restriction mask. So 1c0 is RES_NOTRAP, RES_NOMODIFY, RES_NOQUERY. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 1/16/2014 3:45 PM, Steve Kostecke wrote: On 2014-01-16, Greg Troxel g...@ir.bbn.com wrote: Harlan Stenn st...@ntp.org writes: The majority use case for ntpd is to synchronize your clock to UTC (i.e. a leaf-node client). So an ntpd ought to have the following defaults: driftfile /path/to/ntp.drift pool pool.ntp.org iburst restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 This would enable the majority use case without the need for a configuration file. I just tried that with 4.2.7p381 and it failed to get any servers. I added: restrict source and it still failed. I commented out the first two restrict lines and then it worked. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 1/15/2014 7:18 PM, Greg Troxel wrote: [invalid William has been trimmed from the cc list] Harlan Stenn st...@ntp.org writes: William Unruh writes: I do not mean the default in the config file, I mean the default if there is no config file or if nothing is set in the config file. Then ntpd won't connect to anything and there will be no data to report. This is a ridiculous strawman. The ntp project is abdicating its responsibility to provide sane default behavior by claiming that no default behavior can make everyone happy and therefore it's not their fault. The notion that OS packagers somehow have a better idea of usage is also specious. Really, ntpd should, when run with a config file of only server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org behave relatively sanely, including declining to respond to packets that could be amplification attacks, while being usable as a s2/s3 to other nearby nodes. This notion of good behavior under minimal config seems really obvious to me, yet there is a huge resistance to it, with the notion that every end user should invest the time to be an expert. And, as far as I can tell, seems to be as simple as 'restrict noquery' as a compiled-in default before any restrict statements are given. Yet that does not happen. By default, the dev branch software doesn't respond to mode 7 packets and even if mode 7 packets are enabled it still doesn't respond to monlist requests. So, if it is as simple as you say, then you've got your wish already. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 12/27/2013 5:24 AM, Rob wrote: What is the NTP developers position on implementation of better rate limiting options in ntpd? There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. Possible candidates are of course the commands to retrieve the list of clients (similar to ntpdc -c monlist) and and the list of associated servers (ntpq -p). In the current code monlist is replaced by mrulist. The mrulist command requires a handshake, so a spoofed address would not be possible. However, it might be wise to limit the number of packets sent per exchange. Currently the client sets the number but a man in the middle attack would still be possible. We could set the maximum number of packets sent per return packet to relatively small. The current implementation on the client sets it to 32, but we could allow a maximum of 4 or 8. 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? Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
On 12/27/2013 11:49 AM, Rob wrote: Brian Utterback brian.utterb...@oracle.com wrote: On 12/27/2013 5:24 AM, Rob wrote: What is the NTP developers position on implementation of better rate limiting options in ntpd? There are more and more amplification attacks against ntp servers, similar to those against open DNS resolvers. A small packet sent with a spoofed source address (allowed by a lame ISP) results in a large reply from ntpd, sent to the victim of the attack. Possible candidates are of course the commands to retrieve the list of clients (similar to ntpdc -c monlist) and and the list of associated servers (ntpq -p). In the current code monlist is replaced by mrulist. The mrulist command requires a handshake, so a spoofed address would not be possible. However, it might be wise to limit the number of packets sent per exchange. Currently the client sets the number but a man in the middle attack would still be possible. We could set the maximum number of packets sent per return packet to relatively small. The current implementation on the client sets it to 32, but we could allow a maximum of 4 or 8. 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? Brian Utterback Are you doubting the fact that NTP is used for amplification attacks? It is a fact... and many ntp pool members have faced the consequences already. I think what has to be discussed is the countermeasures, not the fact. Not at all. I am asking the parameters of the attack. Is the current software solution sufficient to stop such attacks? If so, then the solution is for the servers to upgrade. Indeed, no solution we craft for the current software development will help sites that do not upgrade. So, if the current software is subject to attack, is the attack always via mrulist or does the peer command also cause a problem? If it is mrulist only, then scaling back the maximum packets should make it a less attractive vector. Indeed, you could easily make the amplification dynamic, scaling back to one or two packets per exchange when the rate is high. If peers are a problem too, then a more general solution might be in order, such as the rate limit you mentioned. Unfortunately, the exchange is specific to mrulist. Perhaps an uprev of the protocol so that an exchnage is always required. I think I outlined a scheme such as that earlier. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] better rate limiting against amplification attacks?
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
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
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.
Brian Utterback
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Pool returns IPv6 address to IPv4 query
On 11/20/2013 4:44 AM, Rob wrote: Brian Utterback brian.utterb...@oracle.com wrote: On 11/19/2013 3:40 PM, Danny Mayer wrote: You should not be using literal IP addresses of either flavor without also setting the AI_NUMERICHOST flag otherwise it tries to do a DNS lookup. That's poorly written code otherwise. Danny Not so. The getaddrinfo function will recognize literal addresses and merely convert them. The point is that for something like ssh or any other network utility, the user is supposed to give a hostname, but in virtually all cases you can give a literal address and the application does not have to treat it differently. If you read the ipng mailing list, you will see that they were trying to make the whole process of writing a network application simpler, with getaddrinfo doing the heavy lifting for all of the major cases. At the same time they were trying to allow applications to work on either IPv4 or IPv6 systems without changing them, or dual stack or any combination. But no matter what they did there were edge cases that needed to work differently. Brian Utterback Well most of it was successfull, I converted an application from the old functions to getaddrinfo/getnameinfo etc, and it really is more convenient to program for. However, what I don't understand is why an IPv6 address does not fit into a struct sockaddr, and why this fact is so badly documented. It took me a lot of time to find why my queried IPv6 addresses were truncated. It is a little tricky to be sure. Part of it was backwards compatibility and history, part of it was providing the proper abstractions. The root cause of course is that IPv6 addresses are longer than IPv4 addresses. If you use them properly, you should never have a problem with truncation though. You would have to be trying to put a IPv6 address into a IPv4 sockaddr for that to happen. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Pool returns IPv6 address to IPv4 query
Just as a point of interest, one of the most heated debates I have ever been involved in internally here at Oracle was concerning whether getaddrinfo (as defined by POSIX) should or should not return IPv6 addresses if the system only has IPv4 interfaces and/or only the loopback IPv6 address. The getaddrinfo call was designed to work efficiently on both dual stack and single stack systems, but the wording in the standard is slightly ambiguous especially considering the case that the host you are looking up might actually belong to the system you are on. On 11/18/13 16:01, Danny Mayer wrote: On 11/18/2013 2:44 PM, A C wrote: On 11/18/2013 11:18, Majdi S. Abbas wrote: The fact that it's even trying means you didn't start ntpd with -4, and the host has at least one IPv6 interface (this might be as simple as v6 enabled on the loopback.) So, either ensure that v6 is fully disabled on the host, or add -4 to your ntpd startup parameters. lo0 did indeed have a v6 address configured (hadn't noticed) though my eth0 does not. I would not have expected ntpd to use v6 if any one interface did not have it. Up until this point it never returned a v6 address on lookup so that's probably why I never noticed that v6 had been enabled again (recent upgrade of OS). I've disabled all v6 now and added -4 for good measure. ntpd will use whatever addresses it gets back from DNS. If you don't specify that you only want IPv4 addresses and it gets an IPv6 address it will attempt to use it. This is a DNS and configuration issue not an ntp issue. This is true of all applications (whether client or server) these days. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Pool returns IPv6 address to IPv4 query
On 11/19/2013 12:33 PM, Rick Jones wrote: Danny Mayer ma...@ntp.org wrote: That must have been a short discussion. getaddrinfo() has nothing to do with the IP stack. getaddrinfo()'s job is to get information from the nameservers you specify in resolv.conf or wherever else the OS has that information. Its job is NOT to make decisions about what it should ask for. That's the programmer's job when setting up the API call as to what addresses to ask for. I suspect it all boils down to the behaviour when one sets AI_ADDRCONFIG in the getaddrinfo() call. When that is set, ostensibly getaddrinfo() is supposed to filter-out any reponses that are of a type that cannot be used by the application. The decision made was if there were no non-loopback-interface IPv6 addresses configured, records would not be returned from the getaddrinfo() call. Similarly for A recorecords if there were no IPv4 addresses configured on the system. Later, when interfaces started getting auto-configured, local scope IPv6 addresses, there was a call to change that to be don't return IPv6 addresses unless there is a better-than-local-scope IPv6 address assigned. Started causing me all manner of pain in netperf :( Not sure where that stands now in the Linux world. rick jones Yes, that was the issue. Further complicating it was what do you return if you have no IPv6 interfaces and you set AI_ADDRCONFIG and you pass in a literal IPv6 address. The problem is that getaddrinfo replaces both gethostbyname and inet_aton, each of which you might expect to have different results in that case. We had people citing two RFC's and the ipng working group mailing list. Great fun. Brian utterback Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Pool returns IPv6 address to IPv4 query
On 11/19/2013 3:40 PM, Danny Mayer wrote: You should not be using literal IP addresses of either flavor without also setting the AI_NUMERICHOST flag otherwise it tries to do a DNS lookup. That's poorly written code otherwise. Danny Not so. The getaddrinfo function will recognize literal addresses and merely convert them. The point is that for something like ssh or any other network utility, the user is supposed to give a hostname, but in virtually all cases you can give a literal address and the application does not have to treat it differently. If you read the ipng mailing list, you will see that they were trying to make the whole process of writing a network application simpler, with getaddrinfo doing the heavy lifting for all of the major cases. At the same time they were trying to allow applications to work on either IPv4 or IPv6 systems without changing them, or dual stack or any combination. But no matter what they did there were edge cases that needed to work differently. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Strange refid
On 11/11/13 01:35, A C wrote: Anyone care to explain what this refid means? This is from the billboard on one of my machines. This came from the round-robin DNS pool but I couldn't tell you which round-robin provided it other than one of the North America or US pools. 204.109.63.243 .M-F.\.. 16 u 86 512 376 58.947 -201.11 138.426 I just looked at the code for printing the refid and if it decides that the refid is not an address and that it should print it in ascii, the routine makeascii is called to do the conversion. Oddly enough, if the character is has the high order bit turned on, it prints M- and then the character with the high order bit masked off. So, if the refid was 192.46.92.46 and it decided to run it through makeascii anyway, it would print as .M-F.\.. Now, while it looks like a valid IP address, it doesn't seem to be one of the servers that 204.109.63.243 is currently using (maybe previously?) nor does it explain why an IP address got printed as ASCII, but it does explain how we got 6 characters out of 4 bytes. However, it begs the question of why somebody thought that printing M- before characters with the high order bit turned on would be a good idea. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Strange refid
On 11/12/2013 1:02 PM, Gary Johnson wrote: On 2013-11-12, John Hasler wrote: Brian Utterback writes: However, it begs the question of why somebody thought that printing M- before characters with the high order bit turned on would be a good idea. ASCII characters with the high bit turned on are control characters. No, they're not. Control characters are those with all but the lowest five bits set to 0. M- is a common notation for control as in M-J for control-J. M-J is 0xCA whereas Ctrl-J is 0x0A. Regards, Gary Okay, I can see why someone might have thought it was a good idea at the time, but it clearly fails as a long term strategy since it is only obvious after it is explained. And particularly considering that this feature would never be exercised except through a bug. Brian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] DDOS attacks and NTP
On 11/5/2013 5:41 AM, Marco Marongiu wrote: Hi all A colleague contacted me yesterday and asked: You being somewhat tied to the NTP world, hear anything about public NTP servers being used for amplification in ddos attack? I haven't heard anything about that. Have you? In case, anything you can share about that? There was a CVE many years ago that sounds similar. It was possible to send a malformed NTP packet with a spoofed IP address that resulted in continuous ping ponging between two servers. If you did that with enough servers so that they were all ping ponging packets with one server, you could swamp it. But as I said that was fixed quickly and years ago. Brian Utterback. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTPD silently not tracking
On 9/1/2013 7:10 AM, Rob wrote: Maarten Wiltink maar...@kittensandcats.net wrote: unruh un...@invalid.ca wrote in message news:n5lUt.340835$qt4.176...@fx22.iad... On 2013-08-31, E-Mail Sent to this address will be added to the BlackLists Null@BlackList.Anitech-Systems.invalid wrote: [...] perhaps it has already been fixed in a more recent version. Sorry, but I have always found this to be a complete copout. You can keep the complainer busy till doomsday trying out different version and different configs. Do you know that others have had this person's problem? Do you know thatthe latest version fixes them? Otherwise you are simply sending him on a fishing expidition. As a developer (not NTP) myself, I don't react well to people complaining about bugs I've already solved, just not in the version they have. So the first reply is always going to be 'upgrade, and see if it goes away.' Especially with things like NTP, if it goes away, the problem is solved. Even if you're not sure, you try this first. Plain common sense, and common courtesy. No fishing expedition, just a one-time upgrade and if the problem stays we go to work. Groetjes, Maarten Wiltink Like unruh, I hate developers and companies with this attitude. When there is no reason to believe that a particular problem is solved in a later release, it is just annoying when the suggestion from support departments is to first install the latest version and see if that fixes it. It is just a way to wave off the initial complaint and to keep others busy. What is even worse: when people report an issue and it goes on a bug registration system (e.g. bugzilla), and after some time has elapsed a person marks all open bugs with remarks like we have not heard about you for a while, please install latest version maybe it was fixed. As if that many bugs are fixed by accident. Sometimes it even happens with feature requests. Also remember that it is not always straightforward to upgrade a program. People often install ntpd as part of an OS (Linux) distribution, and it is integrated into the system by their distributor. Getting a newer version compiled from scratch and replacing the integrated version can be a major and risky operation, especially for someone not proficient in such tasks. You get what you pay for. As a support professional, I will not suggest upgrading unless I have reason to believe that the upgrade will actually fix the problem. Often upgrading is the right thing to do if there is a good chance that in that one step the problem is solved instead of having a prolonged series of tests and analysis. Keep in mind that even if we finally do isolate a bug and fix it, the customer will still have to upgrade to get the fix. But certainly mindless upgrade and see if it goes away is not what you expect from a support contract. So, if you have a paid support contract for NTP, then fine, you have a right to complain. If not and you are getting help from volunteers, then I think they have a right to expect that you have done what you can to eliminate the problem yourself including upgrading to the latest available version if possible, or at least to take it under advisement if it is suggested to you and to explain why you can't if it isn't possible. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Raspberry Pi error in PPM offset
On 8/24/2013 9:46 AM, james.perou...@gmail.com wrote: So, are you saying that the PPM value returned by NTP is to be ignored, is purely for information purposes, and is not to be interpreted as having any real-world meaning? istinfo/questions Yes and no. The value displayed is the adjustment to the frequency that NTP had to apply to maintain the time offset at zero. So your supposition that the actual system clock frequency is 2.5 ppm different than the clock frequency the kernel is using is correct, and indeed if you could accurately tell the kernel the correct frequency then you could get that number to zero. However, what is the point? Why do you care if the value ends up at zero? If you are using the kernel discipline (ntp_adjtime call) then the kernel has been told the more accurate number anyway and it is using it to update the clock. That is the whole point of making that calculation. Another problem is that the actual frequency usually isn't static. It changes with the temperature among other factors. So even if you got the kernel to use the correct value, it would still be off some of the time. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Order of servers in ntp.conf
I don't understand how you get the idea that your system is synchronizing with only one server when the messages you posted show it synchronizing with 6 servers. Do you mean that it is synchronizing with one server at a time? That is what it is supposed to do. There is a combining step in the algorithms that can adjust the actual offset used by combining with offsets from others in a selected group, but there is always a single primary sync source. On 8/14/2013 11:03 AM, Nils Brubaker wrote: Thank you, un...@invalid.ca, for your response to my question. Couple follow-up questions. My ntp.conf running on Linux has 4 servers defined: server 0.rhel.pool.ntp.org server 1.rhel.pool.ntp.org server 2.rhel.pool.ntp.org These are public servers from the NTP pool project. In my /var/log/diag-log file, I see messages indicating that my ntpd is synching with individual servers, for example: Aug 7 09:53:58 yellowstone ntpd[3272]: synchronized to 69.50.219.51, stratum 2 Aug 7 10:04:52 yellowstone ntpd[3272]: synchronized to 184.82.112.110, stratum 2 Aug 7 10:39:05 yellowstone ntpd[3272]: synchronized to 69.50.219.51, stratum 2 Aug 7 11:28:17 yellowstone ntpd[3272]: synchronized to 184.82.112.110, stratum 2 Aug 7 12:47:06 yellowstone ntpd[3272]: synchronized to 128.10.19.24, stratum 1 ... Aug 8 11:37:43 yellowstone ntpd[3254]: synchronized to 50.116.55.65, stratum 2 Aug 8 12:18:46 yellowstone ntpd[3254]: synchronized to 50.116.55.161, stratum 2 Aug 8 13:01:27 yellowstone ntpd[3254]: synchronized to 38.101.77.21, stratum 2 Aug 8 15:01:00 yellowstone ntpd[3254]: synchronized to 50.116.55.161, stratum 2 Aug 8 16:09:20 yellowstone ntpd[3254]: synchronized to 38.101.77.21, stratum 2 These log messages suggest that ntpd is synchronizing with one and only one NTP server. Is that the correct interpretation? Is this single server selected for synchronization only after performing all the calculations described below? Also, I see long time periods in the diag-log where there is no synchronization message. What does that signify? No agreement between the servers on the correct time? No need to adjust system clock because it is already in sync? Thanks, Nils Brubaker On 2013-08-13, Nils Brubaker ncb at us.ibm.com wrote: For ntpd 4.2.4p6 running on Linux, is there any significance to the order of servers in the ntp.conf file? Will ntpd synchronize with the first available/good time server in the list? No, no. ntp gets the data from all the servers. It then looks at the times it gets from each server, and groups them into classes according to its estimate of the max time error from the server-- ie whether the error intervals overlap or not. It then looks for the largest group of servers all of whose error intervals overlap and uses the average of those times as the time to send on the the ntp engine. The others are false tickers. It estimates the error by looking at the round trip time and the other machine's estimate of its own max error. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP makes a time jump
On 7/11/2013 7:37 AM, Igor wrote: yes David, true. was kind of stressed and forgot to update legend and values. these are seconds on both axis. X is elapsed time and Y is delta between a real NTP time and time of server and two clients. I'll re-upload gaph. The graph shows pretty much what I would expect. Yours is a pretty common scenario, but it is also an impossible one. You want system clocks that are undisciplined and unhardened to stay very close in time to each other when not connected to the Internet, but to be close to the real time as quickly as possible when connected and never jump the clock. You need to break one of those requirements for the sake of the others. Either get a refclock for your highest stratum servers so they are never disconnected from the real time, or harden the oscillators on you high stratum servers so that they don't drift when not connected or let them step so that they quickly get back to the real time when connected. In fact, it looks to me that you clients are pretty much doing what you want. They all stick pretty close to one another as they slew to follow the higher stratum servers. I bet they would stick even closer if they peered with one another. Realistically, are your systems really likely to drift to 15 seconds offset between connections? How long do they get disconnected for? Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd is spawning multiple processes
Did you see my previous message? You apparently have a cron job with a typo in it. Instead of running ntpq each hour, it is running ntpd. Those command line arguments are for ntpq, not ntpd. On 07/02/13 05:43, bunty21.tiw...@gmail.com wrote: Not helping.Is there any other issue..we are struggling since long. On Friday, June 28, 2013 9:52:47 PM UTC+5:30, bunty21...@gmail.com wrote: Hi We are using cloud based Red hat 5.5 Tikanga OS. After installing the ntp (ntp-4.2.2p1-15.el5_7.1 and starting the ntpd process I can see multiple processes are running. I can see processesare adding after every hour, Below is a snapshot, [root@sandbox2 subsys]# ps -eaf | grep ntpd ntp 25589 1 0 15:05 ?00:00:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g root 30021 1 0 16:00 ?00:00:00 /sbin/ntpd -c 'timeout 1000' -c sysinfo -c sysstats -c peers Syslogs are as below, Jun 28 16:00:01 sandbox2 ntpd[30017]: ntpd 4.2.2p1@1.1570-o Tue Oct 25 12:54:50 UTC 2011 (1) Jun 28 16:00:01 sandbox2 ntpd[30021]: precision = 4.000 usec Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 2, port 123, addr 0.0.0.0, in_classd=0 flags=9 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 10, port 123, scope 0, addr ::, in6_is_addr_multicast=0 flags=1 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 10, port 123, scope 0, addr ::1, in6_is_addr_multicast=0 flags=1 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 10, port 123, scope 3, addr fe80::be76:4eff:fe10:11f8, in6_is_addr_multicast=0 flags=1 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 10, port 123, scope 0, addr 2001:4801:7817:72:6a3e:ad9:ff10:18e4, in6_is_addr_multicast=0 flags=1 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 10, port 123, scope 2, addr fe80::be76:4eff:fe10:18e4, in6_is_addr_multicast=0 flags=1 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 2, port 123, addr 127.0.0.1, in_classd=0 flags=5 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 2, port 123, addr 198.61.168.154, in_classd=0 flags=25 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 2, port 123, addr 10.177.8.134, in_classd=0 flags=25 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: kernel time sync status 0040 Jun 28 16:00:01 sandbox2 ntpd[30021]: getconfig: Couldn't open peers --Thanks ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd is spawning multiple processes
You apparently have a cron job with a typo in it. Instead of running ntpq each hour, it is running ntpd. Those command line arguments are for ntpq, not ntpd. On 6/28/2013 12:22 PM, bunty21.tiw...@gmail.com wrote: Hi We are using cloud based Red hat 5.5 Tikanga OS. After installing the ntp (ntp-4.2.2p1-15.el5_7.1 and starting the ntpd process I can see multiple processes are running. I can see processesare adding after every hour, Below is a snapshot, [root@sandbox2 subsys]# ps -eaf | grep ntpd ntp 25589 1 0 15:05 ?00:00:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g root 30021 1 0 16:00 ?00:00:00 /sbin/ntpd -c 'timeout 1000' -c sysinfo -c sysstats -c peers Syslogs are as below, Jun 28 16:00:01 sandbox2 ntpd[30017]: ntpd 4.2.2p1@1.1570-o Tue Oct 25 12:54:50 UTC 2011 (1) Jun 28 16:00:01 sandbox2 ntpd[30021]: precision = 4.000 usec Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 2, port 123, addr 0.0.0.0, in_classd=0 flags=9 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 10, port 123, scope 0, addr ::, in6_is_addr_multicast=0 flags=1 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 10, port 123, scope 0, addr ::1, in6_is_addr_multicast=0 flags=1 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 10, port 123, scope 3, addr fe80::be76:4eff:fe10:11f8, in6_is_addr_multicast=0 flags=1 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 10, port 123, scope 0, addr 2001:4801:7817:72:6a3e:ad9:ff10:18e4, in6_is_addr_multicast=0 flags=1 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 10, port 123, scope 2, addr fe80::be76:4eff:fe10:18e4, in6_is_addr_multicast=0 flags=1 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 2, port 123, addr 127.0.0.1, in_classd=0 flags=5 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 2, port 123, addr 198.61.168.154, in_classd=0 flags=25 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: bind() fd 16, family 2, port 123, addr 10.177.8.134, in_classd=0 flags=25 fails: Address already in use Jun 28 16:00:01 sandbox2 ntpd[30021]: kernel time sync status 0040 Jun 28 16:00:01 sandbox2 ntpd[30021]: getconfig: Couldn't open peers --Thanks ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] what is the meaning of dash in the type field of ntpq -p output?
A long standing question that I have been asked is what is the mean of a dask (-) in the type field of the output of ntpq -p. The type field is decoded from the destination address. Here is the code that determines the type: ch = (char)(((dummy0xf000)==0xe000) ? 'm' : ((dummy0x00ff)==0x00ff) ? 'b' : ((dummy0x)==0x7f01) ? 'l' : ((dummy0xffe0)==0x) ? '-' : 'u'); From this we can see that if the first octet of the IP is 224, then it is mutlicast. If the last octet is 255, then it is boradcast. If it is 127.0.0.1 then is it is localhost. If everything except the last 5 bits are zero, then it is the dash. And if it isn't any of these, then it is unicast. Of course, all of these definitions have problems, but I am totally flummoxed by the - test. I can't figure out what it is trying to find at all. Any ideas? -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] time to sync vs ptp?
There was a bug in the start up of NTP that caused it to set the frequency before setting the first offset. This meant that the kernel PLL treated the first offset correction as a drift in time since the time the frequency was set (seconds before) which introduced a sudden jerk to the loop, which, depending on the circumstances, might send it careening off the mark. I reported this as bug 1044. I believe that the fix for bug 1981 may have fixed this, but I have not verified it yet. On 5/31/2013 11:49 AM, Rob wrote: matthew.gar...@gmail.com matthew.gar...@gmail.com wrote: On Thursday, May 30, 2013 2:21:15 PM UTC-5, Rob wrote: I have a server running NTP 4.2.2 (as part of the RedHat 5.7 release). Last night I changed it's /etc/ntp.conf file, specifically the server xyz line to point to a new NTP server. After doing this, the clock's offset was *increasing* after an hour. Offset is measured by ntpdate -q peer. This is a wellknown problem. When you do a couple of ntpd shutdown/restarts e.g. because you a experimenting with different server configurations, the combination of ntpd and the kernel goes haywire and it will actually steer the time the wrong way. Just wait a day or so, and it will have solved itself. Would it be possible to provide a link or point me to some reference material where I can read more about this issue? I think the issue is never acknowledged by the author. He believes his system is proven to be stable. It is only in practice that we see this happen, it cannot happen in theory. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] client configuration: it's sufficient 3 servers ?
On 5/24/2013 5:27 AM, Rob wrote: claim that 2 servers is not good because they may have different time and you will not be able to tell which one is right, but in a correctly configured ntp server it will normally not happen that it serves wrong time without noticing it. You are missing the point that it is not the case that two different servers may have different time, it is the case that they *will* have different time. The only question is by how much. Obviously, the closer together they are, the less the impact will be. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] client configuration: it's sufficient 3 servers ?
Peering them is a good idea, but isn't going to help, since they will each view the other as being of a higher stratum then their upstream servers. On 5/24/2013 10:30 AM, Rob wrote: Brian Utterback brian.utterb...@oracle.com wrote: On 5/24/2013 5:27 AM, Rob wrote: claim that 2 servers is not good because they may have different time and you will not be able to tell which one is right, but in a correctly configured ntp server it will normally not happen that it serves wrong time without noticing it. You are missing the point that it is not the case that two different servers may have different time, it is the case that they *will* have different time. The only question is by how much. Obviously, the closer together they are, the less the impact will be. These are two servers within an organization. They can be interconnected with a peer line. They should be closely together until one or both of them get unsynchronized, which the clients will notice. Of course, with a LOCAL clock they will remain synchronized to LOCAL and they can drift away from real time. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Offset is always increasing
questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] symmetric active while configurion uses server mode, RFC compliant or not?
Okay, that looks really weird. Just the rate of the packets seems very off, only 10s of milliseconds between packets. The system whose IP address ends in b900::1:1 doesn't like it. The second packet it sends is a KOD packet that is complaining about the high rate of packets, and then it shuts down and refuses to respond anymore. Packets 2 and 3 of the trace are the same packet, but with the hop count decremented from 56 to 51. Actually, on closer inspection, of the 24 packets in the trace transmitted by 823d:1b13, they are all duplicates of only two packets. The same two packets are looping around your network, with the hop count going down by 5 each time, until they hit zero and are dropped. Now, I grant that which ones are sending client, server, and symmetric active and symmetric passive is odd, but until you fix the looping, there is no telling what is causing that. It might be an artifact of the looping. On 5/19/2013 5:28 AM, Joe the Shmoe wrote: On 18/05/2013 20:10, Brian Utterback wrote: On 5/18/2013 3:14 AM, Joe the Shmoe wrote: [...] This is non-intuitive and arguably incorrect according to the RFC, but it is the programmed behavior. There was a time when all Windows clients used symmetric active mode, so to work around that ntpd with nopeer configured responded with symmetric active mode packets but did not mobilize the association. I don't know if they still use symmetric active by default. Perhaps this should be revisited. Thank you for your explanations. I now understand the reason. Having made some tests after my question here, there is effectively a difference with a real symmetric passive which is shown by the 'peer' command of ntpdc or ntpq (= an association is mobilized?), while here hopefully that sort of faked symmetric exchanges on network side, do not show with that same command. I guess, one cannot introduce false time information to my server that way, if for example, the symmetric client spoofs a stratum 1 server. - Other symmetric active requests come from the server itself toward one of the 5 configured hosts. But the server only makes use of server in the configuration (no peer statement). This occurs after a first NTP client request to that configured host which get answered by two NTP server from the configured host. Can you post the traces? I am not sure I follow. An extract of such NTP exchanges (wireshark capture) is available at: ftp host: edrusb.is-a-geek.org login: nobody password: ntp Brian. Regards, Joe. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] symmetric active while configurion uses server mode, RFC compliant or not?
On 5/18/2013 3:14 AM, Joe the Shmoe wrote: Zooming on these I see two types of requests: - received symmetric active from unconfigured hosts, which get answered by symmetric passive from my host. Here the point I do not understand is that the NTP server is configured in a way to Deny packets that might mobilize an association unless authenticated. Shouldn't the server ignore the request rather than answering them by a symmetric passive message? This is non-intuitive and arguably incorrect according to the RFC, but it is the programmed behavior. There was a time when all Windows clients used symmetric active mode, so to work around that ntpd with nopeer configured responded with symmetric active mode packets but did not mobilize the association. I don't know if they still use symmetric active by default. Perhaps this should be revisited. - Other symmetric active requests come from the server itself toward one of the 5 configured hosts. But the server only makes use of server in the configuration (no peer statement). This occurs after a first NTP client request to that configured host which get answered by two NTP server from the configured host. Can you post the traces? I am not sure I follow. Brian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp system without a rtc
I just tried it on my system, I get sync in 12 seconds. Now, of course getting the frequency correction right will take a lot longer, and it may lose sync in the mean time if the frequency is far enough off. On 05/14/13 02:59, David Woolley wrote: Richard B. Gilbert wrote: NTPD is NOT designed for fast convergence. From start up to get the minutes correct, NTPD will need about thirty minutes! To get the best time you are going to get, you will need to wait for about ten hours! Convergence to within 128ms should take a lot less than that. With iburst, I believe it should be less than one minute. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP servers in INIT state
On 4/23/2013 4:50 PM, Lakshmi Kuruganti wrote: Hi all, Our NTP peers are showing up in INIT state on solaris11. . ntpq -p remote refid st t when poll reach delay offset jitter == nycron .INIT. 16 u- 6400.0000.000 0.000 nycron .INIT. 16 u- 6400.0000.000 0.000 rrcron .INIT. 16 u- 6400.0000.000 0.000 rrcron .INIT. 16 u- 6400.0000.000 0.000 . I did a bit of troubleshooting and i think we are coming across authentication issue. . ntpq rv 13479 associd=13479 status=8011 conf, sel_reject, 1 event, mobilize, . CodeMessageTDescription 0sel_reject discarded as not valid (TEST10-TEST13) . from man page.. 0x200 TEST10 The autokey protocol has detected an authentication failure. See the Authentication Options page. 0x400 TEST11 The autokey protocol has not verified the server or peer is proventic and has valid public key credentials. See the Authentication Options page. 0x800 TEST12 A protocol or configuration error has occurred in the public key algorithms or a possible intrusion event has been detected. See the Authentication Options page. I am not seeing any key files for NTP on solairs, any help is highly appreciated. I suspect that the code in this case is not valid. It is probably set to zero because no packet has ever been received from the server. Please email me directly, I think I may have some information about your issue. Brian Utterback br...@utterback.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpd 4.2.6p5 will not synchronize to broadcast servers
I think this is a duplicate of bug 629. On 4/24/2013 9:54 PM, Harlan Stenn wrote: Gary, The short answer is I don't know. I believe we have successfully used broadcast clients in 4.2.6. Please see if ntp-dev works for you though - if there is a problem there we want to fix that before releasing 4.2.8. And having written the above: http://bugs.ntp.org/show_bug.cgi?id=2261 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntpdate function
On 04/15/13 12:48, unruh wrote: On 2013-04-15, Jacek Igalson jacek.igalson wrote: In fact, I have used offset, delay is recorded by the way. It indicates how asymmetric might be the trip. No. It says nothing about the asymmetry. Just about the delay. Now you might make the assumption that a longer delay is probably a delay in only one leg of the path, implying asymmetry (which is what ntpd does in its clock filter algorithm) and that might often be a reasonable assumption, expecially if the delay is is say twice as long as usual, it is often a very bad assumption for slightly longer delays. That was my first reaction when I read it. But I think that what he is saying is that delay tells you the *maximum* error that can be introduced by asymmetry. If the path were completely symmetric the value of delay would not matter. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] dispersion has high peak when reference clock first appears
On 04/08/13 08:03, Nickolay Orekhov wrote: Hello! I've got external util that estimates quality of synchronization. One of the clues that it uses is current sys peer dispersion. When clock goes down for a long period of time it's dispersion filter gets filled with MAXDISPERSE ( 16.0 ) And than there's a peak dispersion when clock goes up again and get's selected. In general I don't think that's logical. Because I have very good synchronization with low self dispersion and than there will be a peak just because some clock appeared from nowhere. I'm thinking about some additional code. For example, one can delay clock selection until all filter will be filled with good dispersion, which is not equal to MAXDISPERSE. It will smooth the moment of clock appearance. That's pretty much how it works now. The dispersion is calculated using all 8 pieces of polling data in the billboard. If a clock has been off the air too long, all of the data regarding the clock times out or is cleared and the billboard doesn't have any polled data for the clock and the dispersion is calculated as the max for all eight pieces of data. As each new piece of polling data is entered the dispersion is re-calculated and because the data is weighted by age each piece of data has the effect of approximately reducing the dispersion by half. But ntpd will not select a clock with dispersion over one second. This is the main reason that iburst was created, to allow the billboard to be filled quickly with valid data, reducing the dispersion below one second and allowing the clock to be selected. Before iburst you had to wait for 5 polling periods. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] high jitter on serial gps causes big time offsets
On 04/08/13 07:50, Nickolay Orekhov wrote: No I'm not a gps developer. Imagine that I've got very precise time according to GPS+PPS for a long period. After that GPS and PPS quality goes low and than quality of GPS serial high jitter clock will appear before low jitter PPS. Before selecting PPS, ntpd will do some adjustments according to GPS. And my highly disciplined time will be spoiled. When ntpd will switch to PPS my time will be disciplined again but there will be noticable period of time when GPS will spoil my local clock discipline and maybe frequency. That is the problem. I don't want ntpd to do small adjustments according to GPS serial that will spoil local clock. I just want to do steps according to GPS and do adjustments according to PPS. Isn't the GPS providing the PPS as well? Are you saying that the PPS pulse is stopped being sent while the GPS sentences continue, without there being an indication in sentence that the time is invalid? There is no such thing of a poor quality PPS as far as NTP is concerned, the pulse is either there or it is not. Usually if you are using PPS ntpd is not even responsible for applying the offset corrections determined from the PPS. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Extracting ntpq like information programmatically
On 3/29/2013 1:26 PM, Claudio Carbone wrote: I mean that, when I have certain timings from different machines, if I correct them by their average offset from a common source, doesn't this augment the precision of the measure? I'm using a single external source to compare all other clocks. In a word, no. How do you determine their average offset? You can use their own estimate of that (which is what ntpq does) but taking the average is not adding any precision since NTP is already correcting for the offset it measures. You can measure the offset relative to the system making the test (say by running ntpdate), but then you are introducing a new source of error so it doesn't help you. As unruh said, if there was a way to improve the accuracy of the measurement over the network like that, NTP would already be doing it. Brian Utterback. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Extracting ntpq like information programmatically
On 03/29/13 15:27, Claudio Carbone wrote: On 29/03/13 19:26, Brian Utterback wrote: As unruh said, if there was a way to improve the accuracy of the measurement over the network like that, NTP would already be doing it. If so why doesn't the offset oscillate? If NTP were a real compensation system, it should oscillate around the setpoint. Instead I noticed a nearly static offset, at least during the 15 minutes observation time. This has to do with another reason that taking the average offset doesn't help. Each data point has its own error possible as determined by the round trip time of the polling process. For instance, if the round trip time were 1ns, then we know that the calculated offset between the clocks can not be in error by more than 1ns. But if it were 1 minute, then we can only say that the calculated offset is within 1 minute of the actual offset. There are some tricks that NTP uses to eliminate the processing time from the trip time, and the result is called the delay in the ntpq output. But it sets a maximum error in calculating the offset between a system and the server. So, what NTP does is store the last 8 polls and uses the poll that has the smallest delay since it is more likely to be more accurate. There is some weighting going on too, so that polls grow stale over time by adding a age based correction. But if you get a single poll that has a much shorter round trip time than usual, that same offset may end up being displayed for several poll periods, until it either falls off the end, one with a smaller delay comes along or the correction for its age means that another poll is better. You need to remember that the output of ntpq -p does not represent the clock offsets as it is now, it represents the clock offset relative to a particular server, as it was calculated and selected at the time of the last poll to that server. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] outlyer / falseticker
Okay, it can be a little obtuse, especially if you don't know the references. The two specific references that are being used here are the reality television show Survivor and The Byzantine Generals Problem, an algorithm for detecting misbehaving parts of a system, in this case an NTP server. Comments inline: On 3/7/2013 7:22 AM, folkert wrote: Ok. While reading through the source, I encountered a lot of unusual comments: * Initially, we populate the island with all the rifraff peers rifraff? Riff Raff: disreputable person. This is saying initially use all of the candidate servers, no matter how good or bad they appear. * that happen to be lying around. Those with seriously * defective clocks are immediately booted off the island. Then, * the falsetickers are culled and put to sea. The truechimers cullend and put to sea? Seriously defective means not selectable because either the server is not in sync or the root sync distance is too large, or it doesn't meet administrative criteria (stratum too low, too high, configured noselect, or makes a sync loop). The algorithm takes what is left and looks for false tickers. This is a little tricky to describe in English, but it essentially looks at the offset and error bars from all the remaining servers and determines a consensus interval in which the true offset lies. A falseticker is any server with an offset that does not lie within that interval. If a server is tagged as a falseticker, it is removed from further consideration, which is the what culled and put to sea means in this case. * remaining are subject to repeated rounds where the most * unpopular at each round is kicked off. When the population * has dwindled to sys_minclock, the survivors split a million * bucks and collectively crank the chimes. split a million bucks? This is where the Byzantine General solution comes into play. We repeatedly try to narrow the consensus interval of the remaining servers until we get the smallest possible interval. All servers with offsets in the smallest interval are candidates for selection. It is possible that there is no consensus and it is not possible choose a server that has any better likelihood of being correct than any other and they do not agree, which leads us to the next comment. * candidates, the Albanians have won the Byzantine wars and * correct synchronization is not possible. byzantine wars? The Byzantine Generals Problem is based on an allegory with the problems the generals in the Byzantine empire had fighting the Albanians. This comment is saying if there is no consensus among the Byzantine generals, then they cannot act and Albania wins the war. That is, no servers are selectable. After that there is more culling of the rest, using jitter and distance to find the best quality of time of the remaining servers. And then the weighting algorithm may come into play to get the final offset used. Servers culled at this point at marked as Excess, since they had good time, but the culling continues until there are only sys_minclock servers left. Hope that make it more clear. Brian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] multiple instances of NTP on different interfaces
On 3/5/2013 11:25 PM, Abu Abdullah wrote: On Tue, Mar 5, 2013 at 11:18 PM, Brian Utterback brian.utterb...@oracle.com mailto:brian.utterb...@oracle.com wrote: Based on what is being requested, I can suggest one way to accomplish it, but it involves using an OS feature, rather than using an NTP feature. If it is feasible to run Oracle Solaris on the system in question, you could use the Solaris Zones feature to do what you want. You could have one instance of ntpd running in one zone with one set of interfaces which controls the system clock and have another instance in a separate zone configured with the other set of interfaces configured with the LOCAL refclock only so it never tries to change the clock, but will instead serve time only. There is an interlock mechanism in the ntpd configuration on Solaris to prevent ntpd from running in a zone but there is an override to the interlock if you really want to do it and you know what you are doing. Just a thought. Thanks Bria, we are using RedHat so I think the equivalent is KVM but right now I'm trying to find if there is an easier way. Zones are easier to use and lighter weight than KVM (single kernel image with zones), but if you need to use Red Hat then the KVM may be the closest equivalent. Brian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] multiple instances of NTP on different interfaces
Based on what is being requested, I can suggest one way to accomplish it, but it involves using an OS feature, rather than using an NTP feature. If it is feasible to run Oracle Solaris on the system in question, you could use the Solaris Zones feature to do what you want. You could have one instance of ntpd running in one zone with one set of interfaces which controls the system clock and have another instance in a separate zone configured with the other set of interfaces configured with the LOCAL refclock only so it never tries to change the clock, but will instead serve time only. There is an interlock mechanism in the ntpd configuration on Solaris to prevent ntpd from running in a zone but there is an override to the interlock if you really want to do it and you know what you are doing. Just a thought. On 3/5/2013 1:07 PM, Abu Abdullah wrote: each with different interface. I want to have instance for each network. Why? mentioned it before We have a requirement for NTP service for two different networks: public (not important, can have outages), private (important). we are trying to have separate process for each network in case high load come from the public domain (or for any security issue). We will have more control on the public NTP where we can set the resources for it at the OS level. in addition, at any point of time we can migrate the private NTP to a dedicated machine (currently we have only one machine) once the hardware is not capable to handle both. In this case we will not have to change the NTP IPs in the clients configurations (private). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP architecture with virtual machines for stratum-2 ?
On 3/4/2013 3:20 PM, unruh wrote: Should our stratum-2 servers all be connected to ntp1-4, or is it better to have server1-ntp1, server2-ntp2, etc.. to make sure they don't all run off the same clock source? i.e. should we for server1 have ntp.conf with: If source a gives good time, why should you worry about many machines using it? The only purpose could be redundancy, and that you get by having many servers, not by pointing them at different sources. At some level you will need to mix the sources, so it doesn't really matter where that occurs. The higher up the tree that mixing happens the easier to diagnose it will generally be. It is a good idea to have multiple ultimate time sources, because individual vendors have been know to have glitches. Try not to rely on any one tech overly much, otherwise ifg there is a glitch it my override the other, correct, servers. Brian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS only configuration
On 2/22/2013 1:36 AM, unruh wrote: On 2013-02-22, Brian Utterback brian.utterb...@oracle.com wrote: On 2/21/2013 7:00 PM, unruh wrote: Note that rmc 5322 is 2008. Many of the news readers are older than that. Another reason to refer to the RFC I quoted, which dates back to the 90's. So, it would appear that is the poster uses format=flowed test, then your reader should handle it. But if someone is using just text/plain, then they should break the lines at a reasonable place. No. If the person wants his post to be easily readable by as many people as possible, he breaks his lines. If he does not care if people read his posts, or wants to make a point about line lengths, then he can do whatever he wants. Yes, but as we have seen from the RFC, the sender's software should take care of that on sending (if using flowed) and the reader's software should take care of it on reading, even if the sender has not (again if using flowed). The point is that if you are using flowed format, inserting CR at the end of each line defeats the purpose. Software that mixes these modes makes it difficult for everyone. For instance, input text fields in HTML forms often wrap the lines on input when you reach the margin of the field, but do not insert an actual CR, so that when the entered text is viewed on a resulting HTML page, it might end up as one long line. Inserting CR's at the end of the line on input each time the words wrap is a huge pain since you can't tell if it was your CR or the auto-wrap that caused the linefeed, and doesn't help if the input field is of a different width from the output field anyway. All of the above was entered with no CRs except the one at the end that signaled a new paragraph. You probably see this okay because my mailer will follow the RFC I quoted and limit the line lengths anyway. But that is a should, not a must. Even if it did not, anyone viewing it with a conformant reader would still see it as multiple lines. However, if I were to insert the CRs at each line as you suggest then it would no longer look right for those using conformant readers. Of course, that only applies if the format is flowed. If it is text/plain without that format, then the CRs are necessary, with the disadvantages noted in the RFC. That's why they created flowed in the first place. But making this a little more tricky, it isn't like I chose flowed anywhere, my software did it without my knowledge. And in the end, that is kind of what we expect from our software, to do the right thing. Brian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS only configuration
Hate to get into a religious war here, but there is a hard, factual standard here. RFC2646 which defines the MIME type text/plain format parameter. If you are reading a message with content type text/plain and format set to flowed, and a non-quoted line of words appears that is too long (for various values of too long, mostly between 60 and 80 characters or wider than your screen) then the problem is with the reader you are using. Period. I note that the message above with the 1500 character line of text is content type text/plain with format flowed. Brian Utterback. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS only configuration
Having said that, I note that Ed Mischanko's mailer is not sending text/plain flowed. So unruh has a point in that case. On 2/21/2013 8:38 AM, Brian Utterback wrote: Hate to get into a religious war here, but there is a hard, factual standard here. RFC2646 which defines the MIME type text/plain format parameter. If you are reading a message with content type text/plain and format set to flowed, and a non-quoted line of words appears that is too long (for various values of too long, mostly between 60 and 80 characters or wider than your screen) then the problem is with the reader you are using. Period. I note that the message above with the 1500 character line of text is content type text/plain with format flowed. Brian Utterback. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS only configuration
I know that it is an RFC, but it does say that it is standards track and there doesn't seem to be a full standard already that covers the same info. However, STD11 is not helpful in this argument. It is not covering the presentation of the message, only its transport. I don't believe that unruh is saying that his mailer cannot handle the long lines, he is saying that his mailer displays long lines on the screen as long lines. The RFC I referred to also is basically talking about the transport format of the message, but does address how they should be presented on screen as well. Now, if you don't like RFC2646, you might say it's not a standard and that you won't follow it, but I don't think you should get a lot of sympathy, just as if you decided that you were going to ignore RFC 1305 because it isn't a standard. On 2/21/2013 1:08 PM, Mike S wrote: On 2/21/2013 8:52 AM, Brian Utterback wrote: Having said that, I note that Ed Mischanko's mailer is not sending text/plain flowed. So unruh has a point in that case. On 2/21/2013 8:38 AM, Brian Utterback wrote: Hate to get into a religious war here, but there is a hard, factual standard here. RFC2646 which defines the MIME type text/plain format parameter. RFC2646 isn't a standard. It's an RFC, just like RFC1149. The standard is STD11 (from RFC822). It places no restriction on the length of lines in the body. The planned replacement (draft standard) is RFC5322, which is quite clear that an MUA which can't handle long lines is non-conformant. 2.1.1. Line Length Limits There are two limits that this specification places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. The 998 character limit is due to limitations in many implementations that send, receive, or store IMF messages which simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations that (in compliance with the transport requirements of [RFC5321]) do not accept messages containing more than 1000 characters including the CR and LF per line, it is important for implementations not to create such messages. The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification (and that of [RFC5321] if they actually cause information to be lost). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS only configuration
On 02/21/13 14:45, E-Mail Sent to this address will be added to the BlackLists wrote: Brian Utterback wrote: RFC2646 Obsoleted by RFC3676 Missed that because they changed the title. However, the new RFC doesn't change the behavior I was referring to. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS only configuration
On 2/21/2013 7:00 PM, unruh wrote: Note that rmc 5322 is 2008. Many of the news readers are older than that. Another reason to refer to the RFC I quoted, which dates back to the 90's. So, it would appear that is the poster uses format=flowed test, then your reader should handle it. But if someone is using just text/plain, then they should break the lines at a reasonable place. Brian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS only configuration
You can't. The PPS feature can only use offsets up to .5 seconds. If the offset is greater than .5 the PPS will synchronize your system to the wrong second. In essence the PPS just locks the clock to the nearest second. So NTP PPS is designed to require another source of time and then on let the PPS kick in when the offset is below .5 seconds. If you circumvent that requirement, you run the rather high risk of being some integer multiple of seconds offset from the real time. On 01/15/13 13:48, Edward T. Mischanko wrote: How do I configure NTPD so that only the PPS offset is used to figure the clock offset, instead of factoring in the surviving back-up servers that have bigger offsets? I only want the back-up servers to come into play when, or if, the PPS fails. # enable pps enable kernel enable ntp tos minclock 4 tos minsane 3 tinker huffpuff 7200 # driftfile /var/db/ntpd.drift leapfile /usr/home/ed/leap-seconds # enable stats statistics loopstats statsdir /usr/home/ed filegen loopstats file loop type day # server 127.127.20.0 mode 18 minpoll 3 prefer fudge 127.127.20.0 time2 0.374000 server 127.127.22.0 minpoll 3 fudge 127.127.22.0 flag2 0 flag3 1 server 192.168.1.254 iburst minpoll 6 maxpoll 6 server tick.cerias.purdue.edu iburst minpoll 6 maxpoll 6 server tock.cerias.purdue.edu iburst minpoll 6 maxpoll 6 server tack.cerias.purdue.edu iburst minpoll 6 maxpoll 6 server nist1-chi.ustiming.org iburst minpoll 6 maxpoll 6 server nist.expertsmi.com iburst minpoll 6 maxpoll 6 server nist.netservicesgroup.com iburst minpoll 6 maxpoll 6 server ntp.your.org iburst minpoll 6 maxpoll 6 server navobs1.wustl.edu iburst minpoll 6 maxpoll 6 server utcnist2.colorado.edu iburst minpoll 6 maxpoll 6 server time-a.timefreq.bldrdoc.gov iburst minpoll 6 maxpoll 6 server ntp1.conectiv.com iburst minpoll 6 maxpoll 6 server east-pool.ustiming.org iburst minpoll 6 maxpoll 6 # ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] how to configure ntp for conditional use of servers, depending on my LAN status?
You don't need to have the info in config 1, there is no point. If you are not on a network then ntp doesn't have any clients and you don't want it changing the clock. The cleanest way to do the other two is to have two separate config files and restart ntpd with the correct config file depending on the network topology at the time. However, you could just configure all the servers. The ntpd process will try to resolve the server names and will continue trying to do so periodically until it succeeds. It will then try to send packets periodically until it succeeds. So, when you are not on the right network the packets will just not get there. On 1/9/2013 2:21 PM, dar8...@eml.cc wrote: hi, i'm running ntp-4.2.6p5-3.10.1.x86_64 on linux/64. i've a question about proper configuration/use of fallback on a roaming laptop. the laptop boots to a no-network configuration. connection is chosen/enabled as needed after KDE desktop launch ... i'd like to configure ntpd.conf so that (1) at machine boot, ntp starts up using the machine's local time, in the absence of network access. i think i'd use this: server 127.127.1.0 fudge 127.127.1.0 stratum 10 (2) once network connection is made, if my IP is on my local LAN (10.10.50.0/24), then use my local LAN's time server. for that, server ntp-server-f.q.d.n iburst prefer restrict ntp-server-f.q.d.n (3) if my IP is not on my LANB, then use some external servers. e.g., server clock.isc.org iburst prefer restrict clock.isc.org server ntp1.sf-bay.org iburst restrict ntp1.sf-bay.org i'm not sure if/how to implement this conditional fallback 'logic' for ntp's server selection. reading the docs, i think stratum can be used -- but really am not certain. thought i should check before abusing some servers inadvertently. any guidance would be appreicated! thanks, daryl ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP client syncs successfully with NTP server within local network but not with the NTP pool servers
On 1/9/2013 12:41 AM, Arpith Nayak wrote: Adding my .conf file: driftfile /tmp/ntp.drift/ server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server 3.pool.ntp.org Adding ntpq -p data: [Thu Feb 10 12:55:51 root@root-ubuntu:~]# ntpq -p 0.pool.ntp.org remote refid st t when poll reach delay offset jitter == *64.147.116.229 .ACTS. 1 u 151 1024 3772.439 -0.632 0.052 +131.107.13.100 .ACTS. 1 u 879 1024 377 27.8531.041 0.539 -time.nrc.ca 132.246.11.231 2 u 989 1024 377 86.821 -4.132 8.778 -time1.chu.nrc.c 209.87.233.522 u 53 1024 377 109.2213.153 9.377 +dense.utcc.utor 128.100.200.166 2 u 88 1024 377 64.115 -1.841 0.454 -dns4.utoronto.c 128.100.103.253 2 u 167 1024 377 65.252 -43.422 56.093 ___ Of much greater use would be ntpq -p from the system having the problem. Is ntpd still running on that system or has it exited. If it has exited, you should check the syslog for any messages. If it hasn't the ntpq output would be the next step to seeing what is happening. By the way, the output of ntpq -p 0.pool.ntp.org isn't very useful for another reason. Since this is a roundrobin DNS address, there isn't any guarantee that it is even the same system that the ntpd process is using. Brian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] How to establish a public timeserver on linux? (ntp.conf)
On 12/26/12 08:05, Michael Tatarinov wrote: 2012/12/26, David Woolleydavid@ex.djwhome.demon.invalid: joerg.wieg...@googlemail.com wrote: what are the right settings in ntp.conf to allow public access? A sufficient condition would be the lack of any restrict lines. Not always. It's my config: restrict default kod limited nomodify nopeer notrap nomrulist restrict 127.0.0.1 restrict ::1 ___ Which is of course why David didn't say a necessary and sufficient condition. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A proposal to use NIC launch time support to improve NTP
On 12/20/2012 6:25 AM, Ulf Samuelsson wrote: Yes there is. The ntpd program has to set a timestamp in the outgoing packet and then specify the launchtime when it writes the packet. The goal here is to have the timestamp written in the packet exactly match the time the packet actually hits the wire. So, the timestamp in the packet must be a little in the future when it is written so that by the time the controller gets it the packet can be delayed until the right time. Since ntpd cannot access the clock in the controller, The Network controller will timestamp the message in H/W as it arrives and will add a CMESG with the timestamp, and this is supported in ntpd since some time. You add a small delay to the receive timestamp to make your launchtime. systime does not get involved at any stage, and can be way off. (Note that I am only interested in Stratum 1 server functionality) You have to guarantee that the actual processing delay from controller to controller is never more than .5 seconds minus your small delay, otherwise the timestamp will be off. It would be a good idea to synchronize the system clock so that you can detect that kind of situation. Also, if you are only going to be a stratum 1 server, from where are you going to get the actual time? If you are only going to use the controller timestamps then the controller better be disciplined to some source of time. Some how something needs to be setting the time on the controller. Brian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A proposal to use NIC launch time support to improve NTP
On 12/18/2012 7:05 PM, Ulf Samuelsson wrote: Brian Utterback brian.utterb...@oracle.com wrote: On 12/13/2012 5:00 AM, Jonatan Walck wrote: This is going to be very hard to get it to be useful. Looking at the specs for the card, the timestamp you give is relative to a clock that is internal to the controller, and is only accurate to the nearest second. That is, it is like the PPS in that it is assumed that the clock is in sync to within .5 seconds to avoid aliasing the timestamp. Brian. The internal clock of the network controller is the PHC for IEEE1588, it has a 1 ns resolution, and can be steered with a 32 bit fractional of 1 ns. see SYSTIML and TIMINCA in the I210 datasheet. // jwalck I know that. The problem is that there is going to be jitter introduced when you set the clock from the kernel. That is generally the problem with IEEE 1588, getting the time from the controller to the kernel and vice versa. If you have to go across a PCI bus for instance that will introduce jitter. Brian No, you capture the time for the 1 PPS pulse in the network controller. Then you tweak the count rate of the timestamp counter up or down. Eventually you will have synchronized the timestamp counter with the 1 PPS pulse, If you run the network contoller from a clocksource derived from the Cesium clock You should get within a few ns from the pulse, It is an inconvenient approach since you can easily synch your timestamp with a 1 PPS pulse using a few counters if you understand the issue. Unfortunately, those counters are not available in the Intel chips, so we have to use it they way they want us to use it. Since launch time will be the arrival time of the client request (through H/W timestamping) + a constant delay, any delays in the PCIe bus will not affect the precision. You just have to make sure that the constant delay added, is longer than the processing time inside the server. No, you are missing the point. You have two clocks in this scenario, the kernel clock and the network controller clock. If one gets a good time then you have to set the other from it. This means that this time will have to travel over the PCI bus which will introduce jitter. Now, if you have a PPS signal available and can provide it to both the network controller and the kernel, then you don't have this problem since the PPS signal will sync the time to an accuracy better than the jitter that was introduced. Even without the PPS signal to the kernel, your system might be usable, since the only timestamp used in the kernel will be for the originate/transmit timestamp, and this timestamp will be in sync with the the network controller timestamp by virtue of the use of launchtime. But you will have to be sure that the kernel clock is always a little ahead of the network controller clock, enough so that the actual delay in the stack doesn't cause the packet to reach the controller after the designated launchtime, but not so far ahead that the timestamp wraps (i.e. .5 second). Also, not so far ahead that you get too large a back log in the controller of packets waiting to be sent. Of course, this also all depends on the controller providing receive timestamps as well. Otherwise you will replace jitter with systematic asymmetric delays, which are worse. Brian ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A proposal to use NIC launch time support to improve NTP
On 12/19/12 10:12, Ulf Samuelsson wrote: Now, if you have a PPS signal available and can provide it to both the network controller and the kernel, then you don't have this problem since the PPS signal will sync the time to an accuracy better than the jitter that was introduced. Even without the PPS signal to the kernel, your system might be usable, since the only timestamp used in the kernel will be for the originate/transmit timestamp, and this timestamp will be in sync with the the network controller timestamp by virtue of the use of launchtime. But you will have to be sure that the kernel clock is always a little ahead of the network controller clock, enough so that the actual delay in the stack doesn't cause the packet to reach the controller after the designated launchtime, but not so far ahead that the timestamp wraps (i.e. .5 second). Also, not so far ahead that you get too large a back log in the controller of packets waiting to be sent The desired launchtime is compared to the network controller timestamp counter in H/W, so again there is no need to synchronize with the system time. Yes there is. The ntpd program has to set a timestamp in the outgoing packet and then specify the launchtime when it writes the packet. The goal here is to have the timestamp written in the packet exactly match the time the packet actually hits the wire. So, the timestamp in the packet must be a little in the future when it is written so that by the time the controller gets it the packet can be delayed until the right time. Since ntpd cannot access the clock in the controller, this requires that the kernel time be relatively close to the controller time. If you can guarantee that they agree to within some upper bound and then add that maximum error to the timestamp written to packet, plus the maximum delay in the stack, then your scheme should work anyway. The key is, what is that maximum error and delay? If they get too close to .25 seconds then it will fail because of the timestamp wrap restrictions of the launchtime register. So you are dependent on how accurately you can synchronize the kernel and network controller's clocks. But I think that the required tolerance should easily be obtainable, so you should be good to go. But remember that the greater that additive term is, the more packets you might need to queue. I couldn't find the spec I saw originally that made me think that there was a three packet limit, but even if that isn't the limit, there is very likely to be some limit. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A proposal to use NIC launch time support to improve NTP
On 12/19/12 14:05, unruh wrote: On 2012-12-19, Hal Murrayhal-use...@ip-64-139-1-69.sjc.megapath.net wrote: In article50d1c5b9.8020...@oracle.com, Brian Utterbackbrian.utterb...@oracle.com writes: No, you are missing the point. You have two clocks in this scenario, the kernel clock and the network controller clock. If one gets a good time then you have to set the other from it. This means that this time will have to travel over the PCI bus which will introduce jitter. Now, if you have a PPS signal available and can provide it to both the network controller and the kernel, then you don't have this problem since the PPS signal will sync the time to an accuracy better than the jitter that was introduced. Doesn't the PPS signal to the kernel have to go over the same PCI bus? I'd guess that you would get better results from a network card. That's assuming it has a good clock. All you have to do is read a counter. There is no interrupt latency. You can also read it several times and pick the best one. Pick the best one? How would you know what the best one was? Not sure what you mean by a good clock. It certainly will not be an accurate clock. It may be one whose drift rate is not too bad, although I suspect it will change with temperature. Generally, the PPS signal does not go over the PCI bus. The kernel gets its PPS signal via the serial port. You would therefore like the controller to have its own PPS signal input, but I don't see one in the datasheet. So you are back to worrying about the sync of the kernel clock and the controller clock. It might not matter too much, but it will kind of depend on how the receive timestamp is obtained from the card. The receive timestamp and transmit timestamp have got to be on the same time source or you could run into problems. Brian -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A proposal to use NIC launch time support to improve NTP
On 12/19/12 16:49, Brian Utterback wrote: Generally, the PPS signal does not go over the PCI bus. The kernel gets its PPS signal via the serial port. You would therefore like the controller to have its own PPS signal input, but I don't see one in the datasheet. So you are back to worrying about the sync of the kernel clock and the controller clock. It might not matter too much, but it will kind of depend on how the receive timestamp is obtained from the card. The receive timestamp and transmit timestamp have got to be on the same time source or you could run into problems. Brian Actually, the controller does have the equivalent of a PPS input. There is a provision for detecting a level change on a single input line. The controller timestamp of the level change is stored in a register. The driver can read the register and if it knows what the timestamp should have been when that signal came in, it can calculate the offset. There is then a register that it can write the offset to, which results in the controller adjusting its clock by that amount. There is also a facility in the controller to generate a periodic clock based signal. Pretty nifty all told, if the driver makes use of it. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Panic stop captured
On 12/14/12 16:11, A C wrote: I finally had a panic stop with an instrumented copy of 4.2.7p270 which was capturing various values inside the functions refclock_process_f and refclock_process_offset. I'm going to post an entire capture of the log but one thing I noticed is that the value of pp-nsec at the top of refclock_process_f slowly ticks down and then wraps around. Eventually a panic stop happens: panic_stop +2147483648 s; set clock manually within 1000 s. (but the clock hasn't changed, the system time is still correct to within a second of all my other systems). Apparently the wrap around happens pretty frequently so it's not likely the cause of the problem. For now the log is available at http://acarver.net/ntpd/ntpd_panic.log (8 MB file, be warned) in case any of you has an idea about what might be happening to cause the panic or there's anything else I should instrument and write to the logs instead. There are several steps in each of the functions written out to the log looking for overflows or similar. I do have various statistics files for that period, too, if they would be useful. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions Not know where how the executable was instrumented, it is hard to tell exactly what all of this output means. But there is one thing that jumps out at me. Exactly at the time that the panic stop occurs, ntpd has just peered with the SHM refclock. This suggests that the time stored in shared memory is either uninitialized or is the wrong format. -- blu Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. - Martin Golding ---| Brian Utterback - Solaris RPE, Oracle Corporation. Ph:603-262-3916, Em:brian.utterb...@oracle.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] A proposal to use NIC launch time support to improve NTP
On 12/13/2012 5:00 AM, Jonatan Walck wrote: This is going to be very hard to get it to be useful. Looking at the specs for the card, the timestamp you give is relative to a clock that is internal to the controller, and is only accurate to the nearest second. That is, it is like the PPS in that it is assumed that the clock is in sync to within .5 seconds to avoid aliasing the timestamp. Brian. The internal clock of the network controller is the PHC for IEEE1588, it has a 1 ns resolution, and can be steered with a 32 bit fractional of 1 ns. see SYSTIML and TIMINCA in the I210 datasheet. // jwalck I know that. The problem is that there is going to be jitter introduced when you set the clock from the kernel. That is generally the problem with IEEE 1588, getting the time from the controller to the kernel and vice versa. If you have to go across a PCI bus for instance that will introduce jitter. Brian ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
