Re: [ntp:questions] Attn Linux distributors - pse include PPS
Paul wrote: On Tue, Apr 29, 2014 at 10:17 AM, David Taylor david-tay...@blueyonder.co.uk.invalid wrote: But the more variants you introduce, the more opportunity for confusion there is, and the more support effort is needed. Yep. Not in this case. If you had a pure client installation you couldn't even send an ntpdate request to that machine just to check the time offsets. And, is all the ntpq stuff where ntpd is connected from outside and replies to queries client stuff or server stuff which would be omitted in a pure client installation? In the latter case, how would you check the state of the client ntpd? If the client still replied to ntpq queries, would you disable the possibility to let the client ntpd reply to queries for the current time? Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
David Taylor schrieb: On 29/04/2014 15:35, Rob wrote: [] But with a modular approach you would not need to rebuild to add a standard refclock, that would just be the installation of another package containing the precompiled refclock or refclock bundle. That is no different from having a program like Perl as a base, and a lot of packages containing Perl modules for specific tasks. The advantage would be that one can actually ADD an own refclock without having to go through long and painful discussions with package maintainers. Or in the case discussed in this thread, one could compile a single refclock that was omitted due to distributor oversight, and keep the remainder of ntpd standard and candidate for automatic updates. Even when the whole thing (ntpd and refclocks) would be distributed in a single package, it would be possible to add new refclocks to that. I agree it sound nice in theory, but you need to find a mechanism which is supported in all the operating systems which NTP supports, and document how the users can add ref clocks. To me, it's all completely unnecessary - the number of folk /adding/ ref-clocks must be far smaller than those /using/ ref-clocks! Ack. From my experience having to install several packages depending on whether you're going to use refclocks or not will cause more confusion to normal users than it provided benefit for someone. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ 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
Martin Burnicki martin.burni...@meinberg.de wrote: David Taylor schrieb: On 29/04/2014 15:35, Rob wrote: [] But with a modular approach you would not need to rebuild to add a standard refclock, that would just be the installation of another package containing the precompiled refclock or refclock bundle. That is no different from having a program like Perl as a base, and a lot of packages containing Perl modules for specific tasks. The advantage would be that one can actually ADD an own refclock without having to go through long and painful discussions with package maintainers. Or in the case discussed in this thread, one could compile a single refclock that was omitted due to distributor oversight, and keep the remainder of ntpd standard and candidate for automatic updates. Even when the whole thing (ntpd and refclocks) would be distributed in a single package, it would be possible to add new refclocks to that. I agree it sound nice in theory, but you need to find a mechanism which is supported in all the operating systems which NTP supports, and document how the users can add ref clocks. To me, it's all completely unnecessary - the number of folk /adding/ ref-clocks must be far smaller than those /using/ ref-clocks! Ack. From my experience having to install several packages depending on whether you're going to use refclocks or not will cause more confusion to normal users than it provided benefit for someone. Note that splitting the program into separate modules for main function and refclocks does not mean that those modules have to be distributed in separate packages. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
Paul writes: I seemed to recall a distro that shipped an ntpd with (effectively) disable-all-clocks and an ntpd with enable-all-clocks. Debian once offered an ntp-simple package which did not include any refclocks as well as an ntp package which did. -- John Hasler jhas...@newsguy.com Dancing Horse Hill Elmwood, WI USA ___ 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] Attn Linux distributors - pse include PPS
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 26/04/2014 05:05, Harlan Stenn wrote: William Unruh writes: [] More recent ntpd combine server and client in one program. Not sure when that was. It's been the case for at least 20 years' time. This is something that may be different in the upcoming rewrite. H I hope not, as it would make much of the documentation out of date, and destroy much of the simplicity of deployment from the user's point of view. 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. I think a useful separation would be between one part that is a server and a client of network time, and another part (many other parts) that are the interfaces to local refclocks. That could be in the form of a main program with loadable modules (like the Linux kernel), or by reducing the current ntpd to have zero refclocks, and have a set of separate programs that each serve up a refclock as an NTP source that the ntpd program just polls via 127.127.x.y which should be a localhost. Of course something would have to be arranged so that the stratum is not unnecessarily increased by one. This solution provides a lean ntpd program that is fit for most users, and it facilitates the easy addition of refclock drivers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
Harlan Stenn wrote: This is something that may be different in the upcoming rewrite. Do you have a pointer to those plans? Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
Paul wrote: 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. It would be interesting to know why it should be required to rebuild the kernel. At least for Linux I can only imagine that this was at a time where neither nanosecond nor PPS support was provided by the standard Linux kernel, and usually you had to apply Ulrich Windl's patches against the vanilla kernel to get these features. Of course you had to rebuild the kernel in this case. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
Harlan Stenn wrote: William Unruh writes: Well, ntpd could include timepps.h into ntpd source and point to it, instead of using the system one. Is there only one version of that file that is compatible with the places NTP will be built? What sort of bit-rot issues are there if we include a copy of the file in the NTP distribution? Maybe it would be sufficient to let the configure script print a summary of features which would be included, and which not. For example, if you forget to install the openSSL *headers* on a system where openSSL is normally available then the NTP package will silently be built without openSSL support, and when you use the resulting binaries you wonder why things don't work as expected. In a configure script for some other application I tried to build by myself there was a summary line printed indicating which features would be included, and which not, so I could see immediately that an optional feature I was expecting was obviously missing, and could install the required headers to have this optional feature supported. In case of NTP under Linux at least the Linux capabilities, openSSL, and PPS support come into my mind where a warning should be printed if these features are not included simply because some header files have not been installed on the build system. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ 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 29/04/2014 14:40, Paul wrote: [] 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. However, many of my users who use PPS or other ref-clocks run Windows, and they do not have either the required tools or skills to recompile. The compiler alone is a 1 GB download. These days a slightly larger executable including the ref-clocks is a very small inconvenience compared to having to rebuild. Another issue is the time taken to rebuild - you are looking at nearly an hour on the Raspberry Pi, for example. -- Cheers, David Web: http://www.satsignal.eu ___ 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
David Taylor david-tay...@blueyonder.co.uk.invalid wrote: On 29/04/2014 14:40, Paul wrote: [] 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. However, many of my users who use PPS or other ref-clocks run Windows, and they do not have either the required tools or skills to recompile. The compiler alone is a 1 GB download. These days a slightly larger executable including the ref-clocks is a very small inconvenience compared to having to rebuild. Another issue is the time taken to rebuild - you are looking at nearly an hour on the Raspberry Pi, for example. But with a modular approach you would not need to rebuild to add a standard refclock, that would just be the installation of another package containing the precompiled refclock or refclock bundle. That is no different from having a program like Perl as a base, and a lot of packages containing Perl modules for specific tasks. The advantage would be that one can actually ADD an own refclock without having to go through long and painful discussions with package maintainers. Or in the case discussed in this thread, one could compile a single refclock that was omitted due to distributor oversight, and keep the remainder of ntpd standard and candidate for automatic updates. Even when the whole thing (ntpd and refclocks) would be distributed in a single package, it would be possible to add new refclocks to that. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On 29/04/2014 15:35, Rob wrote: [] But with a modular approach you would not need to rebuild to add a standard refclock, that would just be the installation of another package containing the precompiled refclock or refclock bundle. That is no different from having a program like Perl as a base, and a lot of packages containing Perl modules for specific tasks. The advantage would be that one can actually ADD an own refclock without having to go through long and painful discussions with package maintainers. Or in the case discussed in this thread, one could compile a single refclock that was omitted due to distributor oversight, and keep the remainder of ntpd standard and candidate for automatic updates. Even when the whole thing (ntpd and refclocks) would be distributed in a single package, it would be possible to add new refclocks to that. I agree it sound nice in theory, but you need to find a mechanism which is supported in all the operating systems which NTP supports, and document how the users can add ref clocks. To me, it's all completely unnecessary - the number of folk /adding/ ref-clocks must be far smaller than those /using/ ref-clocks! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On 29/04/2014 15:33, Paul wrote: 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 .. and I would be happy if the Raspberry Pi Linux variant did not have tickless set, as it means you need to recompile the kernel to get the best NTP performance. But the threat of breaking NTP into two separate parts had been mentioned, and it was that which I was addressing. If the server variant was the only one available for Windows it would not be a problem. Having multiple variants does increase the support costs. -- Cheers, David Web: http://www.satsignal.eu ___ 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
Martin Burnicki writes: Harlan Stenn wrote: This is something that may be different in the upcoming rewrite. Do you have a pointer to those plans? Not yet - we can start a discussion topic on the wiki and I doubt I'll have time to do much with it for at least a month. Right now I have a few significantly hotter fires to put out (for example, you may have noticed there haven't been any tarball snapshots in a while - hardware problems). H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On 26/04/2014 05:05, Harlan Stenn wrote: William Unruh writes: [] More recent ntpd combine server and client in one program. Not sure when that was. It's been the case for at least 20 years' time. This is something that may be different in the upcoming rewrite. H I hope not, as it would make much of the documentation out of date, and destroy much of the simplicity of deployment from the user's point of view. 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. Better to have the server incorporated but sitting silent until needed. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
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 so responsibility should reside there. IIRC, the OP was a heads up which IS useful, but complaints should go to the distributers, rather than here as has been previously mentioned. That is very clear to me, but do you know about a better point of contact for the distributors? E.g. is there a mailinglist or newsgroup where all those distributors are reading so I don't need to create accounts on a zillion different bugzillas and file a bug there? So far it appears to affect at least openSUSE, Ubuntu and probably Debian. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
Paul tik-...@bodosom.net wrote: 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 Well, it is for Ubuntu 14.04 LTS ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
Le 27 avr. 2014 à 12:28, Rob a écrit : 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 so responsibility should reside there. IIRC, the OP was a heads up which IS useful, but complaints should go to the distributers, rather than here as has been previously mentioned. That is very clear to me, but do you know about a better point of contact for the distributors? E.g. is there a mailinglist or newsgroup where all those distributors are reading so I don't need to create accounts on a zillion different bugzillas and file a bug there? I very much doubt it. I tried to see what support ubuntu were offering and when wanting to ask a Q, got directed to a launchpad login page. So it sort of depends on how much you want a fix! I feel for you. So far it appears to affect at least openSUSE, Ubuntu and probably Debian. ___ 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] Attn Linux distributors - pse include PPS
On 27/04/14 11:28, Rob wrote: is there a mailinglist or newsgroup where all those distributors are reading so I don't need to create accounts on a zillion different bugzillas and file a bug there? You are still going to have to submit the individual bug reports as it will be such a minor issue to the distributors that, even if they do see it, they will forget about it unless it is in their issue tracking system. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
mike cook michael.c...@sfr.fr wrote: Le 27 avr. 2014 à 12:28, Rob a écrit : 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 so responsibility should reside there. IIRC, the OP was a heads up which IS useful, but complaints should go to the distributers, rather than here as has been previously mentioned. That is very clear to me, but do you know about a better point of contact for the distributors? E.g. is there a mailinglist or newsgroup where all those distributors are reading so I don't need to create accounts on a zillion different bugzillas and file a bug there? I very much doubt it. I tried to see what support ubuntu were offering and when wanting to ask a Q, got directed to a launchpad login page. So it sort of depends on how much you want a fix! I feel for you. In fact I don't need a fix at all. I already solved my problem. I only want to help the community so this error can be removed in future products. You know, the always acclaimed strong point of open source projects: anyone can hunt for errors, correct them and the product will be better. When they don't want to listen, too bad. Maybe it is not like that after all. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On -10.01.-28163 20:59, Rob wrote: Apparently there is unresolved discussion whether a .h describing a PPS API belongs in the set of kernel include files or in a separate package. There is? Can't say I've ever dealt with PPS, but *if* this .h provides the necessary information that *several* pieces of userland software need to use a kernel API, with the details/version of that API tied to the underlying kernel version and nothing else, then there should be only three kinds of package suitable to provide that .h: a) the kernel itself (i.e., always present), b) the package providing the kernel module providing the API (*if* made into a module for the distributed kernel), or c) a hypothetical devel package that provides the .h, but *not* some set of userland utilities on top unless they're strictly necessary (e.g., to configure the API in some way before it can be used). Of course, if there's some history of this API's development that needs to be taken into account for compatibility reasons, things can get ... complicated. There's no such thing as 'if [ -f foo.h ]; then #include foo.h ; else #include my_foo.h' (post-./configure) ... But the separate package pps-tools which includes this file already exists. I wonder whether we can take the package description: https://packages.debian.org/de/sid/pps-tools as an actual declaration of *intent* from Debian to keep the .h there. I don't understand why this is a problem that can be fixed in a minute. There must be TENS of packages that have to be installed on the build machine to successfully build the binaries in the distribution. Compilers, linkers, packaging tools, libraries, etc etc etc. Can't they add just one simple package to that? Well *there* you're confusing the software installed on it *to make it a build machine* and the packages installed so as to *get built*. Imagine cross-compiling being involved and you'll see how one needs to be kept separate from the other. I'd imagine that the folks dealing with embedded devices would have a couple choice words about forcing the entire pps-tools into *every* installation just so as to make the PPSAPI available, maybe even the IT security people (particularly if there's set[ug]id involved with them). Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
Jochen Bern jochen.b...@linworks.de wrote: On -10.01.-28163 20:59, Rob wrote: Apparently there is unresolved discussion whether a .h describing a PPS API belongs in the set of kernel include files or in a separate package. There is? Can't say I've ever dealt with PPS, but *if* this .h provides the necessary information that *several* pieces of userland software need to use a kernel API, with the details/version of that API tied to the underlying kernel version and nothing else, then there should be only three kinds of package suitable to provide that .h: a) the kernel itself (i.e., always present), b) the package providing the kernel module providing the API (*if* made into a module for the distributed kernel), or c) a hypothetical devel package that provides the .h, but *not* some set of userland utilities on top unless they're strictly necessary (e.g., to configure the API in some way before it can be used). I fully agree with that. (I wondered why the .h file is in package pps-tools and not pps-tools-dev or in the kernel include file set) Of course, if there's some history of this API's development that needs to be taken into account for compatibility reasons, things can get ... complicated. There's no such thing as 'if [ -f foo.h ]; then #include foo.h ; else #include my_foo.h' (post-./configure) ... There apparently is some confusion whether timepps.h should be in /usr/include or /usr/include/sys but the ./configure for ntpd already handles that. But the separate package pps-tools which includes this file already exists. I wonder whether we can take the package description: https://packages.debian.org/de/sid/pps-tools as an actual declaration of *intent* from Debian to keep the .h there. LinuxPPS support tools and headers This package includes the necessary headers for using LinuxPPS PPSAPI kernel interface in user-space applications and several support tools: * ppstest: PPSAPI interface tester * ppsldisc: setup correct RS232 line discipline * ppswatch: continuously print PPS timestamps * ppsctl: PPS device manager * ppsfind: find pps device by name Apparently they realize that they have mixed up two things in one package. But those tools are minute in size and will not disturb anything. I don't understand why this is a problem that can be fixed in a minute. There must be TENS of packages that have to be installed on the build machine to successfully build the binaries in the distribution. Compilers, linkers, packaging tools, libraries, etc etc etc. Can't they add just one simple package to that? Well *there* you're confusing the software installed on it *to make it a build machine* and the packages installed so as to *get built*. Imagine cross-compiling being involved and you'll see how one needs to be kept separate from the other. What I mean is that for building packages they need not only building tools but also -dev packages for many libraries that are going to be used by the packages being built. There is a long list of packages that one is supposed to install before even attempting to build a single package from source, and then the particular package adds more requirements. This timepps.h file is just one tiny little file between many other .h .a and .so files. I'd imagine that the folks dealing with embedded devices would have a couple choice words about forcing the entire pps-tools into *every* installation just so as to make the PPSAPI available, maybe even the IT security people (particularly if there's set[ug]id involved with them). There isn't: ls -l /usr/bin/pps* -rwxr-xr-x 1 root root 10672 May 25 2012 /usr/bin/ppsctl -rwxr-xr-x 1 root root 298 May 25 2012 /usr/bin/ppsfind -rwxr-xr-x 1 root root 10352 May 25 2012 /usr/bin/ppstest -rwxr-xr-x 1 root root 10576 May 25 2012 /usr/bin/ppswatch I am not forcing anything upon embedded devices, it may even be that those devices don't support the PPS API. I only suggest that the file required to enable PPS support is installed on systems used for building the binaries, so nptd will be compiled with PPS support in environments where this is available. Notice: Several years ago I wanted to sync my clock to a GPS providing PPS. At that time, PPS support in the kernel was only available as a set of patches. You had to apply them to a kernel source tree and rebuild the kernel. And I think there were several competing patchsets. You also needed to build a program that would actually bind the PPS to a device pin. Not wanting to go through all that trouble, I wrote the part of the gpsd program that takes the PPS info in a userspace thread and puts the information in an SHM segment that ntpd can use as a refclock. Support for PPS without having to patch or recompile existing binaries. This worked well, but lately I have been working on a project that has more strict timing requirements and I
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On -10.01.-28163 20:59, Rob wrote: What I mean is that for building packages they need not only building tools but also -dev packages for many libraries that are going to be used by the packages being built. There is a long list of packages that one is supposed to install before even attempting to build a single package from source, and then the particular package adds more requirements. This timepps.h file is just one tiny little file between many other .h .a and .so files. Ah, I see. So there actually are *three* areas of installed software on a build system that need to be properly set up: The stuff that makes the build machine itself (architecture A) run, the packages that you want it to produce (for architecture B), and the source/devel packages that those latter need only *during compilation*. FWIW, you might find this open Debian bug interesting: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672 It does not only state the problem, but also lists the proper technical term (Build-Depend) and an e-mail address to (supposedly) poke the actual package maintainers through. (And IIRC Debian is the upstream for a fair *lot* of distribs.) But, for sake of completeness: While the Build-Depend needs to point to whichever package contains timepps.h, the question of whether that file *belongs* there is, I gather, rather irrelevant for ntp package brewmasters. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 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 2014-04-27, mike cook michael.c...@sfr.fr wrote: Le 27 avr. 2014 ? 05:36, Paul a ?crit : 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 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 so responsibility should reside there. IIRC, the OP was a heads up which IS useful, but complaints should go to the distributers, rather than here as has been previously mentioned. ntpd needs timepps.h. timepps.h is only sporadically included in distros. So ntpd should supply what it needs. It is bizarre that if the distro does not have the API ntpd supplies the timepps, but if it does it washes its hands of the problem? Sorry, makes no sense to me. Now, if each distro required a different timepps.h your argument would make sense, but as far as I know, there is a common timepps.h that will work on all versions of Linux. So, include it. Otherwise why not tell people to but the SCO or Solaris kernel developers to include the API and refuse to include a workaround in the ntpd code? It is the kernel's fault! To waste thousands of people's time, to tell someone to run around to all thousand linux distros and submit a bug report to each one, when one could simply include yet another .h file in the code seems pretty perverse to me. Now the above IS predicated on the assumption that there is a common timepps.h file which could be used for all Linux kernels. If that is wrong, if it really is kernel or distribution specific, then my argument fails. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On 2014-04-27, Rob nom...@example.com wrote: Notice: Several years ago I wanted to sync my clock to a GPS providing PPS. At that time, PPS support in the kernel was only available as a set of patches. You had to apply them to a kernel source tree and rebuild the kernel. And I think there were several competing patchsets. You also needed to build a program that would actually bind the PPS to a device pin. Not wanting to go through all that trouble, I wrote the part of the gpsd program that takes the PPS info in a userspace thread and puts the information in an SHM segment that ntpd can use as a refclock. Support for PPS without having to patch or recompile existing binaries. This worked well, but lately I have been working on a project that has more strict timing requirements and I investigated the current state of things w.r.t kernel PPS. PPS support has been incorporated in the kernel. Distributors compile kernels with PPS support built in, and include modules for parallel, serial and gpio ports. Things are looking good. But those modules give timing to one a few (5-10) usec. because of interrupt handling issues. Your shm solution would seem to me to be more than adequate for any timing requirements if they can be solved with an interrupt driven pps. ntpd has support for this kernel PPS in its source tree. Availability of PPS API is autodetected, and ntpd refclock drivers are using it. Linux distributors compile ntpd with a (default) set of options that basically says: please include all refclock drivers that are supported on this system. Fine! BUT STILL IT DOES NOT WORK Why? Because a single file was missing during compilation. I agree that ntpd should supply that file. It would cost nothing, unless it is true that that file differs depending on distribution/kernel/... And when I suggest to fix that, all kinds of reasons are popping up why this isn't going to happen, isn't wanted, etc. I think it is a big waste of effort made by many people who contributed to what we now have. Pity. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
William Unruh un...@invalid.ca wrote: But those modules give timing to one a few (5-10) usec. because of interrupt handling issues. Your shm solution would seem to me to be more than adequate for any timing requirements if they can be solved with an interrupt driven pps. Well, the kernel PPS API does the timestamping in the interrupt handler while my gpsd/SHM solution does timestamping in a user process that is marked to be ready to run in an interrupt handler. Especially on a loaded system it can be less accurate due to scheduling. I experimented with marking the process for realtime scheduling, but the disadvantage is that it hangs the entire system when it goes in a loop due to some bug. On my system the offset and jitter for kernel PPS from a professional GPS receiver (Datum) are usually 1 or 2 microseconds in the ntpq display, but always less than 5. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
Jochen Bern jochen.b...@linworks.de wrote: On -10.01.-28163 20:59, Rob wrote: What I mean is that for building packages they need not only building tools but also -dev packages for many libraries that are going to be used by the packages being built. There is a long list of packages that one is supposed to install before even attempting to build a single package from source, and then the particular package adds more requirements. This timepps.h file is just one tiny little file between many other .h .a and .so files. Ah, I see. So there actually are *three* areas of installed software on a build system that need to be properly set up: The stuff that makes the build machine itself (architecture A) run, the packages that you want it to produce (for architecture B), and the source/devel packages that those latter need only *during compilation*. FWIW, you might find this open Debian bug interesting: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691672 It does not only state the problem, but also lists the proper technical term (Build-Depend) and an e-mail address to (supposedly) poke the actual package maintainers through. (And IIRC Debian is the upstream for a fair *lot* of distribs.) Ah that looks good, they know what to do since in Aug 2013 mr Zehl posted the correct diff. Now let's hope that someone applies it... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On 2014-04-27, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: But those modules give timing to one a few (5-10) usec. because of interrupt handling issues. Your shm solution would seem to me to be more than adequate for any timing requirements if they can be solved with an interrupt driven pps. Well, the kernel PPS API does the timestamping in the interrupt handler while my gpsd/SHM solution does timestamping in a user process that is marked to be ready to run in an interrupt handler. ?? I do not think so-- the kernel has interrupt handlers which stamp the PPS input via interrupt routines. They hand the result to gpsd which puts it into an shm, if I understand correctly. Thus both the kernel and gpsd use the same interrupt timestamping. Especially on a loaded system it can be less accurate due to scheduling. I experimented with marking the process for realtime scheduling, but the disadvantage is that it hangs the entire system when it goes in a loop due to some bug. On my system the offset and jitter for kernel PPS from a professional GPS receiver (Datum) are usually 1 or 2 microseconds in the ntpq display, but always less than 5. Yes, that is consistant with what I found with my own interrupt handler. I got the feeling but have not done any real tests, that the serial port pps (eg /lib/modules/3.10.28-desktop-1.mga3/kernel/drivers/pps/clients/pps-ldisc.ko.xz) routine was a bit more ragged.) Or is this module what you mean by kernel PPS? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
William Unruh un...@invalid.ca wrote: On 2014-04-27, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: But those modules give timing to one a few (5-10) usec. because of interrupt handling issues. Your shm solution would seem to me to be more than adequate for any timing requirements if they can be solved with an interrupt driven pps. Well, the kernel PPS API does the timestamping in the interrupt handler while my gpsd/SHM solution does timestamping in a user process that is marked to be ready to run in an interrupt handler. ?? I do not think so-- the kernel has interrupt handlers which stamp the PPS input via interrupt routines. They hand the result to gpsd which puts it into an shm, if I understand correctly. Thus both the kernel and gpsd use the same interrupt timestamping. That is a later version, not the one I wrote. It requires kernel PPS API, which mine didn't. That one is still used when kernel PPS API is not available. It uses the TIOCMIWAIT ioctl. The GPS I use (actually a GPSDO) cannot work with gpsd. It has 1PPS and 10MHz outputs but no serial datastream other than some very limited interface that can be used for monitoring. It does not provide time/date. So we use ntpd with a couple of network clocks and the 1PPS with the ATOM refclock (refclock 22). That works OK. At least when ntpd is compiled correctly. Especially on a loaded system it can be less accurate due to scheduling. I experimented with marking the process for realtime scheduling, but the disadvantage is that it hangs the entire system when it goes in a loop due to some bug. On my system the offset and jitter for kernel PPS from a professional GPS receiver (Datum) are usually 1 or 2 microseconds in the ntpq display, but always less than 5. Yes, that is consistant with what I found with my own interrupt handler. I got the feeling but have not done any real tests, that the serial port pps (eg /lib/modules/3.10.28-desktop-1.mga3/kernel/drivers/pps/clients/pps-ldisc.ko.xz) routine was a bit more ragged.) Or is this module what you mean by kernel PPS? Yes that is what I use. PPS timestamping in the kernel, with the PPS API. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
Harlan Stenn st...@ntp.org wrote: William Unruh writes: On 2014-04-25, Paul tik-...@bodosom.net wrote: 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. More recent ntpd combine server and client in one program. Not sure when that was. It's been the case for at least 20 years' time. This is something that may be different in the upcoming rewrite. I think it is not a wrong guess that there are more systems that use ntp only over the network than there are systems which have local refclocks as well. But that is not the point. 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. This would be less of a problem when the refclocks were loadable modules or were running in separate processes on the same machine. Then one could compile a single refclock module or program and add it to an existing system. But until that has been implemented, we could at least try to have the distributors build a complete ntpd by default. Today there is no reason (on the PC platform at least) to squeeze out a few KB of the executable size by omitting a couple of refclocks. My custom built ntpd on Ubuntu is just 55216 bytes larger than the default one. Those bytes probably don't even occupy memory. But it took me 2 hours to learn how to build it and actually do that, a waste of time IMHO. And it is now in risk of being overwritten by a security update. ___ 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
Paul tik-...@bodosom.net wrote: 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. I am saying that the ntpd that ships with Ubuntu 14.04 is limited because it was built on a system where timepps.h was not present, and thus the ATOM and JUPITER (and a couple other) refclocks were not included in the binary. Even though PPS support is present in the kernel. I built ntpd locally after installing the package pps-tools, which includes timepps.h, and then everything is OK. ./configure detects the presence of timepps.h and then enables all refclocks with PPS support. But I would prefer not having to build ntpd to get the ATOM refclock working. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
I am saying that the ntpd that ships with Ubuntu 14.04 is limited because it was built on a system where timepps.h was not present, and thus the ATOM and JUPITER (and a couple other) refclocks were not included in the binary. Even though PPS support is present in the kernel. I built ntpd locally after installing the package pps-tools, which includes timepps.h, and then everything is OK. ./configure detects the presence of timepps.h and then enables all refclocks with PPS support. But I would prefer not having to build ntpd to get the ATOM refclock working. Don't you think that is a gripe for the people over at Ubuntu? Developers have no control how others choose to implement their software. Hence the discussion here is about as pointless as complaining on the Microsoft support forum about how Apple does something in their UI and should change it... *facepalm* ___ 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] Attn Linux distributors - pse include PPS
Jason Rabel ja...@extremeoverclocking.com wrote: I am saying that the ntpd that ships with Ubuntu 14.04 is limited because it was built on a system where timepps.h was not present, and thus the ATOM and JUPITER (and a couple other) refclocks were not included in the binary. Even though PPS support is present in the kernel. I built ntpd locally after installing the package pps-tools, which includes timepps.h, and then everything is OK. ./configure detects the presence of timepps.h and then enables all refclocks with PPS support. But I would prefer not having to build ntpd to get the ATOM refclock working. Don't you think that is a gripe for the people over at Ubuntu? Developers have no control how others choose to implement their software. Hence the discussion here is about as pointless as complaining on the Microsoft support forum about how Apple does something in their UI and should change it... *facepalm* It is about how they configure their build machines. You know, the place where the source packages are loaded on a computer, compiled, and binary packages are being produced to fill a DVD or website. If that is outside the control of the people at Ubuntu, I have misunderstood the place of Ubuntu in the distributor landscape. Is the Ubuntu distribution being built by the people at Debian? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On 2014-04-26, Jason Rabel ja...@extremeoverclocking.com wrote: I am saying that the ntpd that ships with Ubuntu 14.04 is limited because it was built on a system where timepps.h was not present, and thus the ATOM and JUPITER (and a couple other) refclocks were not included in the binary. Even though PPS support is present in the kernel. I built ntpd locally after installing the package pps-tools, which includes timepps.h, and then everything is OK. ./configure detects the presence of timepps.h and then enables all refclocks with PPS support. But I would prefer not having to build ntpd to get the ATOM refclock working. Don't you think that is a gripe for the people over at Ubuntu? Developers have no control how others choose to implement their software. Hence the discussion here is about as pointless as complaining on the Microsoft support forum about how Apple does something in their UI and should change it... *facepalm* Well, ntpd could include timepps.h into ntpd source and point to it, instead of using the system one. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
William Unruh un...@invalid.ca wrote: On 2014-04-26, Jason Rabel ja...@extremeoverclocking.com wrote: I am saying that the ntpd that ships with Ubuntu 14.04 is limited because it was built on a system where timepps.h was not present, and thus the ATOM and JUPITER (and a couple other) refclocks were not included in the binary. Even though PPS support is present in the kernel. I built ntpd locally after installing the package pps-tools, which includes timepps.h, and then everything is OK. ./configure detects the presence of timepps.h and then enables all refclocks with PPS support. But I would prefer not having to build ntpd to get the ATOM refclock working. Don't you think that is a gripe for the people over at Ubuntu? Developers have no control how others choose to implement their software. Hence the discussion here is about as pointless as complaining on the Microsoft support forum about how Apple does something in their UI and should change it... *facepalm* Well, ntpd could include timepps.h into ntpd source and point to it, instead of using the system one. Apparently there is unresolved discussion whether a .h describing a PPS API belongs in the set of kernel include files or in a separate package. But the separate package pps-tools which includes this file already exists. The only problem is that this package is not installed on the build machines. I don't understand why this is a problem that can be fixed in a minute. There must be TENS of packages that have to be installed on the build machine to successfully build the binaries in the distribution. Compilers, linkers, packaging tools, libraries, etc etc etc. Can't they add just one simple package to that? ___ 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] Attn Linux distributors - pse include PPS
William Unruh writes: Well, ntpd could include timepps.h into ntpd source and point to it, instead of using the system one. Is there only one version of that file that is compatible with the places NTP will be built? What sort of bit-rot issues are there if we include a copy of the file in the NTP distribution? And even if so, why should this issue cost-shift to the NTP Project? H ___ 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
Le 27 avr. 2014 à 05:36, Paul a écrit : 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 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 so responsibility should reside there. IIRC, the OP was a heads up which IS useful, but complaints should go to the distributers, rather than here as has been previously mentioned. ___ 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] Attn Linux distributors - pse include PPS
On 04/24/2014 09:31 PM, Rob wrote: all that is required to get PPS working is to fetch the source package of ntpd for the distribution and recompile it while that single file has been added. e.g. on Ubuntu that file is present in the package pps-tools. So please, on your build systems, make sure that the package pps-tools or whatever other source used for timepps.h is installed during the compilation of ntpd. It makes the use of PPS much easier, as one does not have to find how to successfully compile a package from source on that particular system. And it will not be causing trouble when updates appear. The following bug report exists about this problem in Ubuntu's problem tracker. https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/826873 If this issue affects you, please visit that page and say so. This will raise the priority of the problem and the likelihood of it being fixed in the near term. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
Jan Ceuleers jan.ceule...@computer.org wrote: On 04/24/2014 09:31 PM, Rob wrote: all that is required to get PPS working is to fetch the source package of ntpd for the distribution and recompile it while that single file has been added. e.g. on Ubuntu that file is present in the package pps-tools. So please, on your build systems, make sure that the package pps-tools or whatever other source used for timepps.h is installed during the compilation of ntpd. It makes the use of PPS much easier, as one does not have to find how to successfully compile a package from source on that particular system. And it will not be causing trouble when updates appear. The following bug report exists about this problem in Ubuntu's problem tracker. https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/826873 If this issue affects you, please visit that page and say so. This will raise the priority of the problem and the likelihood of it being fixed in the near term. I have no account on that tracker yet but I see you have posted a message already. In fact I am a user of openSUSE which is similarly affected, and found that the same problem exists in Ubuntu when I was helping someone else to get PPS going on his Ubuntu box. (I first had to find out how to compile a source package on Ubuntu) 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. I see this issue, which would be fixed by a single command on the build system (apt-get install pps-tools) has been open for 3 years, and a dup of this issue was closed because there was no response :-( 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 because of -Werror=format-security. There is a patch in the package that is supposed to fix that, and changes some instances of fprinf(stderr, message) to fprintf(stderr, %s, message) in other modules, but it does not include the patch for this file. It is unclear to me how this bug can be present and the package can still be distributed in binary form... ___ 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] Attn Linux distributors - pse include PPS
Paul tik-...@bodosom.net wrote: 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. Everybody would be OK at once when the kernel maintainers would include timepps.h. Maybe the distributors are waiting for that to happen. 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). I am still confused why I cannot recompile a Ubuntu package to the same state as the binary in the distribution. This is for 14.04. I am used to SUSE where one can easily install the package sources and rebuild them using the same options as the builders did. In Ubuntu I did: wget https://launchpad.net/ubuntu/saucy/+source/ntp/1:4.2.6.p5+dfsg-3ubuntu2/+files/ntp_4.2.6.p5+dfsg.orig.tar.gz wget https://launchpad.net/ubuntu/saucy/+source/ntp/1:4.2.6.p5+dfsg-3ubuntu2/+files/ntp_4.2.6.p5+dfsg-3ubuntu2.debian.tar.gz wget https://launchpad.net/ubuntu/saucy/+source/ntp/1:4.2.6.p5+dfsg-3ubuntu2/+files/ntp_4.2.6.p5+dfsg-3ubuntu2.dsc # NTP compileren dpkg-source -x ntp_4.2.6.p5+dfsg-3ubuntu2.dsc cd ntp-4.2.6.p5+dfsg dpkg-buildpackage -rfakeroot -b -nc Those links to package files I got from a Ubuntu page where the latest packages for many versions are displayed, and I selected 14.04 It unpacks the source tree, applies patches, and then starts the compilation beginning with a ./configure with 10 lines of options. I am completely puzzled why this would build another set of refclocks than is in the distributed binary. (of course with the exception of the ATOM PPS refclock, because ./configure will only select it when timepps is available. well, maybe it is the same for refclock_jupiter? I would not expect that since jupiter is a serial receiver) 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). Of course ntpd should use separate modules for refclocks that can be separately compiled and loaded, just like kernel modules. Alternatively, it could be split in a timekeeping engine and a number of clock modules that implement an SNTP-like protocol, and which are polled by the timekeeping engine over local sockets. But that is all just dreaming. For now, it would be nice if it was at least compiled correctly. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
On 2014-04-25, Paul tik-...@bodosom.net wrote: 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). Why shoul dit ship with no refclocks? Why should you have to build the requisite kernel and drivers? DO you have the same opinion for serial port or parallel ports, or network drivers? Everyone who want to use those should have to build the requisite kernel? If not why not? Or maybe everyone should have to build their own kernel always. Good for the soul. Kernel pps is used by enough people that it should be compiled in by default. The common refclocks should be compiled in the distribution ntpd. ___ 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 2014-04-25, Paul tik-...@bodosom.net wrote: 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. More recent ntpd combine server and client in one program. Not sure when that was. 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. As do you-- generalising from your one situation. Why did they require building ntpd? And my point is that it should not be required to build the kernel. Note that the number of your machines for which the people do not use serial or parallel ports is probably the same as those you claim do not use ntpd refclocks. (Note that just because they get time from your three servers does not mean that they do not also use say a gps refclock.) But our position will undoubtedly not change any kernel packager's mind. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Attn Linux distributors - pse include PPS
William Unruh writes: On 2014-04-25, Paul tik-...@bodosom.net wrote: 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. More recent ntpd combine server and client in one program. Not sure when that was. It's been the case for at least 20 years' time. This is something that may be different in the upcoming rewrite. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Attn Linux distributors - pse include PPS
On two different distributions, openSUSE 13.1 and Ubuntu 14.04, I noticed that while everything is available to support kernel PPS, the distributed ntpd is compiled without refclock 22 (Atom) support. This apparently is not intentional, as the ./configure command on both distributions includes many parameters to force inclusion of as many refclocks as possible. However, prerequisite of the compilation of kernel PPS is the availability of the file /usr/include/sys/timepps.h during the ./configure phase of compilation of the ntpd package. all that is required to get PPS working is to fetch the source package of ntpd for the distribution and recompile it while that single file has been added. e.g. on Ubuntu that file is present in the package pps-tools. So please, on your build systems, make sure that the package pps-tools or whatever other source used for timepps.h is installed during the compilation of ntpd. It makes the use of PPS much easier, as one does not have to find how to successfully compile a package from source on that particular system. And it will not be causing trouble when updates appear. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
