Re: [ntp:questions] Source address in response always the same as target address in request?
Danny Mayer wrote: If you want to send a reply back to a client how would you specify the outgoing local interface address? Even using sendmsg() you cannot do that if you want to use, for example, the wildcard socket. Don't forget this is UDP so it's connectionless and is a separate datagram each time. There are very few choices here. With TCP there is an established connection and you can reply on that connection. This is not the case here. That's my point. The socket interface does not provide a way to do something that is required to use the NTP protocol. The fact that the sockets API has existed for so long without that ability is my evidence that the requirement should not have been so lightly made. If the requirement was really so universal (as Dave suggested) as to not even need to be mentioned in the spec and just assumed, then I contend that the sockets API would have a way to easily meet that requirement. Which as you pointed out, it does not. -- blu You've added a new disk. Do you want to replace your current drive, protect your data from a drive failure or expand your storage capacity? - Disk management as it should be. -- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Rick Jones wrote: The NTP clock discipline will strive to zero the offset, but cannot correct for round trip asymmetry. Any individual offset measurement will contain a measurement error. That measurement error will be of the same magnitude as the measurement error you will get with your application. If you are interested in one way latency, you are interested in asymmetry! I think that in 99 cases out of 10 this would be run on a LAN where I have a decent expectation of symmetry :) Or at least the first places _I_ would be running it would be on a LAN :) Netperf can and does get run over WAN's where any hope of symmetry is out the window, but I'm willing to caveat that in the documentation. ... Is that need, Need, or NEED? Is there is a way to be good enough without having the dependence upon anything more than the two endpoints being sync'ed to the same time source? (Other than the same GPS constellation received independently by each via their own PPS pucks that is) well, I guess the point is, if you think it's going to be symmetric anyway (in your almost guaranteed sense), why not just simplify tremendously, run ping, and divide by 2? Otherwise, you'll have to use something like OWAMP and follow it's prerequisites. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Rick Jones [EMAIL PROTECTED] wrote: Here is what I have now that I've dropped the minpoll from the server and dropped LOCAL: peer bl480c2 minpoll 3 maxpoll 4 iburst server 10.208.0.1 iburst server 10.0.0.1 server 10.202.1.1 Scratch that - I commented-out the last two servers. rick jones -- a wide gulf separates what if from if only 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] time delta between clients
Per Hedeland [EMAIL PROTECTED] wrote: Did you lower the maxpoll on the server that is actually providing time to those two? Don't do that, it prevents ntpd from fine-tuning the disciplining of the system clock. insert sheepish yes answer here... Lowering it on the peer setup - which is not intended to provide time to either of those two hosts, and so could usefully have 'noselect' (if it is available in your version and works with peer, I haven't tried that) - is just so you can have a recent value for the offset. It would be a good idea to lose the LOCAL clock though, it's totally useless for your purpose. Here is what I have now that I've dropped the minpoll from the server and dropped LOCAL: peer bl480c2 minpoll 3 maxpoll 4 iburst server 10.208.0.1 iburst server 10.0.0.1 server 10.202.1.1 I just restarted that on both ends (adjusting peer accordingly) and will see how that settles-in. thanks, rick jones -- oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag 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] time delta between clients
Rick Jones wrote: Rick Jones [EMAIL PROTECTED] wrote: Here is what I have now that I've dropped the minpoll from the server and dropped LOCAL: peer bl480c2 minpoll 3 maxpoll 4 iburst server 10.208.0.1 iburst server 10.0.0.1 server 10.202.1.1 Scratch that - I commented-out the last two servers. rick jones I think you may have problems, even in the mythical zero-latency network, getting the skew consistently below double the clock tick of the system with the largest clock tick interval. With the skew you're looking for, you'd need systems with microsecond clock accuracy and resolution, and that probably means systems with one or another iterations on the way to the nano-kernel. -Tom ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNMP support
David, There are no plans that I know of for the reference implementation itself to support SNMP directly. There is an alternative that in fact was implemented for evaluation some years ago. It used an SNMP agent program to send mode-6 (ntpq) commands to an NTP server and translate what came back, then respond in the style of the MIB. That actually worked quite well, considering the limitations of SNMP. While that program is lost in the dust of time, it would not be too hard to re-create it. The hard part in the agent implementation was how to translate the episodic data from an NTP association into something a NOC engineer coul see on a meter or tally light. The attraction of the agent aproach was that the translation can be done by the agent without tinkering the NTP server in possibly ugly ways. An approach that saw action some years ago was to embed the translator in an expert system programmed in smalltalk, for example. The project was funded by DARPA not specifically for NTP monitoring, but for Internet NOCs in general. I just love that approach. Dave David J Taylor wrote: Does NTP include SNMP support (on Windows), and if not, are there any plans to add support? Thanks, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dimensioning NTP Server
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Aggarwal Vivek-Q4997C) writes: Aggarwal Hi Iam planning to have NTP Server for something around 50,000 Aggarwal Clients in the Network Is this a LAN or a WAN? Have you seen http://support.ntp.org/Support/DesigningYourNTPNetwork ? While I think 1 or 2 machines could handle the load (if the clients all started at the same time it would be fun for a little while), you will do better overall having at least several machines offering NTP service, both in terms of reliability and load. The machines you would need for this service should all be pretty inexpensive. And if you could write up your experience (or email it to me) I would appreciate it. -- Harlan Stenn [EMAIL PROTECTED] http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNMP support
Heiko, A couple of comments about this mission. First, last I looked SNMP had a really hard time with floating point and the scaling issues are dangerous. Second, as mentioned several times on the NTP hackers wire, we would very much like to shoot ntpdc and its fascist (mode 7) protocol. As of now, many configuration issues can be performed using the mode-6 (ntpq) protocol. While many ntpdc related issues can be easily moved to the mode-6 protocol, which is based on UDP, the monlist function of ntpdc really needs TCP, as experience with monlist and UDP demonstrates. This paritcular combination of UDP and TCP would not be friendly to SNMP. I continue to speculate that an SNMP agent in an expert system would be an ideal shotgun marriage between mode-6 and SNMP. Dave Heiko Gerstung wrote: David J Taylor schrieb: Heiko Gerstung wrote: David J Taylor schrieb: Does NTP include SNMP support (on Windows), and if not, are there any plans to add support? Thanks, David When the MIB for NTP has been standardized, I will try to write a module for net-snmp which supports that standard NTPv4 MIB. Our current NTP server appliances (like others on the market) already offer NTP related data objects in their enterprise MIB. The current draft can be found here: http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-mib-03.txt Best Regards, Heiko Heiko, I'm delighted to see this so well advanced, and even more delighted that we may even see an implementation! I would be after a Windows SNMP implementation which worked with MRTG and perhaps other reporting tools. A quick read suggests that you could get with SNMP everything which you can currently get from NTPQ, with the addition of optional notifications when things change. There is no other writeable input. Would that be a fair summary? Well, I would not go as far as promising that you will get every that NTPQ offers, but this was not the intention. We wanted to include as many data objects as required to be able to automatically monitor your NTP server instance(s) with your standard network management system a la HP Openview or IBM Tivoli or whatever. Besides the effort to produce an NTP module for NET-SNMP (which is AFAIK also available for Windows) it will be required to modify ntpd as well to provide an interface that can be used by the net-snmp module (or any other implementation). Using mode 6 / mode 7 packets will be working for most objects in the MIB, other parts require additional data collecting on ntpd's side (e.g. for the requests stats). It might be time to implement a new management interface for ntpd which probably could use TCP/123 instead of UDP, but I am not sure if everybody involved would be willing to go down that road. However, I see a demand for simplifying the health and statistics monitoring side of NTP. People often tend to say that NTPQ already offers all they need, but the core idea behind SNMP (IMHO) is that you need only one piece of software to monitor your routers, servers, printers, coffee machines and, yes, time servers. Since SNMP is to network monitoring what NTP is to network time synchronization (the de facto standard protocol), it is time to enable NTP to provide an SNMP interface. One day it might be even a way to replace ntpdc when it comes to runtime reconfiguration issues. This would overcome the current problems we see with ntpdc, mainly the tight relationship between ntpdc's and ntpd's version. But this would require to add more writable data objects and since this has a major implication on security, we will spare that until the definition of NTPv5's MIB :-) Cheers, Heiko ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Distribution security
Harlan, I don't want to pick a fight on this, but you told me offline that the html2man utility was imperfect and not appropriate to convert bulk NTP html pages to man pages. So, why is that utlity still in the distribution? It may yet be useful in many cases, but there needs to be a statement to that effect. Also reported offline, there is in fact an html page on the sntp progam, so the sntp man page is superfluous, especially if installed by default. I don't promote this as specific to UDel, but applicable everywhere. The sntp program included in the distribution itself has serious hazards and can be badly misused if certain program options are are enabled. The html page is carefully structured to avoid these hazards. In any case, the sntp program should be bansihed to a separate but supported distribution. On the options thing, whatever intricate facility you have installed creates four new files for each program. I tried to find what option letter coresponded to what obscure define in the ntp-keygen.c program and could not discover it. As result, the html documentation and the options list decodes are probably discordant. As I said many times, the official documentation should be in one place only and can be updated as necessary without creating little discords elsewhere. On the other hand, I have no objection and do encourage useful help as in the standard Unix command usage decodes. Dave Harlan Stenn wrote: Folks, I have privately followed up with Dave on his response. Anybody with a threaded newsreader (or access to one) should be easily able to find it, if they care that much. H ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
