Re: [ntp:questions] drift value very large and very unstable
"Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >Maarten Wiltink wrote: >> "David Woolley" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> >>>Danny Mayer wrote: >> >> We supply neither an ntp.conf file nor a startup file so this comment makes no sense. This kind of thing belongs in the Support wiki which > >> >> ISTM there are two things that would go into a default ntp.conf to be >> supplied by the current NTP developer effort: servers, and a drift file. >> >> For the drift file, I suspect the Filesystem Standard (whatever it's >> called these days) defines some place where it might usefully be put. > >File System Standard? What's that?? Unix tends to put things in more >or less standard places but it's not guaranteed that system A's file >system or directory naming will be compatible with system B. Once you that is why there is a proposed file system standard. Log files in /var/log/ntp say. Drift file in /etc/ntp.drift config file in /etc/ntp.conf >get out of the Unix-Linux arena nothing is guaranteed. Windows has its >own way of doing things. MacIntosh? It's Unix or Unix-like but I'm not >really familiar with it; I have had maybe two hours of Mac experience in >the last twentyfive years! OpenVMS has its own way, not compatible with >anything else of course. Can AIX read UFS or ZFS? Can Solaris read >whatever AIX uses? Sorry-- what has the filesystem got to do with anything? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] pool configuration directive on Windows
Danny, Understand. You guys have been wizards with the net interfaces. Real magic. I haven't heard anybody comment on IGMP and the need to replicate for the DVMRP spanning tree. Is that done by IGMP without NTP being involved? If so and multiple endpoints result, Autokey would surely scream. You may notice in the fog of war that Autokey names potentially can replace the IP addresses. Need to work on that... Dave Danny Mayer wrote: > David L. Mills wrote: > >>Danny, >> >>The specific accusation directed to me personally was about the notrust >>bit, which change I described in my previous message. I hadn't noticed >>the L option change, which was not by my hand. >> > > > Well it might well have been me since I have touched that code a number > of times. I'm intending to get rid of it as soon as Harlan and I have > agreement on the syntax of the changes. This will implement listen-on > and query-on directives in the configuration file to allow the admins to > have control over exactly what addresses and interfaces to use to > receive and transmit NTP packets. I already have working code for this. > We just have details to resolve. > > Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] pool configuration directive on Windows
David L. Mills wrote: > Danny, > > The specific accusation directed to me personally was about the notrust > bit, which change I described in my previous message. I hadn't noticed > the L option change, which was not by my hand. > Well it might well have been me since I have touched that code a number of times. I'm intending to get rid of it as soon as Harlan and I have agreement on the syntax of the changes. This will implement listen-on and query-on directives in the configuration file to allow the admins to have control over exactly what addresses and interfaces to use to receive and transmit NTP packets. I already have working code for this. We just have details to resolve. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift value very large and very unstable
Maarten Wiltink wrote: > "David Woolley" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >>Danny Mayer wrote: > > >>>We supply neither an ntp.conf file nor a startup file so this comment >>>makes no sense. This kind of thing belongs in the Support wiki which > > ISTM there are two things that would go into a default ntp.conf to be > supplied by the current NTP developer effort: servers, and a drift file. > > For the drift file, I suspect the Filesystem Standard (whatever it's > called these days) defines some place where it might usefully be put. File System Standard? What's that?? Unix tends to put things in more or less standard places but it's not guaranteed that system A's file system or directory naming will be compatible with system B. Once you get out of the Unix-Linux arena nothing is guaranteed. Windows has its own way of doing things. MacIntosh? It's Unix or Unix-like but I'm not really familiar with it; I have had maybe two hours of Mac experience in the last twentyfive years! OpenVMS has its own way, not compatible with anything else of course. Can AIX read UFS or ZFS? Can Solaris read whatever AIX uses? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift value very large and very unstable
David Woolley wrote: > Danny Mayer wrote: > >> We supply neither an ntp.conf file nor a startup file so this comment >> makes no sense. This kind of thing belongs in the Support wiki which >> is constantly updated. > > > You need to supply both. Otherwise the packagers will do it for you and > they will get it wrong. Anybody who runs a "packaged" configuration deserves whatever happens to him. Windows comes configured to use time.windows.com. AFAIK that's operated by Microsoft and it's not a problem. RedHat comes preconfigured to use servers provided by RedHat. That's not a problem either. Neither Microsoft nor RedHat can, or does, guarantee that the canned configuration will work well for you! Further, the NTP developers/packagers/whatever have no idea where you will be running your system or what your requirements will be. A configuration that's perfect for a system in Dover, Delaware, will be garbage if used in a system in Tokyo! Any canned configuration should be treated as an example. The ultimate user needs to pick his own servers, his own security, his own locations for log files, etc, etc. If you need a configuration you can depend on, you have a responsibility to think about the problem and develop a configuration that meets *your* needs! I believe that the developers have met their responsibility by providing documentation that tells you how to "roll your own" configuration. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift value very large and very unstable
"David Woolley" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Danny Mayer wrote: >> We supply neither an ntp.conf file nor a startup file so this comment >> makes no sense. This kind of thing belongs in the Support wiki which >> is constantly updated. > > You need to supply both. Otherwise the packagers will do it for you > and they will get it wrong. ISTM there are two things that would go into a default ntp.conf to be supplied by the current NTP developer effort: servers, and a drift file. For the drift file, I suspect the Filesystem Standard (whatever it's called these days) defines some place where it might usefully be put. For the servers, we have the Pool. We still _want_ that to be used, right? Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
"David Woolley" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Maarten Wiltink wrote: >> [...] The server part would >> assume or require that the clock is being disciplined by a client >> implementation. > > It needs to share rather more than the clock. Things like: > > stratum > root distance > root dispersion > system peer > local reference time > leap bits > etc. Yes. Those are all client-part statistics that could easily be made available to a server-part for dishing out to anyone interested in evaluating the status and quality indicators of your server. As part of _requiring_ that the clock be disciplined by an NTP client part. You're not going to trust that; you're going to check it. Of course there is overhead in having the server part query for the client part's statistics, and transferring them. That's not the point. Nor do I have any illusions about any of this ever happening. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Maarten Wiltink wrote: > > This _is_ what I'd call the 'client part'. The server part would > assume or require that the clock is being disciplined by a client > implementation. It needs to share rather more than the clock. Things like: stratum root distance root dispersion system peer local reference time leap bits etc. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift value very large and very unstable
Danny Mayer wrote: > We supply neither an ntp.conf file nor a startup file so this comment > makes no sense. This kind of thing belongs in the Support wiki which is > constantly updated. You need to supply both. Otherwise the packagers will do it for you and they will get it wrong. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Maarten Wiltink <[EMAIL PROTECTED]> wrote: > I'm no IP wizard, but isn't there a SO_REUSEPORT flag or something > like that? It still (IIRC) lacks sufficient ubiquity and the semantics on the various platforms may not match what is desired. rick jones -- denial, anger, bargaining, depression, acceptance, rebirth... where do you want to be today? these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
"Steve Kostecke" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [...] > Currently NTP uses port 123/UDP for both the source and destination > port. What you are proposing would require the use of a different source > port to work on a single-homed host. This would result in a DOS when > polling a server that enforces the NTP port. I'm no IP wizard, but isn't there a SO_REUSEPORT flag or something like that? Anyway, I frankly doubt that requiring a specific source port is still a good thing. Dit it ever accomplish anything above testing that the sender has root on the remote machine? By now, it mostly serves to chase off innocent NATted clients. > Another thing to consider is the fact that you would now have two > processes which both require high priority access to the system clock. I can see how that would be a party killer. But the current, monolithic NTP can't discipline the clock and answer polls at the exact same time, either. The obvious choice would be to give the client part priority over the server part. Things might actually get *better*. >> [...] Decoupling always adds complexity at the interface. But as a >> software guy I appreciate the focus it adds to the decoupled modules. [...] > I'd point out that the source is available for anyone to modify, but > that statement seems to interpreted as an attempt to stifle discussion. Well, I appreciate the source being available and all, but unfortunately I already have a hobby to take up six nights a week. Plus, while patches might be accepted, I doubt that a major rewrite of the entire codebase would. Sorry. Sometimes I wish I were still twenty-two and had the patience to do it, and the perseverence to get it changed. At thirty- seven, all I have left is the questionable sideline-based wisdom to see room for improvement. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Too much offset from GPS?
On 2008-03-11, Unruh <[EMAIL PROTECTED]> wrote: > Steve Kostecke <[EMAIL PROTECTED]> writes: > >>The key detail here, which you overlooked in your haste, is the price >>differential between a ~$70 GPS suitable for timing and a ~$250 >>suitable for geocaching. > > The key detail which you overlooked is that you quoted the price for > the 18USB, not the 18LVC, That's the default price which appears on the GPS 18 OEM page. >which could have confused the OP. Really? > The USB version is useless for timing. It is ONLY the LVC which can be > used for timing. You're preaching to the choir. There's a reason why I own a GPS18 _LVC_. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
Steve Kostecke wrote:
> FWIW: ntpdc is version specific and it's use has been discouraged on
> more than one occasion.
FWIW: I routinely use ntpdc to add/remove associations ('addserver' and
'unconfig') and to fudge time1 values. It seems to work fine for those
purposes. Before using it, however, I would recommend patching it with the
patch described by myself here:
http://bugs.ntp.org/1003
Dennis
--
Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com
NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Too much offset from GPS?
Steve Kostecke <[EMAIL PROTECTED]> writes: >On 2008-03-11, Unruh <[EMAIL PROTECTED]> wrote: >> Steve Kostecke <[EMAIL PROTECTED]> writes: >> >>>The USD249.99 GPSMAP 60 is a mapping receiver. >> >>>The USD74.50 GPS18 LVC is a timing receiver. >> >> 68.50 >The exact price is irrelevant. >The key detail here, which you overlooked in your haste, is the >price differential between a ~$70 GPS suitable for timing and a ~$250 >suitable for geocaching. The key detail which you overlooked is that you quoted the price for the 18USB, not the 18LVC, which could have confused the OP. The USB version is useless for timing. It is ONLY the LVC which can be used for timing. >>You are quoting the USB which is useless for timing. >I quite clearly wrote "GPS18 LVC". Again, the exact MSRP is not the >point here. No but the exact model is, and while you mentioned LVC your price was USB, and the OP could have thought that the USB was equivalent. It is not. >-- >Steve Kostecke <[EMAIL PROTECTED]> >NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
On 2008-03-11, Maarten Wiltink <[EMAIL PROTECTED]> wrote: > "Steve Kostecke" <[EMAIL PROTECTED]> wrote in message > >> There is considerable overlap between an "NTP Client" and an "NTP >> Server". >> >> "NTP Clients" and "NTP Servers" both: >> >> 1. Poll time sources (e.g. "NTP Servers", ref-clocks) >> 2. Discipline the system clock > > This _is_ what I'd call the 'client part'. The server part would > assume or require that the clock is being disciplined by a client > implementation. The main functional difference between an ntpd which is operating as an "NTP Client" and one operating as an "NTP Server" is that latter receives polls from clients, time stamps them and sends them back. Currently NTP uses port 123/UDP for both the source and destination port. What you are proposing would require the use of a different source port to work on a single-homed host. This would result in a DOS when polling a server that enforces the NTP port. Another thing to consider is the fact that you would now have two processes which both require high priority access to the system clock. >> 3. Utilize NTP Authentication > > You may have a point there. But I have a feeling that they use it > differently, one as a client and one as a server. (No surprise there.) NTP Authentication authenticates the server to the client. So that code is going to be used, albeit somewhat differently, by both ends of an authenticated association. >>> The objection when raised earlier was that the server may be asked >>> for statistics about things that happen in the client; ISTM this >>> could be solved. >> >> By adding another layer of complexity ... > > Yes. Decoupling always adds complexity at the interface. But as a > software guy I appreciate the focus it adds to the decoupled modules. That would make sense of there was a substantial difference between the modules. In this case I doubt that the difference is all that great. I'd point out that the source is available for anyone to modify, but that statement seems to interpreted as an attempt to stifle discussion. So I ... oops >>> Also, the much-sought feature of re-resolving dried up associations >>> could be done from a cron job with ntpq/ntpdc. Determining for certain >>> what configuration to use might be a problem. >> >> A 're-resolve' command in ntpq would be useful. > > I don't have the details handy, but aren't there already commands to > remove and create associations? Probably only in ntpdc, though. 'addserver' & 'unconfig' are currently available only in ntpdc. FWIW: ntpdc is version specific and it's use has been discouraged on more than one occasion. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Default config on Ubuntu doesn't work as client
Maarten Wiltink wrote: > "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > [...] > >>My experience with VMWare is limited to VMWare ESX. With ESX all you >>need to do is to log in as root, edit ntp.conf to include your favorite >>servers, start ntpd and enjoy. > > > Is that the free one? (The free one is what I have at home. It's free.) > > With the free version, you have to install the VMware tools in every > client, and enable 'Time synchronization between the virtual machine > and the host operating system' on the options tab. (This is on a Windows > client.) > > Groetjes, > Maarten Wiltink > > I don't think the ESX version is free! My employer at that time bought a copy. We installed it on a server and ran two or three virtual machines on it. I configured NTP on it. This was ca. 2003. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Too much offset from GPS?
On 2008-03-11, Unruh <[EMAIL PROTECTED]> wrote: > Steve Kostecke <[EMAIL PROTECTED]> writes: > >>The USD249.99 GPSMAP 60 is a mapping receiver. > >>The USD74.50 GPS18 LVC is a timing receiver. > > 68.50 The exact price is irrelevant. The key detail here, which you overlooked in your haste, is the price differential between a ~$70 GPS suitable for timing and a ~$250 suitable for geocaching. >You are quoting the USB which is useless for timing. I quite clearly wrote "GPS18 LVC". Again, the exact MSRP is not the point here. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
On 2008-03-11, Johnson, John-P63914 <[EMAIL PROTECTED]> wrote: > I realize that what I am trying to do is very easily accomplished with > one instance of ntpd. However, I assure you that the manner in which I > am trying to accomplish it is absolutely necessary for my particular > application. Can you tell us why this is so? -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
[EMAIL PROTECTED] (Johnson, John-P63914) writes: >> One instance of ntpd is all that is necessary to perform both of these >> tasks at the same time. >I realize that what I am trying to do is very easily accomplished with >one >instance of ntpd. However, I assure you that the manner in which I am >trying to accomplish it is absolutely necessary for my particular >application. Uh, and we believe you why? It is very hard to imagine a situation where what you want is "absolutely necessary". >I found a definitive answer in the code. >ntp_io.c, line 1232 >/* > * Check to see if we are going to use the interface > * If we don't use it we mark it to drop any packet > * received but we still must create the socket and > * bind to it. This prevents other apps binding to it > * and potentially causing problems with more than one > * process fiddling with the clock > */ >This explains why an instance was still receiving packets from an >interface >that was not specified with '-I'. >Thank you very much for the help. >Cheers >Johnny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
> One instance of ntpd is all that is necessary to perform both of these > tasks at the same time. I realize that what I am trying to do is very easily accomplished with one instance of ntpd. However, I assure you that the manner in which I am trying to accomplish it is absolutely necessary for my particular application. I found a definitive answer in the code. ntp_io.c, line 1232 /* * Check to see if we are going to use the interface * If we don't use it we mark it to drop any packet * received but we still must create the socket and * bind to it. This prevents other apps binding to it * and potentially causing problems with more than one * process fiddling with the clock */ This explains why an instance was still receiving packets from an interface that was not specified with '-I'. Thank you very much for the help. Cheers Johnny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] [NOT SOLVED] Default config on Ubuntu doesn't work as client
On Tue, 11 Mar 2008 07:30:20 + David Woolley <[EMAIL PROTECTED]> wrote: > I don't know how VMWare handles the TSC, but unless it handles it in a > away intended for real time measurement, rather than CPU usage > measurement the calibration may be run at a time that doesn't match > average conditions. If that theory is correct, you need to disable TSC > as a time source. Well I have no idea what you just said but I suppose it means that the problem isn't really "SOLVED" after all. And I just rebooted and the time is off again so I wonder if iburst is really sufficient for a robust solution. For posterity I wanted to see if installing VMWare tools made a difference (I bet it does) but after downloading gcc and 45MB of kernel source it wanted me to build the kernel and that's where I throw in the towel (the Linux kernel guys really need to figure out how to make symbol versioning more forgiving). And of course all of this says nothing about the default ntp.conf on Ubuntu. I suspect it does in fact work and that the problem is just VMWare Server (the "free" one, not ESX). Mike ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Default config on Ubuntu doesn't work as client
"Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] [...] > My experience with VMWare is limited to VMWare ESX. With ESX all you > need to do is to log in as root, edit ntp.conf to include your favorite > servers, start ntpd and enjoy. Is that the free one? (The free one is what I have at home. It's free.) With the free version, you have to install the VMware tools in every client, and enable 'Time synchronization between the virtual machine and the host operating system' on the options tab. (This is on a Windows client.) Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
"Steve Kostecke" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 2008-03-11, Maarten Wiltink <[EMAIL PROTECTED]> wrote: >> As a software guy, I've wondered before about the monolithic nature of >> the NTP package. Splitting it into a client and server part might make >> some people (think OpenBSD) very happy. > > There is considerable overlap between an "NTP Client" and an "NTP > Server". > > "NTP Clients" and "NTP Servers" both: > > 1. Poll time sources (e.g. "NTP Servers", ref-clocks) > 2. Discipline the system clock This _is_ what I'd call the 'client part'. The server part would assume or require that the clock is being disciplined by a client implementation. > 3. Utilize NTP Authentication You may have a point there. But I have a feeling that they use it differently, one as a client and one as a server. (No surprise there.) [...] >> The objection when raised earlier was that the server may be asked for >> statistics about things that happen in the client; ISTM this could be >> solved. > > By adding another layer of complexity ... Yes. Decoupling always adds complexity at the interface. But as a software guy I appreciate the focus it adds to the decoupled modules. >> Also, the much-sought feature of re-resolving dried up associations >> could be done from a cron job with ntpq/ntpdc. Determining for certain >> what configuration to use might be a problem. > > A 're-resolve' command in ntpq would be useful. I don't have the details handy, but aren't there already commands to remove and create associations? Probably only in ntpdc, though. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Too much offset from GPS?
Steve Kostecke <[EMAIL PROTECTED]> writes: >On 2008-03-11, chowalit.lab Chowalit Lab Linux <[EMAIL PROTECTED]> wrote: >> So It's wrong on my GPS (GPSmap60). >The problem with the GPSMAP 60 is that it is the wrong type of GPS >receiver for an application which needs highly stable time. >There are two types of GPS receivers: mapping and timing. >The key difference between these two type of receivers is that the >timing receivers provide a Pulse Per Second (PPS) output which is >typically aligned to within 1 microsecond (0.01 sec) of UTC time. >Higher quality timing receivers may be capable of closer (e.g. >nanosecond) alignment. >Both types of receivers are able to emit NMEA sentences via a serial or >USB interface. These NMEA sentences are emitted when the receiver is >not busy doing other things such as processing satellite data, updating >the display, etc., and can occur at _any_ _time_ during second they are >valid for. Time sources utilizing only NMEA sentences are not suitable >for a Stratum 1 time server. >It is up to you to decide if the GPSMAP 60 is good enough for your >requirements. >The USD249.99 GPSMAP 60 is a mapping receiver. >The USD74.50 GPS18 LVC is a timing receiver. 68.50 You are quoting the USB which is useless for timing. >GPSMAP 60 >https://buy.garmin.com/shop/shop.do?pID=224&tab=gpsmap60#specsTab >GPS 18 OEM >https://buy.garmin.com/shop/shop.do?cID=158&pID=223 MAKE SURE you get the LVC, not the PC or USB version. Only the LVC is useful for timing. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Too much offset from GPS?
[EMAIL PROTECTED] (chowalit.lab Chowalit Lab Linux) writes: >Thanks all, > So It's wrong on my GPS (GPSmap60). Oh... So If I still use this >GPS I should add offset with fudge option. Can I get other source from >this GPS? No idea what you are asking. GPS without a PPS (Pulse per Second) option CANNOT ever give very good timing accuracy. Ever. It sends the signal down a serial line ( which takes many many milliseconds) and does so somewhat randomly. Ie, it is good for maybe 1/10 second accuracy, but you should not trust it for more. IF you want better, get a gps with a PPS output (the standard is the Garmin 18LVC which needs a bit of soldering to set up for your system) and you can get microsecond accuracy. You gps is good for navigating with. Use it for what it is good for. >Thank Again >Chong >On Sat, Mar 8, 2008 at 10:46 PM, Unruh <[EMAIL PROTECTED]> wrote: >> isw <[EMAIL PROTECTED]> writes: >> >> >In article <[EMAIL PROTECTED]>, >> > Unruh <[EMAIL PROTECTED]> wrote: >> >> >> Steve Kostecke <[EMAIL PROTECTED]> writes: >> >> >> >> >On 2008-03-07, Hal Murray wrote: >> >> >> >> >>ATTRIBUTION MISSING wrote: >> >> >> >> >> >>>I have problem with my stratum1 box. My box include: freebsd >> >> >>>5.2-RELEASE without PPS , ntp-4.2.0_1, Intel Pentium III, 40 G IDE, >> >> >>>Germin GPSmap60 , connect with serial com. In GPSmap60 set as NMEA. >> >> >>>Freebsd box can get NMEA input string. My configuration of ntp.conf >> >> >>>like this: >> >> >>> >> >> >>>server 127.127.20.0 mode 1 prefer minpoll 4 >> >> >>>server 127.127.1.0 minpoll 5 >> >> >> >> >> >> Most NMEA devices (or at least all the ones I've worked with) >> >> >> send their text with a significant offset. >> >> >> >> >It gets even better ... NMEA sentences are output by the GPS device >> >> >when it is not busy. This means that there is no fixed relationship >> >> >between the top of the second and the NMEA sentence. And there will be >> >> >significant jitter. >> >> >> >> Ie, NMEA is good for getting the second, not for getting any better >> >> accuracy (well maybe 1/10 sec) If you want accurate time get a gps with >> >> PPS >> >> output. >> >> Otherwise there is no advantage of NMEA over a network ntp connection. >> >> >Well, except for the "no wires" part... >> >> Then buy a gps with ppm. The GPS18LVC is only about $60. And you get >> microsecond accuracy rather than 1/10 sec. >> >> >> >> >Isaac >> >> ___ >> questions mailing list >> questions@lists.ntp.org >> https://lists.ntp.org/mailman/listinfo/questions >> ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] May sound like a newbe question, but....
VFikov <[EMAIL PROTECTED]> wrote: > The problem is simple: A big building, about 350-400 Windows XP PCs, > and 2 Linux servers not only for NTP, but for it too... Now today, on > my laptop I had to edit the registry of the XP, so it could sync with > the NTP. Does some one have an idea, how to skip the registry editing, > and may be edit the servers configuration ... So I will not have to go > to every PC and start the reg file I made ... > Please if someone know how to make the damn Windows sync with the > NTPs, it would be great.. :) If you just want to adjust the server they contact for syncing (and not the other settings) you could modify the local dns (if you control that) to make 'time.windows.com' point to your local timeserver. Koos van den Hout -- Koos van den Hout, herding Suns and networks as [EMAIL PROTECTED] +31-30-2534104 PGP keyid 0x27513781 http://idefix.net/~koos/Use PGP when possible! Weather maps from free sources at http://weather.idefix.net/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Too much offset from GPS?
On 2008-03-11, chowalit.lab Chowalit Lab Linux <[EMAIL PROTECTED]> wrote: > So It's wrong on my GPS (GPSmap60). The problem with the GPSMAP 60 is that it is the wrong type of GPS receiver for an application which needs highly stable time. There are two types of GPS receivers: mapping and timing. The key difference between these two type of receivers is that the timing receivers provide a Pulse Per Second (PPS) output which is typically aligned to within 1 microsecond (0.01 sec) of UTC time. Higher quality timing receivers may be capable of closer (e.g. nanosecond) alignment. Both types of receivers are able to emit NMEA sentences via a serial or USB interface. These NMEA sentences are emitted when the receiver is not busy doing other things such as processing satellite data, updating the display, etc., and can occur at _any_ _time_ during second they are valid for. Time sources utilizing only NMEA sentences are not suitable for a Stratum 1 time server. It is up to you to decide if the GPSMAP 60 is good enough for your requirements. The USD249.99 GPSMAP 60 is a mapping receiver. The USD74.50 GPS18 LVC is a timing receiver. GPSMAP 60 https://buy.garmin.com/shop/shop.do?pID=224&tab=gpsmap60#specsTab GPS 18 OEM https://buy.garmin.com/shop/shop.do?cID=158&pID=223 > Oh... So If I still use this GPS I should add offset with fudge > option. You may correct (i.e. fudge) the approximate offset but not the massive jitter inherent in the NMEA sentence(s). You also should enable only one of the NMEA sentences to reduce the receiver's workload. >Can I get other source from this GPS? No. The GPSMAP 60 is not a timing receiver and does not provide a PPS signal. -- Steve Kostecke <[EMAIL PROTECTED]> NTP Public Services Project - http://support.ntp.org/ ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
On 2008-03-11, Maarten Wiltink <[EMAIL PROTECTED]> wrote:
> "Steve Kostecke" <[EMAIL PROTECTED]> wrote in message
>
>> John Johnson wrote:
>>
>>> Now, is what I am trying to do feasible?
>>
>> One ntpd is all you need.
>
> I think you must be using a different definition of the word
> 'feasible' from everybody else.
Here's one:
| From WordNet (r) 2.0 (August 2003) [wn]:
|
| feasible
| adj : capable of being done with means at hand and circumstances
| as they are [syn: {executable}, {practicable},
| {viable}, {workable}]
| adv : in a practicable manner; so as to be feasible [syn:
| {practicably}]
> As a software guy, I've wondered before about the monolithic nature of
> the NTP package. Splitting it into a client and server part might make
> some people (think OpenBSD) very happy.
There is considerable overlap between an "NTP Client" and an "NTP
Server".
"NTP Clients" and "NTP Servers" both:
1. Poll time sources (e.g. "NTP Servers", ref-clocks)
2. Discipline the system clock
3. Utilize NTP Authentication
"NTP Servers" also:
1. Reply to polls from "NTP Clients" and other "NTP Servers"
> The objection when raised earlier was that the server may be asked for
> statistics about things that happen in the client; ISTM this could be
> solved.
By adding another layer of complexity ...
> Also, the much-sought feature of re-resolving dried up associations could
> be done from a cron job with ntpq/ntpdc. Determining for certain what
> configuration to use might be a problem.
A 're-resolve' command in ntpq would be useful.
--
Steve Kostecke <[EMAIL PROTECTED]>
NTP Public Services Project - http://support.ntp.org/
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Default config on Ubuntu doesn't work as client
Maarten Wiltink wrote: > "Michael B Allen" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > >>[...] Could the fact that Ubuntu is running in VMWare Server be a problem? > > > Yes. Very much so. Install the VMWare tools and let the virtual machine > host control the passage of time on the clients. Only run NTP on the > host machine. > > There's a whitepaper somewhere. It boils down to 'Virtual machines are > not suited to real-time software. Let the host control time, it will > do a better job.' > > Time synchronisation in the clients is off by default, and they _will_ > drift. I have two old Linux machines now virtualised, both without VMWare > tools installed. With adjtimex I managed to get one below 1PPM and it > now steps half a second each week; for the other one (kernel 2.0) I > didn't find or compile an adjtimex yet and it steps 2.5 seconds each > day. > > Groetjes, > Maarten Wiltink > > My experience with VMWare is limited to VMWare ESX. With ESX all you need to do is to log in as root, edit ntp.conf to include your favorite servers, start ntpd and enjoy. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift value very large and very unstable
Danny Mayer wrote: > Richard B. Gilbert wrote: > > >>A comment in ntp.conf and/or the startup file, explaining WHY stepping >>is enabled should go a long way toward solving the "dumbass" problem. > > > We supply neither an ntp.conf file nor a startup file so this comment > makes no sense. This kind of thing belongs in the Support wiki which is > constantly updated. > > Danny I didn't mean to suggest that you did or should! I intended to suggest that the OP or anyone else with the same or a similar problem should put the comment is HIS ntp.conf and or startup script. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] pool configuration directive on Windows
Harlan, What you see from me is what you get. How you incorporate it in whatever archive you maintain is at your convenience. Dave Harlan Stenn wrote: In article <[EMAIL PROTECTED]>, "David L. Mills" <[EMAIL PROTECTED]> writes: > > > David> While I don't maintain the changelog, it would seem a simple matter > David> to paste my hackers announcements to the changelog. > > Dave, > > The ChangeLog entries are, by design, short. Under 1 line long. > > The distribution process also produces a CommitLog, which contains the > details of every commit. The CommitLog file is part of every rolled > tarball. > > Since you do not use the revision control system, I commit your changes. > There are some problems with this approach: > > - often your changes are part of an ongoing effort and I do not have > sufficient information (or understanding) of the intricate details of > what any given set of changes do, so I cannot easily identify exactly > changes have been made for that particular -dev release. > > - your "wrap up" email usually happens after the commit, and includes > information that frequently spans a number of previous commits. > > I will see what I can to do get your "wrap up" email messages added to the > CommitLog file. This will probably mean that your wrap-up changes will be > in, say the ...p123 release, and when I incorporate your "wrap up" message > there will be a ...p124 release where the only difference between p123 and > p124 is that the latter includes the CommitLog file containing your "wrap > up" notes. > > With the exception of your email messages that describe your changes, all of > the information Martin has asked for is in the CommitLog file. But it can > be buried in a lot of other detail. > > I'm open to suggestions on how to make improvements in this beast, and I > would prefer solutions that do not involve a "step backwards" in any areas. > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] drift value very large and very unstable
Richard B. Gilbert wrote: > A comment in ntp.conf and/or the startup file, explaining WHY stepping > is enabled should go a long way toward solving the "dumbass" problem. We supply neither an ntp.conf file nor a startup file so this comment makes no sense. This kind of thing belongs in the Support wiki which is constantly updated. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] 1 Machine, 2 NICs, 2 Instances of ntpd; Possible?
"Steve Kostecke" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > John Johnson wrote: [...] >> Now, is what I am trying to do feasible? > > No. > > One ntpd is all you need. I think you must be using a different definition of the word 'feasible' from everybody else. As a software guy, I've wondered before about the monolithic nature of the NTP package. Splitting it into a client and server part might make some people (think OpenBSD) very happy. The objection when raised earlier was that the server may be asked for statistics about things that happen in the client; ISTM this could be solved. Also, the much-sought feature of re-resolving dried up associations could be done from a cron job with ntpq/ntpdc. Determining for certain what configuration to use might be a problem. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Default config on Ubuntu doesn't work as client
"Michael B Allen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [...] Could the fact that Ubuntu is running in VMWare Server be a problem? Yes. Very much so. Install the VMWare tools and let the virtual machine host control the passage of time on the clients. Only run NTP on the host machine. There's a whitepaper somewhere. It boils down to 'Virtual machines are not suited to real-time software. Let the host control time, it will do a better job.' Time synchronisation in the clients is off by default, and they _will_ drift. I have two old Linux machines now virtualised, both without VMWare tools installed. With adjtimex I managed to get one below 1PPM and it now steps half a second each week; for the other one (kernel 2.0) I didn't find or compile an adjtimex yet and it steps 2.5 seconds each day. Groetjes, Maarten Wiltink ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] [SOLVED] Default config on Ubuntu doesn't work as client
Michael B Allen wrote: > The following config works: > > driftfile /var/lib/ntp/ntp.drift > server 192.168.2.15 iburst > > The clock was sync'd in a matter of seconds. > > I kinda figured it would work since I have other servers that use it > and I've asked about this on this list before and was told that the > above was the minimum client config. I was just intrigued that Ubuntu It's not minimum; it includes some, but not all, of the optional things that are considered best current practice (it doesn't contain 4 servers, which is the other common BCP requirement). Given that your drift rate is ppm and ntpd needs it to be somewhat less than 500ppm, I suspect you are getting a continuous sequence of steps and you just happened to look after a step (and iburst is allowing it to actually get a time measurement fast enough that it does exceed 128ms before the time is measured. I don't know how VMWare handles the TSC, but unless it handles it in a away intended for real time measurement, rather than CPU usage measurement the calibration may be run at a time that doesn't match average conditions. If that theory is correct, you need to disable TSC as a time source. > could ship with a default config that didn't actually work and wanted to > see if someone could pinpoint why. I have a feeling there are a lot of > Ubuntu users out there who think their clocks are syncing when in fact > they're not. > > Thanks for the entertainment, > Mike ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Default config on Ubuntu doesn't work as client
Michael B Allen wrote: > Ninty minutes later the time is ahead of the time server by 36 seconds. That drift rate is uncorrectable by ntpd. (It may step repeatedly,) Normally this would indicate a seriously broken motherboard, although, in this case, it may be software related, particularly if any other virtual machine is trying to control the clock. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
