[ntp:questions] NTP Performance on WINNT
Hi All, I'm new to NTP, glad to meet you here. I did some experiments to test NTP performance on WINNT. In an isolated network, two machines are inter connnected with a switcher. Machine A is configure as a stratum 12 NTP server, using lcl as reference clock; machine B is sychronized to machine A. Then, 'ntpq - p' is performed on machine B every 16 seconds. The output of ntpq is cooked by a python script and offset field is recorded to log file. After about 2 hours, I check the log file and found the offset value is 4 ~ 8 ms. Is this normal? I mean if things are properly done, how small the offset I can expect? Thanks. The OS is Windows XP Pro SP3 and NTP software is 4.2.4-p7 from mainberg. http://www.meinberg.de/download/ntp/windows/ntp-4.2@copenhagen-o-win32-setup.exe ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Testing Sync Across Several Systems
On Jul 20, 8:38 pm, T g41...@motorola.com wrote: Greetings: We have about 50 Linux/Solaris/Windows boxes running ntpd at several different sites. Some of the systems from time to time go out of sync. My question is there a way to test ntpd machines are all in sync with the master server? I was thinking of using ssh to get on to each machine to do a date and then go back to the master and do a date and compare, but this seems problematic at best. What do people do to check that all machines are in sync? Thanks in Advanced for any help. Tom My solution is to run 'ntpq -p hostname' remotely from monitoring host. Output of the command can be processed by some kind of scripts, like perl or python, or be redirected to other program. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Performance on WINNT
On Jul 20, 10:36 pm, David J Taylor david-tay...@blueyonder.not- this-part.nor-this.co.uk.invalid wrote: paul wrote: Hi All, I'm new to NTP, glad to meet you here. I did some experiments to test NTP performance on WINNT. In an isolated network, two machines are inter connnected with a switcher. Machine A is configure as a stratum 12 NTP server, using lcl as reference clock; machine B is sychronized to machine A. Then, 'ntpq - p' is performed on machine B every 16 seconds. The output of ntpq is cooked by a python script and offset field is recorded to log file. After about 2 hours, I check the log file and found the offset value is 4 ~ 8 ms. Is this normal? I mean if things are properly done, how small the offset I can expect? Thanks. The OS is Windows XP Pro SP3 and NTP software is 4.2.4-p7 from mainberg. Paul, For comparison, I have the performance of a mixture of Windows systems running a mixture of NTP versions plotter here: http://www.satsignal.eu/mrtg/daily_ntp.html The Windows XP system synced to a local stratum-1 clock is Narvik, showing an offset of within 1.5ms, but that is with a poll interval clamped to 64s. The best is the system Feenix with a local GPS serial and PPS reference clock (but no temperature control) where the offset is within about 0.2ms, and the worst the Windows Vista system Gemini which has a DVB/USB data reception system capturing about 20GB/day, but clobbering the offset with transient peaks of at least 50ms. How long is a piece of string comes to mind! Cheers, David Thank you, David. In my situation, no GPS is availiable. So can I expect better performance when GPS is used as reference clock, or when a stratum-1 NTP server is added to the network? And, I noticed the offset for Narvik is more stable than that for Hydra, is it due the PPS feeded to Narvik? But Bacchus is doing good too without PPS, Why? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Performance on WINNT
On Jul 20, 11:45 pm, David J Taylor david-tay...@blueyonder.not- this-part.nor-this.co.uk.invalid wrote: paul wrote: [] Thank you, David. In my situation, no GPS is availiable. So can I expect better performance when GPS is used as reference clock, or when a stratum-1 NTP server is added to the network? Local GPS or a local stratum-1 server will make a significant difference. When using the Internet the quality of your connection to the remote server, and the remote server loading are probably more important factors than precisely how that server is synced (i.e. whether it has a local GPS clock). 10 Windows boxes with offset no greater than 5 ms from abs time is fair enough for me. I will try a local stratum-1 NTP server. Cheers, Paul ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Performance on WINNT
On Jul 21, 1:55 pm, David J Taylor david-tay...@blueyonder.not-this- part.nor-this.co.uk.invalid wrote: paul wrote: [] 10 Windows boxes with offset no greater than 5 ms from abs time is fair enough for me. I will try a local stratum-1 NTP server. Cheers, Paul Paul, Just for interest, the ntpd.conf for my PC Narvik contains lines like: ___ server 192.168.0.2 iburst maxpoll 6 prefer server 192.168.0.7 maxpoll 6 server 0.uk.pool.ntp.org minpoll 10 server 1.uk.pool.ntp.org minpoll 10 server 0.europe.pool.ntp.org minpoll 10 server 1.europe.pool.ntp.org minpoll 10 ___ The first two are my local stratum-1 servers (GPS/PPS to Windows XP systems, ideally with a light or relatively constant load), and are set for 64s polling (maxpoll 6). To avoid hitting the Internet servers with requests as often, they are set for minpoll 10 (1024s), as they are for backup in the case that both my stratum-1 servers fail. A direct connection from the serial GPS/PPS puck is the best, but even if you need to go through a serial-USB convertor performance may be adequate (I saw about 160us jitter). Cheers, David Hi David, I am wondering is there any other means to profile NTP performance, like some kind of hardware setup to measure time offset of two machine? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Performance on WINNT
On Jul 25, 11:38 pm, David J Taylor david-tay...@blueyonder.not- this-part.nor-this.co.uk.invalid wrote: paul wrote: [] Hi David, I am wondering is there any other means to profile NTP performance, like some kind of hardware setup to measure time offset of two machine? I wrote some simple programs which you can download here: http://www.satsignal.eu/software/net.htm#NTPmonitor It's millisecond rather than microsecond level stuff, but perhaps it may help you? Cheers, David Thanks, but I mean something which do not rely on the output of ntpq.exe. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Performance on WINNT
On Jul 26, 12:30 am, David J Taylor david-tay...@blueyonder.not- this-part.nor-this.co.uk.invalid wrote: paul wrote: [] Thanks, but I mean something which do not rely on the output of ntpq.exe. My NTP Monitor uses NTP network calls to determine the offset of the PCs - it doesn't use ntpq. However, in that sense, it does rely on the output from NTP. What problem are you trying to solve, and how accurately do you need to measure? I'm just not so sure if I can absolutely count on ntpq to determine time offset of NTP synced machines... Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Performance on WINNT
Although you might be able to drive a real (non-USB) parallel port, from application code, with fairly low latency the results would only be meaningful for a very unloaded machine, as, on a loaded machine, you wouldn't really know where you where in the system tick interval, when you read the software time. Johan Nilsson has implemented a Continuously Updating, High-Resolution Time Provider for Windows, maybe this will helpful？ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Time to fix reported driver bug.
I reported a bug in a driver about a month ago. Should I expect a feedback other than having it assigned to the refclock maintainers? Are times to fix on the scale of months or years? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time to fix reported driver bug.
On Sun, Mar 16, 2014 at 9:53 AM, David Woolley david@ex.djwhome.demon.invalid wrote: If you tell us which bug report, someone may be able to indicate whether there is a competent developer, and how important it is. 2557. In most cases (~100%) it's inconsequential. I only noticed when adding another device in the Trimble family but if there's active support I'd submit a patch for it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Indirect GPS time source options
On Thursday, March 13, 2014 1:52:51 PM UTC-4, Olivier Drouin wrote: Diversity is really what I'm looking for and I dont really need microsecond accuracy. I'll talk with the facility owner and do some tests with handheld GPS so I can verify what kind of signal I can get (and where). I'm not sure what your goals and constraints are but ... You should test with a high sensitivity timing GPS receiver (e.g. u-blox or Resolution SMTx). I get acceptable performance in an inner office off a machine room on the ground floor of three-story building. In my case acceptable is 100s of microseconds. If you can sometimes get a GPS signal in your machine room (interior or exterior antenna) then run that into a GPS disciplined oscillator which should give 10-100microsec./day drift when there's no GPS signal -- O(10ms/yr) given stable temperature. The high sensitivity + timing constraints let you stay locked with just a single satellite fix. There are also some time transfer tricks you could do to periodically discipline an oscillator or you could just switch to a Rubidium/quasi-Cesium based free-running oscillator that you manually discipline if needed with NTP (e.g. approximate time2 from peer stats). Some of these things you can buy, some you would have to assemble from functional modules. There was a discussion in the last 12 months or so on the Time-Nuts list about doing time transfer into (really) RF free areas (i.e. secure bunkers). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time to fix reported driver bug.
On Sun, Mar 16, 2014 at 2:22 PM, William Unruh un...@invalid.ca wrote: I only noticed when adding another device in the Trimble family but if there's active support I'd submit a patch for it. Why would you not submit a patch for it if you have one? I meant submit a patch for the new device. I supplied a patch for bug 2557 in the report. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time to fix reported driver bug.
On Mon, Mar 17, 2014 at 12:01 AM, Danny Mayer ma...@ntp.org wrote: A patch WAS submitted for this though it was done inline instead of as an attachment I added a patch against p433 as an attachment. I recommend that you mark it as possibly blocking 4.2.8 How to do that isn't immediately obvious and I'm not sure I want to learn how to use Bugzilla. Your explanation in the report seems to be adequate but someone needs to examine the code to see if the fix has any side effects, especially for other devices. I added a comment. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?
On Mon, Mar 17, 2014 at 8:50 AM, Joe Gwinn joegw...@comcast.net wrote: Yes. My question is basically a query about the current state of the art. Some NTP offsets (output may look funny if formatted) clock1 looking at clock2 and clock3 (a Raspberry Pi). This suggests it can be as good as your IRIG system. Gig ethernet to Gig ethernet. ~22 days: N Min MaxMedian AvgStddev 244059 -0.098741335 0.019727433 9.586e-06 4.814598e-06 0.00038621792 Gig to Fast ~10 days N Min MaxMedian AvgStddev 112254 -0.000516264 0.000453913 1.127e-06 6.8736914e-06 4.2248166e-05 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?
On Mon, Mar 17, 2014 at 8:09 PM, Joe Gwinn joegw...@comcast.net wrote: I'm not familiar with DTI. Look for DOCSIS timing interface. The tight specs mentioned earlier are over a backplane although the in-premises numbers are sub-microsecond. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?
On Mon, Mar 17, 2014 at 8:07 PM, Joe Gwinn joegw...@comcast.net wrote: People are also lusting after sub-microsecond sync. Sure but not optimally in comp.protocols.ntp/questions@lists.ntp.org. With some help NTP can be quite good but the intent really isn't nanosecond accuracy. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?
On Mon, Mar 17, 2014 at 9:33 PM, Joseph Gwinn joegw...@comcast.net wrote: Will it do 100 meters or more, in bad neighborhoods? I'm not the right person to ask but since it is expected to maintain between 2.5 and 100 nanosecond sync with CPE nodes (cable modems) I assume it requires RF techniques not readily available (or cost effective) outside a cable plant. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?
On Tue, Mar 18, 2014 at 5:14 AM, Martin Burnicki martin.burni...@meinberg.de wrote: But without additional measurements you still don't know for sure if this is the true time offset, or if there is an additional systematic time offset (e.g. to an asymmetric network connection) which can't be measured. The point was you can easily get below milliseconds with NTP. It's irrelevant because the OP is actually interested in PTP. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] NIST wonders if it makes sense to outsource NTP over the public Internet
Sort of Lots of interesting stuff. https://www.fbo.gov/index?s=opportunitymode=formid=4f5c8b176af03d89abb1a318624c944b SUMMARY: National Institute of Standards and Technology (NIST), Department of Commerce, seeks information from the public on NIST's potential transition of time services from a NIST-only service to private sector operation of an ensemble of time servers that will provide NIST-traceable time information in a number of different formats over the public Internet. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NIST wonders if it makes sense to outsource NTP over the public Internet
On Wed, Mar 19, 2014 at 3:20 PM, E-Mail Sent to this address will be added to the BlackLists Null@blacklist.anitech-systems.invalid wrote: Certichron is already doing that? I'm curious what punctuation you intended. They are already a significant portion of the NIST NTP servers They were. Certichron appears to have left the building. http://tf.nist.gov/tf-cgi/servers.cgi I believe that page is evidence that NIST should be considering some alternatives. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?
On Wed, Mar 19, 2014 at 6:16 PM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: Each constellation has its own epoch, TAI or UTC time scale, and uncertainty: I'm unclear how various time scales relate to PTP. It would appear that the design intent is local (LAN) process control. And while that might subsume diverse goals time transfer between national labs (even on the same continent) seems out of scope. But perhaps the OP has such interests. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?
On Wed, Mar 19, 2014 at 7:04 PM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: While 1ns precision may be doable, accuracy depends on what controls the GM, and its traceability to a reference. Sure. My point is I haven't seen a use case in this thread for nanosecond *accuracy* relative to the TAI paper clock. Actually I haven't seen a use case for anything -- just some wishful thinking. Getting and keeping a GM in (sub)nanosecond phase with any national lab would appear to be a much larger problem than worrying about which lab you decide to use as a label on the side of the box. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] IEEE 1588 (PTP) at the nanosecond level?
On Thu, Mar 20, 2014 at 1:35 PM, Rob nom...@example.com wrote: Paul tik-...@bodosom.net wrote: Sure. My point is I haven't seen a use case in this thread for nanosecond *accuracy* relative to the TAI paper clock. It is not for timestamping the moment of clicking in an online auction or stock trade? The original question was about the capability of PTP as an improvement over NTP possibly based on IRIG time transfer. Given such a vague question one might simply say if you spend enough money you can do better than the noted O(1ms). Eventually *this* thread drifted off the rails into the realm of national lab scale transfers. Since Joe Gwinn didn't say there was a need for such a degree of *fidelity* (truth as opposed to precision or accuracy, I should have made that more clear) I don't yet know why the issue came up. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On Sat, Mar 22, 2014 at 8:54 PM, Daniel Quick daniel.qu...@gmail.comwrote: While considering that the number of requests to our time servers will grow over time since the client decides which server to sync with. What if the number of queries over time is decreasing? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On Mon, Mar 24, 2014 at 12:26 AM, Danny Mayer ma...@ntp.org wrote: That's a misconception. While I trust Richard Schmidt in what he says, that's is not what you think he says. It's hard to misinterpret 590SG load balancers and : It is the load balancer's duty to assign each incoming NTP request to one of the available servers, balancing the load by round-robin, weighted round-robin, least active connections, or other algorithm. Each NTP server returns packets to the load balancer for forwarding back to the requestor. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On Mon, Mar 24, 2014 at 11:18 AM, Jan Ceuleers jan.ceule...@computer.orgwrote: But I wonder what an active connection is in this context, since NTP sits atop UDP. These are IP based not TCP/IP. Do the load balancers track whether an association has been mobilised They could although the packet inspection code on devices like this (I'm not familiar with the CAI boxes) tends toward HTTP not NTP. , and if so do they ensure that a particular client is always served by the same server, at least if the poll interval is reasonable? That seems unlikely. But we know that the major problems are congestion (which load balancing is fixing) and weak system clocks. Presumably a bit of care would cause the inside-NIST-errors to be swamped by the outside-NIST-errors. And in fact the point of the paper is using PTP with the end result that the intra-farm errors should (it's four years later maybe they are) be in the nano-seconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] USTiming.org and Certichron sites out for a week
On Mon, Mar 24, 2014 at 12:08 PM, toddglas...@gmail.com wrote: The Certichron DNS servers got a DDoS attack against them. We apologize - please use the native time server addresses until they are replaced later this week. Please tell us it was an NTP amplification attack. Is your web problem related to this as well? www.certichron.com Welcome to certichron.com Learn how you can get this domain ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On Mon, Mar 24, 2014 at 1:42 PM, Terje Mathisen terje.mathi...@tmsw.no wrote: Huh? I'd rather expect the current trends to continue, with more and more gear starting to use (often very bad subsets of) the ntp protocol for time sync. The fastest growing device (and for many many people the only) segment is mobile. They don't use NTP pool* resources. Apple devices use Apple servers (slowly). I expect most mobile devices get time from the mobile network (I don't know about random other tablets). I have appliances that use NTP. Some point to specific places, some use pool, some use DHCP and some let you specify via a web page. I don't think the future is the past where a few thousand misconfigured SOHO routers escape into the wild and grind someone down. It may not be fair to exclude zillions of machines using bootleg copies of windows but I do. In an idea world we would have lots lots of S1 and S2 servers all around the world, and all the clients would use 'pool' to automatically detect the best servers to connect to. In my ideal world the GPS everyone is carrying around would be an SNTP server for that person. *I still don't really understand the original question but perhaps it was about pool.ntp.org. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Quality vs. Quantity
On Mon, Mar 24, 2014 at 1:37 PM, Brian Inglis brian.ing...@shaw.ca wrote: I hope that description is inaccurate, because of the additional delay and jitter added by passing twice through the front end. It may not be the case now but that would be an enormous error on the part of the authors. Well designed load balancers run at wire speed (at least up to 1G) and shouldn't add any more jitter than any other switch. By the way the 590SG only has four ports. Uplink, Downlink, Mirror and (probably) Manage. It probably has less jitter than the router it's plugged into. I would expect the load balancer to only provide the IP addresses of the currently lowest loaded and highest quality servers closest to the client, as the NTP Pool does. That's not what IP load balancers do. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Handle ntp conf modification when ntp is already running
On Tue, Apr 8, 2014 at 12:24 PM, Dowd, Greg greg.d...@microsemi.com wrote: do you mean a new association? Like the ntpdc addserver command? Beyond the limited set of options and unpleasant syntax of addserver isn't ntpdc deprecated? (and disabled by default in recent builds) Perhaps :config and config-from-file are the intended replacements. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Reasons of NTP not to use GPS source
A remarkable amount of traffic for a question posted last September. Particularly considering voltage matching wasn't mentioned. However it doesn't matter if William Unruh has never seen level matching problems or if Null@blacklist has always seen it. If the device under test works it works and if not you have to condition the pulse or find another solution. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Fri, Apr 25, 2014 at 9:13 AM, Rob nom...@example.com wrote: Of course it is all caused by the failure to include timepps.h in the kernel include file package, where they belong IMHO. Apparently there is unresolved debate about that. Ubuntu puts this development related file in the pps-tools package, and openSUSE does not have it at all. Yes there are years later unresolved issues. Ubuntu (reasonably) wants this resolved upstream. Debian, taking a broader view, also wants it resolved upstream. I don't know anything about openSUSE. In fact on Ubuntu there is another problem (not on openSUSE): the ntp source package does not build correctly, it halts on compilation of ntpd/refclock_jupiter.c ... It is unclear to me how this bug can be present and the package can still be distributed in binary form... Because the jupiter driver isn't in the binary (at least not in 12.04). So on the one hand it would be nice if the source package depended on pps-tools but on the other hand it would be nice if every distribution shipped a stable dev release but on the other hand one might argue that the upstream should provide timepps.h fallback for more platforms but on the other hand maybe ntpd shouldn't ship with any refclocks and if you're using one you should be prepared to build the requisite kernel and driver(s). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On Thu, Apr 24, 2014 at 11:07 AM, Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote: I would like to know whether NTP can sync between a client and a server within 1ms if the client and server are Linux applications on a simple local network ( less than 10 nodes). As previously mentioned it depends. (These machines are all on the same network but the last one is wireless) remote refid st t when poll reach delay offset jitter == -nub .GPPS. 1 u 203 1024 3770.676 -0.084 0.114 +black .GPPS. 1 u 432 1024 3770.345 -0.051 0.066 +aster .GPPS. 1 u 914 1024 3770.354 -0.093 0.083 *ntp1.GPS.1 u 299 1024 3771.248 -0.055 0.120 remote refid st t when poll reach delay offset jitter == +aster .GPPS. 1 u 140 256 3770.383 -2.281 0.679 +ntp1.GPS.1 u 40 256 3771.201 -2.306 0.703 *nub .GPPS. 1 u 211 256 3770.628 -2.457 0.706 +black .GPPS. 1 u 32 256 3770.184 -2.484 0.645 remote refid st t when poll reach delay offset jitter == +black .GPPS. 1 u 897 1024 3771.024 33.284 46.324 -nub .GPPS. 1 u 45 1024 377 18.423 18.726 203.720 *aster .GPPS. 1 u 86 1024 377 43.362 10.866 26.145 +ntp1.GPS.1 u 267 1024 377 25.155 21.369 75.804 For reference the view from one server: remote refid st t when poll reach delay offset jitter == oPPS(0) .GPPS. 0 l48 3770.0000.001 0.002 *GPS_NMEA(0) .FURY. 0 l38 3770.000 -0.041 0.029 time-d.nist.gov .ACTS. 1 u 96 128 375 36.1203.038 1.156 +nub .GPPS. 1 s68 3760.1710.005 0.007 +black .GPPS. 1 s38 3770.0320.016 0.009 +rPi1.GPPS. 1 s18 3770.0830.073 0.059 +ntp1.GPS.1 u3 32 3771.063 -0.115 0.003 +bbb2.GPPS. 1 u68 3770.258 -0.066 0.008 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Fri, Apr 25, 2014 at 4:36 PM, William Unruh un...@invalid.ca wrote: Why shoul dit ship with no refclocks? ... DO you have the same opinion for serial port or parallel ports, or network drivers? (Ignoring your mischaracterization of what I said and the strawman arguments) because a negligible number of time consumers have a refclock. Back in the day I recall a distro that had ntp-client and ntp-server packages -- so I'm sure I'm not the first person to propose it. Kernel pps is used by enough people that it should be compiled in by default. I think you engage in a great deal of idle speculation. We have thousands of clients served from three S2 servers (so 0% need for refclock support). There are three S1 servers on campus (not yet in production). All three required building NTPd, one required a driver patch and one required building a kernel. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Fri, Apr 25, 2014 at 11:18 PM, William Unruh un...@invalid.ca wrote: As do you-- generalising from your one situation. Are you actually suggesting that the number of refclocks is a non-negligible fraction of the number of clients? Even if you only include Linux that makes no sense. Most of our non-mobile clients run windows and get time from Microsoft or the domain which gets it from our S2 servers. Most of our Linux instances are servers which get time from our S2 servers. I don't imagine our circustances are wildly out of line. By the way comparing network kernel drivers to application build choices is silly. I'm willing to firmly assert that there's much greater need for network support than there is for the ATOM refclock. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Sat, Apr 26, 2014 at 3:33 AM, Rob nom...@example.com wrote: The point is that the program is compiled with a fixed set of refclocks that is unneccessarily limited because the environment it was compiled in was not complete. Are you saying that the ntpd that ships with Ubuntu 14.04 is limited or are you referring to your build here? The latter seems odd but since you don't know what was in the upstream build environment the former also seems odd. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Sat, Apr 26, 2014 at 4:34 PM, Jason Rabel ja...@extremeoverclocking.comwrote: Don't you think that is a gripe for the people over at Ubuntu? Well maybe. The OP was directed to Linux distributors but in this case that's Debian not Ubuntu. But to your point -- even if you don't much care for my comprehensive approach -- get current sources and build what you need -- I think it's fair to wonder why the NTP tar ball doesn't include timepps-Linux.h along with others they do include. So wrong subject line but right mailing list. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On Fri, Apr 25, 2014 at 11:22 PM, William Unruh un...@invalid.ca wrote: I have 8 machines that reliably sync from one GPS PPS driven machine (all using chrony) and they get time reliability of about 10microseconds How do you determine the 10 micosec. value? And why are you conflating NTP performance with Chrony performance? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Sat, Apr 26, 2014 at 6:30 PM, Rob nom...@example.com wrote: Can't they add just one simple package to that? Well pps-tools is clearly special. E.g. it's no longer advertised for 12.04 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Can NTP sync within 1ms
On Sat, Apr 26, 2014 at 8:30 PM, William Unruh un...@invalid.ca wrote: use the offset scatter as an estimate of the time performace (It is at least some sort of upper bound, but as I have said, not terribly accurate) I suspect you shouting CANNOT is probably overstating the issue. After all if offset was of no value how would NTP (or any other offset based time transfer system) work? To the previous point -- if someone says my offsets are always 10s of microseconds that is likely to be a refutation of the 'NTP can't do better than 10s of milliseconds position. I don't know what terribly accurate might be to you but in the real world sufficient accuracy depends on the circumstance. Someone should conduct an experiment. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Sat, Apr 26, 2014 at 5:05 PM, Paul tik-...@bodosom.net wrote: I think it's fair to wonder why the NTP tar ball doesn't include timepps-Linux.h along with others they do include. On Sat, Apr 26, 2014 at 7:54 PM, Harlan Stenn st...@ntp.org wrote: Is there only one version of that file that is compatible with the places NTP will be built? ... And even if so, why should this issue cost-shift to the NTP Project? So why does the distribution include multiple, platform specific, instances of timepps.h viz. timepps-SCO.h timepps-Solaris.h timepps-SunOS.h ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Sun, Apr 27, 2014 at 12:57 AM, mike cook michael.c...@sfr.fr wrote: If you look at those, they are included because the API does not ( or didn't ) exist in the OSs whereas it does for Linux I'll admit to being largely uninformed but to me it looks like all the complete (per the RFC) instances of timepps.h define the RFC functions in terms of ioctl. So I'm not yet persuaded that the kernel devs believe their job is unfinished. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Tue, Apr 29, 2014 at 12:12 AM, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: I would find it annoying to have to tell someone Oh, but if you want to pass on the time you need to uninstall what you have now and replace it with the client/server version. Clearly there was confusion. I said I recall a distro that had two packages. E.g. - ntp-common with ntpd built as disable-all-clocks and - ntpd-server with ntpd built as enable-all-clocks. viz. nfs-common. There was a time when such things were considered good practice. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Tue, Apr 29, 2014 at 4:35 AM, Rob nom...@example.com wrote: This solution provides a lean ntpd program that is fit for most users, and it facilitates the easy addition of refclock drivers. Sure or you just recognize that only one system in a million needs refclock support and assume anyone running a refclock needs to be smart enough to build ntpd with the requisite driver. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Tue, Apr 29, 2014 at 10:12 AM, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: However, many of my users who use PPS or other ref-clocks run Windows The subject line is Attn LINUX distributors. And it's really about timepps.h ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Tue, Apr 29, 2014 at 11:21 AM, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: But the threat of breaking NTP into two separate parts had been mentioned, and it was that which I was addressing Sure. But I really have no idea what Harlan was speaking to there and, for Windows users, I think the issue is still largely a distro concern. In this case, if at some unknown future time ntp is further partitioned, what Meinberg does is more important than what's in the tar ball. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Wed, Apr 30, 2014 at 10:13 AM, Martin Burnicki martin.burni...@meinberg.de wrote: If you had a pure client installation you couldn't even send an ntpdate request to that machine just to check the time offsets. Let's try and return to the original issue. timepps.h is not included in core Debian or Ubuntu (I don't know about other Debian downstream distros). As part of trying to understand this issue I suggested that people running refclocks should have greater sophistication that people not running refclocks and that I seemed to recall a distro that shipped an ntpd with (effectively) disable-all-clocks and an ntpd with enable-all-clocks. That's what I'm talking about -- a Linux build of a refclock-free ntpd. I have no idea what Harlan Stenn is considering. I'm sorry if I was unclear that this had nothing to do with broader ntp development or Windows. Even my observation was a bit off-topic and I should have refrained from mentioning it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On Wed, Apr 30, 2014 at 12:14 PM, John Hasler jhas...@newsguy.com wrote: Debian once offered an ntp-simple package It's nice to know it wasn't an imaginary friend. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Fri, Jun 13, 2014 at 12:17 PM, Rob nom...@example.com wrote: Why is it so picky? Why is your jitter so high? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sat, Jun 14, 2014 at 8:15 AM, Rob nom...@example.com wrote: It is a strange feature. You must have some method of numbering the PPS delimited seconds. I am always looking for solutions that are stable by themselves, without constant attention and trickery. NTP is stable. There are two perspectives: 1) The NTP software used as documented is stable without constant attention and trickery. 2) An instance of NTP can be stable if well configured. By the way, you can have more than one server marked prefer. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sat, Jun 14, 2014 at 12:42 PM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: There may be no problem with time only messages: the NMEA driver page, shows support of GLL and GGA which provide only time. Other drivers may allow similarly limited information. The date has to be provided at some point in some fashion. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sat, Jun 14, 2014 at 2:03 PM, Rob nom...@example.com wrote: Everyone seems to think that GPS equates NMEA. Wrong. ... It apparently assumes anyone who has a PPS signal also has a device that provides date and time information, which is wrong. ... But of course the assumptions of the main author have been wrong nom...@example.com thinks you can run NTP as you imagine it should work rather than reading the documentation ... wrong. You have to be able to number the seconds. If you have any source of date/time you can number the seconds. These include: The network. A supported clock type that provides date+time. Your TOD clock. A clock on the wall. Since you're connected to the network your problem is solved. You will need to make some effort to understand how NTP works though. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sat, Jun 14, 2014 at 10:56 AM, Rob nom...@example.com wrote: What is the value of that? It can solve certain problems. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Sun, Jun 15, 2014 at 12:11 PM, Rob nom...@example.com wrote: Did you put prefer on the PPS and not on another source? That was the complete output of ntpq. The local clock is marked prefer; it can reliably number the seconds. This is just a demonstration and I think it unwise to run this way in production. So you suggest that instead of fixing the bug in NTP we should buy new GPSDOs? It's your opinion it's a bug. It doesn't seem like one to me. I think you want a feature enhancement not a bug fix. It could be argued that If you had a correct installation you wouldn't have this problem. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Mon, Jun 16, 2014 at 3:26 AM, Rob nom...@example.com wrote: Note that we do not have a local clock, only PPS. I'm starting to wonder if you simply refuse to read the documentation or you're just trolling to cause trouble. I want to use that majority vote, not one particular server. Is that so hard? There is no majority vote on numbering the seconds. The installation is correct, only the program is mistreating it. I'm starting to wonder if you willfully choose to pretend NTP is something other than what it is so you can complain or you're just trolling to cause trouble. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev: PPS is a falseticker?
On Wed, Jun 18, 2014 at 4:04 PM, E-Mail Sent to this address will be added to the BlackLists Null@blacklist.anitech-systems.invalid wrote: prefer the PPS, The point was that you can't prefer the PPS driver. While this driver can discipline the time and frequency relative to the PPS source, it cannot number the seconds. For this purpose an auxiliary source is required, ordinarily a radio clock operated as a primary reference (stratum 1) source; however, another NTP time server can be used as well. For this purpose, the auxiliary source should be specified as the prefer peer The local clock appears to be suffcient given a correct configuration and time/date bootstrap. Assuming the local clock driver doesn't change (and isn't dropped since it's deprecated). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Servers in virtual machines
On Mon, Jun 23, 2014 at 9:54 AM, David Woolley david@ex.djwhome.demon.invalid wrote: On 23/06/14 13:12, Miroslav Lichvar wrote: I think it all depends on the VM implementation It will still be subject to potentially large scheduling delays between NTP packet arrival and processing. Also, unless you restrict VM to a single host, the TSC could jump The OP said Why are NTP Servers running on virtualized hardware (vmware) unsuitable to serve time to clients? but referred to a generalized recommendation. I'm sure the recommendation is intended for a generic virtual environment not the commercial product VMWare. I don't know about VMWare specific capabilities but the systems I'm familiar with either: 1) have one clock with a fixed offset allowed for domains. 2) have a vm clock that's a reasonable copy of the host clock which can appear to be changed but isn't. 3) have a vm clock that is read-only (attempts to write return insufficient privilege). All of which make running a clock-disciplining system fruitless. I wondered about this when reading $40/mo in Bandwidth for a pool server. I suppose long T deviation could provide insight in clock quality. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Servers in virtual machines
On Tue, Jun 24, 2014 at 8:32 AM, Dave Holland d...@biff.org.uk wrote: Rob nom...@example.com wrote: This is not possible on real virtual machine systems. VMware's documentation disagrees: You've inverted the conceit*. If you *define* a real virtual machine hypervisor as one that doesn't run any applications then you're done. Of course this ignores the correctness of the discipline process. Is an analysis of the output of a disciplined virtual clock indistinguishable from an analysis of a well-mannered non-virtual clock? From a practical point of view is a disciplined virtual clock good enough to contribute? *Rob is referring to a hypervison like ESXi, the page you reference is about the guest OS. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP Servers in virtual machines
On Tue, Jun 24, 2014 at 9:34 AM, William Unruh un...@invalid.ca wrote: On 2014-06-24, Rob nom...@example.com wrote: It is not possible to run programs on the bare hardware. Since the whole VM is a set of programs running on the bare hardware, this is clearly wrong Yes but ... sometimes we don't type what we mean to type. To speak to something I'm more familiar with: The objects formerly known as Solaris Logical Domains (LDoms) are set up by the system monitor (Openboot). That in-ROM supervisor cannot run NTP. The so-called primary LDom can run NTP and in fact controls the (only) hardware clock for all other LDoms. Similarly I believe the ESXi hypervisor microkernel is closer to GRUB than an OS. But I have no direct experience -- hence hand-waving. Rob has defined things so they match his world view. While not actually wrong I think this could be misleading. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Sat, Jul 5, 2014 at 7:37 PM, Jaap Winius jwin...@umrk.nl wrote: Has anyone here managed to turn a relatively cheap, ARM-based embedded system with a serial port into a decent stratum 1 NTP server? Yes (Google NTP Beaglebone or NTP Raspberry Pi I have both) although since that almost certainly means GPS derived time you typically use a PPS signal to get acceptable jitter.The JL Fury NMEA stream will do 10s of microseconds of offset and jitter but I don't believe that's common, certainly not in any of the other NMEA sources I used. Another low cost/low power approach is a Laureline appliance but they don't run NTP -- they simply respond to time queries with GPS derived responses. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Sun, Jul 6, 2014 at 2:25 AM, detha de...@foad.co.za wrote: Be sure to include some form of external RTC though. While sometimes useful a real time clock isn't required on a typical* S1 server. By the way, some GPS modules have an RTC which (if battery supported) will produce a reasonable date/time stamp before lock. *i.e. a date and time stamp can be retrieved from the S0 device. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Mon, Jul 7, 2014 at 12:39 PM, Rob van der Putten r...@sput.nl wrote: AFAIK the BBB 232 cape doesn't support DCD, so PPS is not available. One normally uses a so-called GPIO pin to read PPS on systems that lack a DCD line or a parallel port. E.g. BeagleBone or Raspberry Pi. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Mon, Jul 7, 2014 at 4:38 PM, David Lord sn...@lordynet.org wrote: I'd have to look this up but think board using Elan 486 used the on chip high speed timer to timestamp the pps input at a gpio port along with a custom ntpd on FreeBSD to obtain sub us offset. Perhaps you're referring to this: http://phk.freebsd.dk/soekris/pps/ Illustrated here: http://www.febo.com/time-freq/ntp/soekris/ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Tue, Jul 8, 2014 at 6:01 AM, Rob van der Putten r...@sput.nl wrote: A lot of people however, by an embedded system, hook op a GPS receiver, find that PPS doesn't work and then just give up. That's appropriate. If you don't know what you're doing and choose not to do the work to learn then you should expect failure. By the way even if you have a supported input pin you have to have an NTP that supports PPS. It would be nice to have a comprehensive overview of embedded PPS implementations. It would be an impossible task and it's working backwards. If you want an embedded system based NTP server then you should search for a working product/design/implementation and then buy that. Don't buy something and then hope you can get it to work unless you're a Time-Nut. By the way, you build embedded systems and you build them to do what you want. You use development boards like the RPi and BeagleBone to develop embedded systems. People looking for inexpensive, low overhead NTP appliances should be supporting Partially Stapled's Laureline development. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Tue, Jul 8, 2014 at 1:00 PM, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: I would have supported that, partially because I like the chap what he does, but their server didn't support any of the standard NTP management commands last time I looked I did talk to him about doing authenticated connections and there are some new features in the new appliance. And of course the code and designs are open so people could run with it. I think the only real issue is no on-board packet filter so it can't block connections. The previous version let you monitor the GPS data stream and I monitor time performance indirectly e.g. using ntpdate. Since it doesn't actually run NTP typical NTP status and management is irrelevant. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Wednesday, July 9, 2014, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: I have to disagree with you there. As I understand, it is an NTP server Quoting the maker: ... Laureline is an embedded SNTP server that receives time from a GPS receiver in the form of a pulse-per-second (PPS) input as well as the usual serial data in whatever format it comes (NMEA, Oncore, TSIP, etc.). I call it SNTP and not NTP because time is served from GPS alone and no other NTP servers are consulted. However, laureline is perfectly suitable as a Stratum 1 reference for NTP and SNTP clients alike. ... Also onboard is a small VCXO which is disciplined by the microcontroller to precisely 10MHz using the GPS pulses, in effect making laureline a low-grade GPSDO. ...the rest of the magic is in software: observing the frequency of the local oscillator by way of incoming GPS pulses, calculating NTP time from the 70MHz timer when queried and handling network administrivia.” and therefore I expect it to behave just like any other NTP server I should be more careful and avoid calling it an NTP server/appliance/etc. People should think of it as a network attached reference clock or a GPSDO that can respond to an NTP query. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Wed, Jul 9, 2014 at 8:38 AM, Paul tik-...@bodosom.net wrote: ... Laureline is an embedded SNTP server By the way that was the description of the previous generation product -- the original is here: http://www.eevblog.com/forum/oshw/'laureline'-embedded-gps-ntp-server/ The current version comes with a GPS, uses a TCXO and provides PPS. Just like a GPSDO. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Wed, Jul 9, 2014 at 11:42 AM, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: However, for me, if someone wants an NTP server something like the Raspberry Pi with GPS/PPS is a good, simple, cheap solution, which is easily managed by the user. No management required can be better than easily managed. This is a more recent implication of direction: http://www.eevblog.com/forum/oshw/%27laureline%27-embedded-gps-ntp-server/msg435951/#msg435951 However you're showing a bias which steers away from a better solution, not needing the overhead of fully-featured NTPd isn't a defect it's an advantage. A Laureline is a better NTP response provider than an RPi (see mike cook's plots) and doesn't require *any* configuration or monitoring (but mike cook shows graphs for those that care about such things). No compiling, no OS updates, no conf file fiddling, no management. Literally plug and play. There is still a to-be-fixed leap-second issue but it is documented to support keyed connections and multi-cast. The curious can read about it here: http://partiallystapled.com/pub/laureline-docs/index.html ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
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. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Thu, Jul 10, 2014 at 4:20 AM, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: Simply that different folk have different needs. This true but not nearly as much as people think. But yes different folks have different needs. Despite that in the next sentence You later say: It's a Reference Clock not an instance of NTPD., in which case I would consider one of these: you again drag out the RPi hammer that appears to make everything look like a nail to you. It's a *network attached* reference clock. For me this started when I commented on the USB redesign issues with the RPi. Despite that fact that was reported by many people and was documented in the RPi design docs your response was (essentially) -- it works for me, you must have a rubbish power supply. Different folk, different needs. Yes but unless you're doing NTP(ref) RD or NTP(ref) specific work the tracking you're so fond of is an impediment. This is your bias: .. where it continues to be called an NTP Server, which it not. When he actually wrote I call it SNTP and not NTP because time is served from GPS alone and no other NTP servers are consulted and: I did speak with the originator many moons ago about this project, hoping that it would conform to NTP management standards. I felt it was a missed opportunity The point is time transfer, not having access to NTP(ref) tools intended to monitor/manage NTP(ref). It's not a missed opportunity any more than SNTP/Chrony/OpenNTP or other proprietary yet NTP wire protocol compatible products are missed opportunites. Broader management and network design issues are far more important than clockstats/loopstats/peerstats or if your S1 server responds to NTP control messages. 99.999% of the people looking for a low power/low cost, GPS based S1 server would be well or best served by something like a Laureline. Full disclosure: I run an RPi based S1 server. And two BeagleBone Blacks servers and two x86 servers and a previous generation Laureline (while I wait for my new one). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
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. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Embedded solutions
On Thu, Jul 10, 2014 at 10:17 AM, Brian Utterback brian.utterb...@oracle.com wrote: 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. I spoke overly broadly or I misunderstood The MV scheme is intended for the most challenging scenarios where it is neccesary to protect against both server and client masquerade.. Or both. It is about the client trusting the server, and your firewall doesn't help much with that. Well it sorta does since it blocks a class of IP spoofing. By the way, I don't advocate using a network attached refclock unless the local network is appropriately configured, you have sufficient redundancy and a robust time transfer hierarchy. You don't just drop one in a comm closet with wire access to the roof, make some dhcp entries and call it a day. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Tue, Jul 29, 2014 at 10:15 PM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: As I discovered recently under similar circumstances, offline servers are considered falsetickers, and if you have insufficient other candidates, or fewer than 3, nothing gets selected. I don't think I'm seeing what you're seeing but I could be confused. I believe I mentioned the same thing last time around on this topic. ntpd --version;ntpq -pn ntpd 4.2.7p440@1.2483-o Tue Apr 22 11:51:47 UTC 2014 (6) remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l28 3770.000 -0.002 0.004 *127.127.1.0 .LOCL. 12 l 65800.0000.000 0.004 192.168.0.210 .GPS.1 u 22 32 3771.304 -0.080 0.028 or just using LOCL ... remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l58 3770.000 -0.005 0.008 *127.127.1.0 .LOCL. 12 l 608 2000.0000.000 0.008 naturally you need to let NTP discipline your clock and a cold start requires something to set it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Wed, Jul 30, 2014 at 12:46 AM, Brian Inglis brian.ing...@systematicsw.ab.ca wrote: Not seen this topic mentioned in the last year or more. See my posts about PPS is a falseticker? of Sun Jun 15 14:37:32 UTC 2014 and Wed Jun 18 20:59:03 UTC 2014 . These statuses show the same issue with local clock reach, implying if reach stays at zero, sync will be lost and PPS become a falseticker without anything to number seconds for too long. But it doesn't -- as previously mentioned. The reach bit cycles up until it is 0, then the LOCAL clock is no longer reference clock, the PPS status changes to x remote refid st t when poll reach delay offset jitter == xPPS(0) .PPS.0 l9 16 3770.0000.001 0.000 LOCAL(0).LOCL. 5 l 536 6400.0000.000 0.000 The next cycle the LOCAL clock starts at reach 1 again, becomes the reference (*), and PPS status changes to o again. or here: Looks like a bug anterior to your version. I see the same issue with version=ntpd 4.2.6p5 at 1.2349-o whether or not there is a preferred local clock or not, and whether or not there are other active server associations. Read the thread about the OP's config and problems. I did. And like others I see this: oPPS(0) .GPPS. 0 l38 3770.0000.001 0.008 *LOCAL(0).LOCL. 12 l 66800.0000.000 0.008 oPPS(0) .GPPS. 0 l18 3770.0000.003 0.008 *LOCAL(0).LOCL. 12 l-810.0000.000 0.008 oPPS(0) .GPPS. 0 l68 3770.0000.003 0.008 *LOCAL(0).LOCL. 12 l 21840.0000.000 0.008 oPPS(0) .GPPS. 0 l18 3770.0000.001 0.008 *LOCAL(0).LOCL. 12 l 568 2000.0000.000 0.008 oPPS(0) .GPPS. 0 l88 3770.0000.005 0.008 LOCAL(0).LOCL. 12 l 71800.0000.000 0.008 oPPS(0) .GPPS. 0 l18 3770.0000.005 0.008 *LOCAL(0).LOCL. 12 l8820.0000.000 0.008 etc. etc. I don't see LOCL marked as a falseticker. This clock has been running and keeping acceptable time for weeks (as an experiment). Since this last came up. I mentioned the version because I *don't* have the OP's various problems -- either in configuration or execution which I think, as I said last month, are the OP's real problem BTW, the other snippet seems to refute the idea that you can't run like this with varying minpoll (although the peer was marked noselect). Or perhaps I misunderstand the assertion. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] bad time with a laptop on windows 7
On Sat, Aug 2, 2014 at 4:28 AM, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: How is the Accutime device defined to NTP? I Refclock 29 (Palisade driver) is a serial driver using various TSIP versions -- which are binary -- rather than NMEA. It might be necessary to set the mode, certainly if you want to use Port B. I would in any case. It appears that there's still no PPS support so one would need to use both the ATOM and Palisade drivers assuming you can manage to get the PPS signal to NTP. /* Supported clock types */ #define CLK_ACUTIME 3 /* Trimble Acutime Gold */ #define CLK_ACUTIMEB4 /* Trimble Actutime Gold Port B */ ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] bad time with a laptop on windows 7
On Sat, Aug 2, 2014 at 5:08 PM, Greg Hennessy greg.henne...@cox.net wrote: Well, I chose the Trible Accutime just to have access to a PPS Your Accutime does provide a TTL PPS signal (by the way, PPS capable GPS receivers are quite inexpensive and common these days) but USB isn't the right way to import the signal. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] bad time with a laptop on windows 7
On Sun, Aug 3, 2014 at 12:11 AM, Greg Hennessy greg.henne...@cox.net wrote: Since the hardware has a USB connector, what is the right way to import the signal if not USB? I'm sorry, I should have said best or ideal rather than right if your USB driver/converter supports mapping the PPS input to something NTP can use. The much more important part is using a driver that supports PPS. The NTPref driver 29 does not support PPS for any of the devices it handles (Palisades etc. TSIP variants). If your NTPD Refclock 29 does support PPS and PPS is getting into your computer then ntpq -pn should have the PPS indicator. Note that your USB adapter will have to specifically support the non-standard Acutime pin-out. If this is the case then using NMEA+PPS (20 or 20+22 drivers) is probably the way to go. What exactly did you buy? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] bad time with a laptop on windows 7
On Sun, Aug 3, 2014 at 7:03 PM, Greg Hennessy greg.henne...@cox.net wrote: A Trimble Accutime Gold, I beleive it was the starter kit version. There is a box the RS422 plugs into, there is a power connector, and a USB to my laptop. If you have a Starter Kit and you're using the UIM for RS-422 to USB conversion then I suspect that USB cannot be used to get PPS. I believe it's only presented on the PPS port. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] bad time with a laptop on windows 7
On Sun, Aug 3, 2014 at 4:07 AM, Rob nom...@example.com wrote: Now, USB is more or less a network protocol. The very accurate timing signal from the GPS is converted to a network message over the USB bus that is transferred when time permits, and the moment the message arrives in the PC is much less accurately defined than the timing of the original hardware signal. Not that this is a problem in your situation. The people here are usually time nuts that are looking at accuracies that are much better than what you need and what you are achieving now, and at that point the USB really becomes a problem. Actually the problem isn't really USB induced latency. The problem is getting a USB to RS-NNN interface that will usefully provide DCD (or possibly CTS) to NTPD. For instance in the OP's case there may be an Acutime Starter involved. Yes the provided UIM converts RS-422 to USB but it doesn't propagate PPS. I've read that people use USB to transport PPS but the details always seem a bit sketchy. The spec sheets for some FTDI parts say yes but others say no. Even if the part supports it the pin(s) may not be connected. The only interfaces I'd have any confidence in are the ones with proper specs from the microcontroller hobbyists like Pololu, Adafruit or Tindie. E.g. http://www.pololu.com/product/391 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp-dev conflicts with ntp
On Sat, Aug 9, 2014 at 2:52 PM, William Unruh un...@invalid.ca wrote: This is not a problem with ntpd but with Debian. You could look at it that way but if you're building from the ntp tarball there are a number of solutions the problem presented. Which is best depends on preference and constraints. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Sat, Aug 23, 2014 at 6:05 AM, Harlan Stenn st...@ntp.org wrote: No idea what you mean there - we do 64-bit builds (under linux and other OSes) all the time. You might want to check with whoever handles building packages for your distro. You lot are not fulfilling your obligation to Rob. Tsk, tsk. More seriously -- having that somewhat stale deb repo probably isn't helping anyone and causes confusion (like yours) between ntp-dev tar balls and ntp-dev debs including the (nearly empty) ntp-dev-doc deb. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Sat, Aug 23, 2014 at 4:00 PM, Harlan Stenn st...@ntp.org wrote: I didn't know that Rob was talking about the debian package stuff from ntp.org until he replied to that message. Look for 'ntp-dev conflicts with ntp' from early this month. Of course there's going to be confusion when 99.99% of people think ntp-dev means the tarball and the rest think it's ntp-dev.deb. I'd love to see folks step-up to maintain various distro packages, I believe Steve Kostecke (who provided the buid assist in that thread) makes the debs. preferably people who are on appropriate distro package teams. The problem is if you don't have a deb build-bot then ntp-dev@ntp.org gets out of sync which defeats the purpose of being on dev. To carp yet again: you should add timepps.h to the tar ball and stick to that. Leave the package building to the distributions. If people want/need more current features they should learn how to build the current dev source and you should make that a LOT easier by including timepps.h for Linux because it's never going to be in Debian or derived distros. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Mon, Aug 25, 2014 at 4:44 AM, Harlan Stenn st...@ntp.org wrote: Personally, I don't understand why we should support these devices, but apparently it's important to some folks and perhaps I just don't understand the issue. You have to draw the line somewhere. Perhaps the ntp developers could use voting of some sort to make assess the level of interest. When you read the driver notes it seems that people with unique devices wrote drivers. Maybe it was easier back in the day. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Mon, Aug 25, 2014 at 12:00 PM, Martin Burnicki martin.burni...@meinberg.de wrote: Since current Linux kernels *do* support PPS, and timepps.h is a valid interface to use it, does anyone know *why* timepps.h isn't in the standard set of header files for Linux, and is never going to be? The Debian maintainers think it's the job of the kernel developers to provide it and the kernel developers [my speculation, the result of reading between the lines] think it's redundant because it's just a wrapper (syntactic sugar) around the real API. Maybe they covertly agree that since NTP is (perhaps) the only software using the RFC-style interface it should provide timepps.h ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] LOCL clock reachability not 377?
On Tue, Aug 26, 2014 at 9:54 AM, Phil W Lee p...@lee-family.me.uk wrote: Paul tik-...@bodosom.net considered Mon, 25 Aug 2014 19:13:45 GMT the perfect time to write: it's just a wrapper (syntactic sugar) around the real API. Thre's not much point in adding that capability without the files to enable it to be used. See above. e.g. from timepps.h: time_pps_fetch (arguments) ...[set-up] ret = ioctl(handle, PPS_FETCH, __fdata); ...[side-effects] return ret; } ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS as a falseticker!!!
On Wed, Aug 27, 2014 at 4:44 PM, juergen perlinger juergen.perlin...@t-online.de wrote: The basic problem is that using a PPS clock and a GPS(NMEA) clock separates what belongs together This is not true. Normally I wouldn't fall prey to there's something wrong on the Internet but this assertion doesn't help solve any problems let alone the problem at hand. In fact in some configurations I've run using the PPS option in the NMEA refclock has *caused* problems. None of the PPS refclock + NMEA refclock instances Ive run have any problems. This is not to mention the ability to run a PPS disciplined local clock as a S1 (taking some care to do it right) without a persistent external source of second numbering. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS as a falseticker!!!
On Wed, Sep 3, 2014 at 4:53 AM, Martin Burnicki martin.burni...@meinberg.de wrote: I think the best solution depends on some details. Sure, but my point was that the bald assertion -- The basic problem is that using a PPS clock and a GPS(NMEA) clock separates what belongs together -- is wrong. Sometimes it's useful or essential that your PPS and timestamps come from the same place and sometimes it's irrelevant. Certainly using the NMEA driver to infer PPS quality can be a win but it's not guaranteed. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] About use of PPS in NTP sync
On Wed, Sep 3, 2014 at 10:30 AM, William Unruh un...@invalid.ca wrote: Without PPS, the GPS has an accuracy (delay and fluctuation) in the tens of milliseconds range Most of the time but, of course, not always. From my stable NMEA source (also using PPS): remote: oPPS(0) offset: -0.002 jitter: 0.003 remote: *GPS_NMEA(0) offset: -0.022 jitter: 0.013 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Questions from people whose return address is gmail, googlemail, Yahoo, etc.
On Sat, Sep 6, 2014 at 8:21 AM, Charles Elliott charles.elliott...@comcast.net wrote: Some day, is it going to be important to ISIS to have accurate time to coordinate a massive strike on the electric, railroad, or bridge infrastructure in some Western country? To charles.elliott...@comcast.net, assuming this isn't a troll, no. However despite the previously expressed somewhat fringe views from elliott.ch@verizon and elliott.ch@comcast the message at hand seems odd. E.g. why is it the only message I've seen (admittedly a quick look) that is double spaced and from charles.elliott...@comcast.net? The concepts and proposals are so completely absurd that I suspect a prank. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Questions from people whose return address is gmail, googlemail, Yahoo, etc.
On Mon, Sep 8, 2014 at 7:56 AM, Charles Elliott elliott...@comcast.net wrote: Is it too much to ask that NTP questions list users give identifiable email return addresses Yes. so we can find out where they are located and who they represent? I'd explain more but I don't know who you represent. Seriously you appeear to have no understanding of how any of this works. Please do some research (avoiding tin-foil-hat web sites) and then continue this discussion on a more appropriate list. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On Tue, Sep 9, 2014 at 5:11 PM, Rich Wales ri...@richw.org wrote: I checked the manual before asking my question Good start, so many don't -- even years later. I might point you at The Huff-n'-Puff Filter but perhaps you could explain your concern. An error in the small millisecond range is often considered acceptable or unavoidable. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On Tue, Sep 9, 2014 at 6:58 PM, Harlan Stenn st...@ntp.org wrote: The issue is that the huff-n-puff filter will work in the case where a symmetrical delay becomes asymmetric, and it will tolerate or accommodate an asymmetric delay (caused by a large download, for example) for some period of time. I was overly casual. If you follow the breadcrumbs you find that there is no general solution to the problem. On Thu, Sep 11, 2014 at 9:35 AM, Martin Burnicki martin.burni...@meinberg.de wrote: The case mentioned by the original poster is just one possible reason. Not to suggest that someone is doing something unreasonable but again why does time derived from the back-up clock need to be as accurate as the local clock (say .5ms versus 2ms)? If there's a legitimate need then trying to solve the problem with the wrong tool will only lead to frustration and complaints that NTP is buggy. If I *needed* highly available and accurate time at home I'd get a constellation of stable oscillators to drive time rather than hoping a remote clock or set of clocks was going to solve my problem. As an aside has anyone tried shaping traffic to make the upstream/downstream latencies similar? It would seem more efficient to apply network solutions to network problems if possible. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On Thu, Sep 11, 2014 at 12:48 PM, Rob nom...@example.com wrote: That does not work. The asymmetry is not caused by traffic but by modem parameters. The asymmetry is caused by asymmetric latency which is caused (for our purposes) by asymmetric line speeds. Traffic shaping can change various things (depending on where you do it) including effective line speed (packets/s not bits/s). Perhaps shaping UDP is too hard. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On Thu, Sep 11, 2014 at 2:29 PM, William Unruh un...@invalid.ca wrote: I doubt that NAT would add much assymetry NAT is symmetric. Otherwise it wouldn't work. But I don't see how that's part of anything at hand. And yes the A in ADSL stands for Asymmetric. If you see the word home in reference to a link in the US it's almost certainly asymmetric modulo some special cases (ISDN, T1, Google Fiber etc.). ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On Thu, Sep 11, 2014 at 2:08 PM, mike cook michael.c...@sfr.fr wrote: Did I miss something? On Tue, Sep 9, 2014 at 3:17 PM, Rich Wales ri...@richw.org wrote: My home LAN is connected to my school's network via a cable modem. If we make the (safe) assumption of a common cable ISP/FiOS in the Palo Alto area the path is asymmetric. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On Thu, Sep 11, 2014 at 3:50 PM, mike cook michael.c...@sfr.fr wrote: Yup, AsymmetricDSL does have different up/down bit rates. What I really meant was that the difference would not explain his issue. ex: with a 12Mbps down rate and 1.3Mbps up rate, the ratio is around 40usec to 300usec transfer of a 48byte NTP packet. I was thinking closer to 1ms assuming a 10:1 asymmetry. In any case it would helpful to know the link speeds, delay and the sign of the offset i.e. ntpq output from each end might be illuminating. I also see consistent 2ms offsets between my stratum 1 servers and external stratum 1 servers. Looking on the latter two I see the same offset with opposite sign. I have a 30/5 link. remote refid st t when poll reach delay offset jitter == o127.127.22.0.GPPS. 0 l18 3770.000 -0.007 0.008 2610:20:6f15:15 .ACTS. 1 u 111 128 377 35.7262.098 0.153 2620:cc:8000:80 .GPPS. 1 u 47 64 377 35.5322.034 0.304 2620:cc:8000:40 .GPPS. 1 u2 64 377 35.3082.054 0.675 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On Fri, Sep 12, 2014 at 11:48 AM, Rob nom...@example.com wrote: No, not link-speed asymmetry but propagation-time asymmetry Sure, you can say that after the fact. Only one other person in this conversation *particularly, not the OP* meant that. As I said the conventional notion of asymmetric latency. It's not helpful to hijack the thread. I'm also quite confident that asymmetric network effects other than link speed are second order. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Compensating for asymmetric delay on a per-peer/server basis?
On Sat, Sep 13, 2014 at 1:46 AM, Rich Wales ri...@richw.org wrote: Any thoughts? Something is wrong with your home machine but there's nothing you can do with stock NTP to fix your offset. As posted earlier I see exactly the same ~2ms offset. However as noted -- given that you're on the same network -- these two lines are junk. -68.65.164.12.PPS.1 u 13 16 3728.168 -2.126 4.585 -171.67.203.16 204.63.224.702 u2 16 3339.6892.146 3.930 and these two are pretty bad (and given the same polling interval might also be junk) +198.60.22.240 .GPS.1 u 45 64 377 35.2226.542 2.864 +213.222.200.99 .PPS.1 u 18 64 377 191.1924.890 8.968 My original question remains. Do you have a production need to remove the offset or is it for aesthetic reasons? Regarding shaping. An extremely cursory look suggests you can use a Linux qdisc to insert a delay (shape to effective speed) in NTP traffic so if you have an appropriate box to place between you modem and your home network you could try that -- after you resolve your current problem. ___ 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 Thu, Oct 16, 2014 at 4:16 PM, Phil W Lee p...@lee-family.me.uk wrote: I don't really want to set the minpoll too high, as it takes such a long time to synchronise after rebooting or restarting ntpd. So you're saying something like server 127.127.22.0 minpoll N server 2610:20:6f15:... minpoll M noselect doesn't work or that your dismayed that maxpoll doesn't work they way you expect? ___ 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 Tue, Oct 21, 2014 at 9:55 PM, Harlan Stenn st...@ntp.org wrote: I'm not saying the current behavior can't be improved, I'm just saying that if there is an issue I want it discussed and tracked in a bug report, not some number of email threads. There's clearly a bug*. I've submitted two (other) bug reports one with a driver patch -- there was/has been no discussion or code change. One is assigned to Mills and the other to an apparently inactive maintainer. Why should people waste time there if it's not a security issue? Perhaps phk's ntp rewrite will save us all. *Adding a refclock to an otherwise working system clamps all unspecified minpoll to the refclock minpoll and clamps all maxpoll to the relevant minpoll. Absent any other configuration all minpoll and maxpoll are hence clamped to the refclock minpoll. As of 4.2.7p465/Linux. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
