Re: [ntp:questions] time delta between clients
David J Taylor [EMAIL PROTECTED] wrote: The GPS18 is not a very sensitive receiver - nothing like as good as the more recent SiRFstarIII receivers (e.g. Garmin GPSmap 60CSx). It does need an outdoor location, or one with little RF attenuation. Hmm, I wonder if they will ever merge the two :) rick jones -- portable adj, code that compiles under more than one compiler 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 [EMAIL PROTECTED] wrote: I suppose I could also try to see if I can get the powers that be to spring for a GPS18 and see if I can indeed get signal in the machine room(s) of interest. Before I did that I borrowed a hand-held GPS receiver (Magellan Crossover IIRC) from someone. Admittedly it will not be a match for the GPS18, and may have a weaker receiver. But given that _all_ signal went poof when I entered the building, I suspect the GPS18, unless it is much more sensitive, would have lost all signal too :( 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] time delta between clients
On 2008-02-19, Rick Jones [EMAIL PROTECTED] wrote: Before I did that I borrowed a hand-held GPS receiver (Magellan Crossover IIRC) from someone. Admittedly it will not be a match for the GPS18, and may have a weaker receiver. But given that _all_ signal went poof when I entered the building, I suspect the GPS18, unless it is much more sensitive, would have lost all signal too :( My GPS18LVC works through a standard US residential roof. But you probably have lots of metal in the way. So ... YMWV You can extend the serial cable between the GPS and the host system so that you can place the receiver where it has a sky view. It may also help to place the host system in a location close to the roof. If you use a small system which can run off of POE that will simplify the cabling a bit. -- 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] time delta between clients
Steve Kostecke [EMAIL PROTECTED] writes: On 2008-02-19, Rick Jones [EMAIL PROTECTED] wrote: Before I did that I borrowed a hand-held GPS receiver (Magellan Crossover IIRC) from someone. Admittedly it will not be a match for the GPS18, and may have a weaker receiver. But given that _all_ signal went poof when I entered the building, I suspect the GPS18, unless it is much more sensitive, would have lost all signal too :( My GPS18LVC works through a standard US residential roof. But you probably have lots of metal in the way. So ... YMWV You can extend the serial cable between the GPS and the host system so that you can place the receiver where it has a sky view. It may also help to place the host system in a location close to the roof. If you use a small system which can run off of POE that will simplify the cabling a bit. I run a GPS 18 LVC along 10m of cat5 cable in addition to the 5m cable it comes with. Not ideal, but it works. While reflections might be a problem, 15m is 50ns and the pps is only good to 1usec anyway, and the time reading is only good for about 3usec as well. So the broadening of the pulse by a few 10s of nsec is completely lost in the noise. (Ie, I use the usb as a power supply for the receiver-- the red and black wires go to the red and two black wires on the GPS, the pink goes to the Ack on the parallel port with also a ground connection, and the green and yellow go to the transmit/receive on the serial port. ) -- 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] time delta between clients
Steve Kostecke [EMAIL PROTECTED] wrote: My GPS18LVC works through a standard US residential roof. But you probably have lots of metal in the way. So ... YMWV Yep - basic concrete, steel and glass US office building - in this case a standard HP BigFoot building. rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates 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 [EMAIL PROTECTED] writes: Steve Kostecke [EMAIL PROTECTED] wrote: My GPS18LVC works through a standard US residential roof. But you probably have lots of metal in the way. So ... YMWV Yep - basic concrete, steel and glass US office building - in this case a standard HP BigFoot building. No idea what a bigfoot building is. But if you have window access that should be fine. Your receiver will see half the sky. rick jones -- oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates 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: I suppose I could also try to see if I can get the powers that be to spring for a GPS18 and see if I can indeed get signal in the machine room(s) of interest. Before I did that I borrowed a hand-held GPS receiver (Magellan Crossover IIRC) from someone. Admittedly it will not be a match for the GPS18, and may have a weaker receiver. But given that _all_ signal went poof when I entered the building, I suspect the GPS18, unless it is much more sensitive, would have lost all signal too :( rick jones Rick, The GPS18 is not a very sensitive receiver - nothing like as good as the more recent SiRFstarIII receivers (e.g. Garmin GPSmap 60CSx). It does need an outdoor location, or one with little RF attenuation. Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
[EMAIL PROTECTED] (Kevin Oberman) writes: [...] Netperf is not really the best way to go. The appropriate tool for one-way latency is OWAMP. http://e2epi.internet2.edu/owamp/ I think you missed the point: AFAIK, Rick is the author of netperf ;-) [...] Ulrich ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Ulrich Windl [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Kevin Oberman) writes: [...] Netperf is not really the best way to go. The appropriate tool for one-way latency is OWAMP. http://e2epi.internet2.edu/owamp/ I think you missed the point: AFAIK, Rick is the author of netperf ;-) S! It's a secret!-) rick jones about to hit-up management for aproval to buy a GPS-18 for some experiments, unless someone knows of a better device... -- The glass is neither half-empty nor half-full. The glass has a leak. The real question is Can it be patched? 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, Apparently, OWAMP uses NTP timestamps, but the article assumes there is a difference between NTP time and system time. Statistically, NTP time is an unbiased estimator of UTC and system time is a lowpass version of it. The offsets you might consider NTP time represent statistical uncertanty of that estimate and should not be used as system time. Now for one-way delay calculations, which I can't find in the article. In cases of severe one-way congestion, which might be the objective, see the NTP huff-n'-puff filter, which is designed to prize this out. As for swish and sway due to congestion, Chapter 6 of das Buch has a really interesting example of a path from here to East Asia with awesome one-way congestion. Huff-n'-puff sliced through it like butter. It could be that the statistical methods used by huff-n'-puff be useful if exported to other applications. Theoretically, you can't measure one-way propagation times unless you have some other measure such as bit rate. The first experiments to measure this was done 30 years ago using the ARPAnet and had some success. The code measures the data rate by launching packets of varying size and measuring the differential delays. I recently tried the same thing in my earlier experiments using the NTP daemon ntpd, but wasn't thrilled with the results. For the experiment to work right the network should satisfy what is called the Kleinrock Assumption, and my dinkly ISDN line to campus fails that assumption. Nevertheless, the code is in the ntp-dev version, but currently disabled. Dave Rick Jones wrote: Ulrich Windl [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Kevin Oberman) writes: [...] Netperf is not really the best way to go. The appropriate tool for one-way latency is OWAMP. http://e2epi.internet2.edu/owamp/ I think you missed the point: AFAIK, Rick is the author of netperf ;-) S! It's a secret!-) rick jones about to hit-up management for aproval to buy a GPS-18 for some experiments, unless someone knows of a better device... ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Danny Mayer [EMAIL PROTECTED] wrote: Don't do that. You need at *least* 4 servers listed here. Two is very bad since you have very few ways of telling which clock is better. peer is useful for comparing how other systems are doing but it will sometimes discipline your system clock if nothing better is available. You should use iburst on all lines to speed up initial convergence to a stable state. OK, I will see about doing that on the 2nd. If this is one of your neverending testing workbenches consider getting one of HP's clocks (or is it owned by Agilent now?). Even better, a cesium clock! The clocks went to Agilent, whom I believe sold that part of the business to another entity. rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Jobert 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
Tom Smith [EMAIL PROTECTED] wrote: Well, first I missed it if Rick said he was exclusively concerned about UNIX hosts. I don't think I said one way or the other. While netperf means never turning-ones-nose-up at any OS, I think it would be safe to say that various flavors of *nix would be the 99% solutuion here. rick jones -- Process shall set you free from the need for rational thought. 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
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
Re: [ntp:questions] time delta between clients
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? --Per Hedeland [EMAIL PROTECTED] 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. -Tom ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
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? --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: 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. Danny ___ 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 Don't do that. You need at *least* 4 servers listed here. Two is very bad since you have very few ways of telling which clock is better. peer is useful for comparing how other systems are doing but it will sometimes discipline your system clock if nothing better is available. You should use iburst on all lines to speed up initial convergence to a stable state. If this is one of your neverending testing workbenches consider getting one of HP's clocks (or is it owned by Agilent now?). Even better, a cesium clock! Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
Kevin Oberman wrote: Netperf is not really the best way to go. The appropriate tool for one-way latency is OWAMP. http://e2epi.internet2.edu/owamp/ It requires well synchronized time which is where I became seriously involved in this area. We try to keep our OWAMP server clocks in sync to 5 microseconds. (And we almost always do.) They are scattered all over out backbone from coast to coast. This one is really interesting. We should add this reference into our support web. I haven't looked at the design of this but there may be a case to include it into NTP. Danny ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
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. 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. Again I think I must be misunderstanding you, since virtually all Unix systems have had microsecond clock *resolution* for many years. --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
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] time delta between clients
In article [EMAIL PROTECTED], Rick Jones [EMAIL PROTECTED] wrote: taps with clue bats, is if I can take the difference in offset between each client and the time server and ass-u-me that is the difference in time between the two clients. Or do I have to do something ntp-like No. If NTP is working properly, it is actually an indication of the order of magnitude of the error you can expect in measuring the combination of network and system timing. The actual system timing variation should be considerably less than this, but there may be a systematic bias, even if offset is consistently almost zero. 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! To the extent that the above is not true, either you are making use of information not available to NTP (like recent temperature excursions), or the NTP algorithms need fixing. You need to use local, probably GPS, reference clocks, with pulse per second feeds, to remove network asymmetry. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] time delta between clients
David Woolley [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Rick Jones [EMAIL PROTECTED] wrote: taps with clue bats, is if I can take the difference in offset between each client and the time server and ass-u-me that is the difference in time between the two clients. Or do I have to do something ntp-like No. If NTP is working properly, it is actually an indication of the order of magnitude of the error you can expect in measuring the combination of network and system timing. The actual system timing variation should be considerably less than this, but there may be a systematic bias, even if offset is consistently almost zero. Demonstrate ignoranve mode on Systematic bias? / 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. To the extent that the above is not true, either you are making use of information not available to NTP (like recent temperature excursions), or the NTP algorithms need fixing. You need to use local, probably GPS, reference clocks, with pulse per second feeds, to remove network asymmetry. 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) -- 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
Richard B. Gilbert [EMAIL PROTECTED] wrote: Rick Jones wrote: David Woolley [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Rick Jones [EMAIL PROTECTED] wrote: taps with clue bats, is if I can take the difference in offset between each client and the time server and ass-u-me that is the difference in time between the two clients. Or do I have to do something ntp-like No. If NTP is working properly, it is actually an indication of the order of magnitude of the error you can expect in measuring the combination of network and system timing. The actual system timing variation should be considerably less than this, but there may be a systematic bias, even if offset is consistently almost zero. Demonstrate ignoranve mode on Systematic bias? / 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. To the extent that the above is not true, either you are making use of information not available to NTP (like recent temperature excursions), or the NTP algorithms need fixing. You need to use local, probably GPS, reference clocks, with pulse per second feeds, to remove network asymmetry. 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) Define good enough! How close must synchronization be between machines on your LAN? How accurate must the time be? Well, if the RTT measured by netperf TCP_RR is any indication: [EMAIL PROTECTED] netperf2_trunk]# netperf -t TCP_RR -v2 -H bl480c2 -c -C TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to bl480c2.raj (10.208.0.27) port 0 AF_INET : first burst 0 Local /Remote Socket Size Request Resp. Elapsed Trans. CPUCPUS.dem S.dem Send Recv SizeSize TimeRate local remote local remote bytes bytes bytes bytes secs. per sec % S% Sus/Tr us/Tr 87380 87380 1 1 10.00 19834.15 2.20 2.29 8.888 9.222 87380 87380 Alignment Offset RoundTrip TransThroughput Local Remote Local Remote LatencyRate 10^6bits/s Send RecvSend Recvusec/Tran per sec Outbound Inbound 8 0 0 0 50.418 19834.148 0.159 0.159 I'm presently seeing round-trip times user space to user space, and with interrupt coalescing disabled (not the default) of 50 microseconds. Some folks have reported better TCP_RR perf with other interconnects (the above was simply Gigabit Ethernet). So, we are talking small numbers of microseconds. Note that having a stable source of time, such as a GPS receiver, can strongly affect the tightness of synchronization. It's analogous to the difference in difficulty of hitting a stationary target versus a moving target. I've done it with and without GPS. GPS is better as long as you can site an antenna with a good view of the sky. With GPS I can keep the herd within one millisecond. Most of what I do is down in the bowels of corporate machine rooms, far from windows, which doesn't fill me with confidence about getting a good view of the sky :( rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Jobert 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
Richard B. Gilbert [EMAIL PROTECTED] wrote: Can you put a small PC with a GPS receiver on the top floor as a dedicated NTP server? Perhaps, but I doubt I could get a direct line on the network from the systems to it. There are devices (expensive) that will read the time from the reference signal of a CDMA cell phone base station and serve time via NTP. I might be able to convince TPTB to fund a GPS18 or GPS185Hz experiment. In this _specific_ instance the building is two stories plus a mezzanine. Perhaps I could get lucky. rick jones -- No need to believe in either side, or any side. There is no cause. There's only yourself. The belief is in your own precision. - Jobert 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: Richard B. Gilbert [EMAIL PROTECTED] wrote: Can you put a small PC with a GPS receiver on the top floor as a dedicated NTP server? Perhaps, but I doubt I could get a direct line on the network from the systems to it. There are devices (expensive) that will read the time from the reference signal of a CDMA cell phone base station and serve time via NTP. I might be able to convince TPTB to fund a GPS18 or GPS185Hz experiment. In this _specific_ instance the building is two stories plus a mezzanine. Perhaps I could get lucky. You might get something to work without an outside antenna. A great deal would depend on just how the building was constructed. Some buildings would work as a pretty good Faraday shield. I can receive GPS signals inside my house because it's mostly wood and more or less transparent to the frequencies involved. YMMV! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] time delta between clients
Some folks have been asking me if it is possible to use netperf to get the one-way latency between two systems, while sending a unidirectional stream of data from one to the other. Netperf already has a TCP_RR test (ping-pong) that will report the average round-trip latency (and optionally a histogram of the individual RTTs). That though is not a unidirectional test. So, I am assuming I need synchronized clocks. Running ntp on each of the two systems on which I would run netperf is not a problem. What I'm curious about, and a topic where I would welcome some gentle taps with clue bats, is if I can take the difference in offset between each client and the time server and ass-u-me that is the difference in time between the two clients. Or do I have to do something ntp-like in netperf itself between the two systems? My tests will typically only run for oh, O(60) seconds at a time, so I'm ass-u-me-ing I can ignore issues of the two client clocks rates changing much. For example, here is ntpq peers output from a pair of machines where I might want to do this: Client 1: ntpq peers remote refid st t when poll reach delay offset jitter == +oslowest.raj15.4.81.61 2 u 118 128 3770.123 -1.602 2.723 +lart.lart 15.235.160.305 u4 128 377 35.6394.115 1.508 *shovlhead.nashu .TRUE. 1 u 54 128 377 101.115 -5.273 8.190 Client 2: ntpq peers remote refid st t when poll reach delay offset jitter == +linger.raj 15.4.81.61 2 u 104 128 3770.1510.002 0.976 +lart.lart 15.235.160.305 u 97 128 377 35.6823.556 1.003 *shovlhead.nashu .TRUE. 1 u 33 128 377 105.602 -0.839 3.267 I would take the difference in offset - -5.273 - -0.839 - and take that to be the difference in time between Client 1 and 2. Thoughts, suggestions, pointers etc most welcome, rick jones BTW, in this case, I disabled the interrupt coalescing on Client 1's NIC, which I believe is the reason for the difference in delay between Client 1 and 2 and linger.raj - all three are on the same LAN. It gets lost in the noise talking to the other two time sources. -- 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
