Re: [ntp:questions] time delta between clients
In article [EMAIL PROTECTED] Tom Smith [EMAIL PROTECTED] writes: Per Hedeland wrote: In article [EMAIL PROTECTED] [EMAIL PROTECTED] (Danny Mayer) writes: Per Hedeland wrote: In article [EMAIL PROTECTED] Tom Smith [EMAIL PROTECTED] writes: 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. Hm, if you were a newbie here, I'd assume that you simply don't know what you're talking about, but since you aren't, I must be misunderstanding you as you appear to be saying that two Unix hosts with the traditional 100 Hz clock (on the same LAN) couldn't achieve a skew consistently below 20 ms - while (at least) sub-millisecond offsets in such setups are commonplace and discussed here every other day. Apparently not even Windows has the kind of problem you suggest anymore. While Rick may be a relative newbie to NTP he has had years of conducting performance analysis of applications and systems. His performance testing of BIND9 is probably *the* seminal reference on DNS testing. Uh, your point being? I'm sure your description is correct even though I have no knowledge of that subject (which doesn't seem to be relevant here), and I specifically said that I *didn't* consider Rick a newbie to NTP - based on the very limited knowledge of *that* subject that I have, namely past postings in this forum. Which is why I found his statement surprising, and assumed that I must be misunderstanding it. Are you saying that you agree with that statement? Or maybe you can explain how I'm misunderstanding it? Well, lets see if we can reduce the confusion a little. ;-) Rick (Jones) is the author of netperf. He deals with quite a large number of platforms, releases of those platforms, and combinations thereof. Tom (Smith) happens to work for the same company as Rick, also deals with quite a large number of platforms, releases, combinations, and with customers with large heterogeneous and problematic NTP networks, among other things. Per's question was to Tom's comment, not Rick's, and Tom's comment was to Rick, not Per. I imagine Rick may be just sitting on the sidelines scratching his head at this point wondering what he did wrong. Thanks for that - I actually knew that I was responding to Tom initially:-), and will blame Danny's message (which then seems even more pointless) for making me mix up the names...:-) Now I'm just wondering if Tom Smith at alum.mit.edu is the same person as Tom Smith at cag.zko.hp.com?:-) Well, I guess I'm also still wondering whether the latter is actually saying that it won't be possible to get the skew below 20 ms with Unix hosts with 100Hz clocks, but it's not really important - the important thing is that such a statement (if made) is not correct. --Per Hedeland [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Per Hedeland wrote: Well, I guess I'm also still wondering whether the latter is actually saying that it won't be possible to get the skew below 20 ms with Unix hosts with 100Hz clocks, but it's not really important - the important thing is that such a statement (if made) is not correct. Well, first I missed it if Rick said he was exclusively concerned about UNIX hosts. Second, if you check, my comment was also not exclusively about UNIX hosts, nor about the nominal clock frequency, but about the clock resolution, or minimum increment from, for example, gettimeofday(). With those thoughts in mind, yes, the comment stands that the skew that can be held between any 2 hosts depends on the clock resolutions of the 2 hosts and this ranges up to 15-16 milliseconds for some and up to 1 millisecond even for some UNIX systems. Since Rick is concerned about differentiating delays in the 10s of microseconds over a relatively short test time, this might be of some importance to him. -Tom ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Is there a windows clock program that updates it's display with sub second accuracy?
Every clock program or display tried with XP seems to update at somewhat random intervals. Some updates will be a second or more slow and other wont be quite as much. Is there something out there that will display something closer to the system clock that's being maintained via NTP? Realistically I probably don't need a display that's perfect but sometimes it's fun to be a little better than good enough. :) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Why false tickers one day, and not the next day?
[EMAIL PROTECTED] wrote: On Dec 17, 9:04 pm, [EMAIL PROTECTED] (Hal Murray) wrote: I think something in that area was fixed a while ago, but I don't remember the details and I could easily be wrong. I'm pretty sure you aren't the first person to ask a question like that. What version of ntpd are you using? Can you easily upgrade to a recent ntp-dev? I've been running 4.2.0. I just built 4.2.4 and I will see how that works. Have you seen that more than once? Yes, numerous times. One thing I would recommend is that you change your configuration: Node-A's ntp.conf: server 210.173.160.27 # external NTP server server node-B iburst # other node server 127.127.1.1 fudge 127.127.1.1 stratum 9 driftfile /etc/ntp.drift Node-B's ntp.conf: server 210.173.160.27 # external NTP server server node-A iburst # other node server 127.127.1.1 fudge 127.127.1.1 stratum 11 driftfile /etc/ntp.drift You are pointing to a single external server AND the other node as a server. In this kind of configuration you should use peer for the other server. Nominally this is a two server configuration which is the worst sort. In reality you have only one but it has no way of telling that. What I would recommend is to have 3 external servers and peer for the other node: peer node-B iburst and it should work the way you expect. peers expect to work at the same stratum. Try that and let us know. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Is there a windows clock program that updates it's display with sub second accuracy?
Ryan * wrote: Every clock program or display tried with XP seems to update at somewhat random intervals. Some updates will be a second or more slow and other wont be quite as much. Is there something out there that will display something closer to the system clock that's being maintained via NTP? Realistically I probably don't need a display that's perfect but sometimes it's fun to be a little better than good enough. :) Ryan, My Tiny Ben (as opposed to Big Ben) program should be within about 100msec or so. http://www.david-taylor.myby.co.uk/software/disk.html#TinyBen Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Resolving Hostnames
David Woolley wrote: allowing the load to evenly distribute among the servers in the pool. In this case the client will send NTP requests to the same host but get NTP responses from physically different servers. All servers in the pool peer with one another. If you can make this sort of change to ntpd, adding re-resolving should be child's play. I really don't see how this could possibly be more efficient than simply replying directly. To make it work, the times on the receiving and sending machines will have to be in lock step, not just synchronised by NTP, as you will need to time stamp the receipt of the packet on the first machine with a clock that is running identical to the clock that is used to timestamp the packet when it is transmitted back. You will also need to ensure that the IP address from which the response returns is the same as that to which it was sent. This cannot work. Physically different servers will have different clocks and the association must be set up to work with just that one clock or the algorithms in the code will end up rejecting the entire set as the jitter and delays will be way off. Not only are the clocks different, their frequencies will be different, their refid's will be different and the round-trip delays will be different. You cannot do anycasting with NTP. This kind of thing works well with DNS but DNS doesn't care about what the server is doing, or how long it takes. NTP does. The way it is working right now, each client may surely get a different server in the pool but I have no way to ensure that each of potentially millions of clients select the server in a way which will balance the load on my servers. Also note that the server pool (at Pure statistics will get you close. If you want better, you could do tricks like making the DNS hash the source address to chose between the servers. It might be possible to do this in a router as well, as long as the router handles this completely within its routing processor and doesn't require control processor involvement. I did get a request recently which suggested picking servers at random from the list of addresses returned from DNS. This is probably worth doing. It will need code also to disable the behavior. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Configuring FreeBSD 6.2 for use with Garmin GPS 18 LVC
The odd thing is, the GPS 18 LVC ran fine for a few weeks with the receiver inside, when it suddenly stopped getting any signal. After that, I mounted it on a bracket about a foot outside the window, where it ran fine for about three months. Now the signal is intermittent, although most of the time it is not synced. If I power-cycle the unit, it syncs for about 5 - 10 minutes, then loses signal. Sometimes it will sync again, sometimes it won't. But it's always intermittent. So it's apparent that it does get signal but it's weak. Dennis Hilberg, Jr. timekeeper(at)dennishilberg(dot)com NTP Server Information: http://saturn.dennishilberg.com/ntp.php Dennis, Have you considered that the unit itself may be defective, Granted it used to work, but that doesn't mean it will last forever. It is a massed produced and rather inexpensive unit, I would think ordering a new unit would be cheaper than the time and labor of stringing wire all over the place. Just a thought, Phil ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Is there a windows clock program that updates it's display with sub second accuracy?
On Dec 23, 10:09 am, David J Taylor [EMAIL PROTECTED] this-bit.nor-this-bit.co.uk wrote: Ryan, My Tiny Ben (as opposed to Big Ben) program should be within about 100msec or so. http://www.david-taylor.myby.co.uk/software/disk.html#TinyBen Cheers, David Worked perfectly. Thanks! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Is there a windows clock program that updates it's display with sub second accuracy?
Ryan * wrote: On Dec 23, 10:09 am, David J Taylor [EMAIL PROTECTED] this-bit.nor-this-bit.co.uk wrote: [] http://www.david-taylor.myby.co.uk/software/disk.html#TinyBen [] Worked perfectly. Thanks! Thanks, Ryan. It came as a result of also having a speaking-clock program, and having that running on three PCs simultaneously. Having the three PCs all speak at /just/ the same time is a nice way to check that NTP is working. When they speak slightly differently, I can check (but usually NTP is still fine). The speaking clock also works in Swedish and German Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
