The machines are not VM. Hmmm, I'm not sure that I believe you guys ;^) I don't think that my application falls into the silly assumption "arrow of time" category. I don't think there is any difference between a negative time step, and a positive one (other than direction). Both are bad, but still not the great big blue boogieman for me. My worst case occurs if the time is different between the computers.
This is a wireless emulator on a wired testbed, and the packets record a start of transmission time on one computer, and then a Start of Reception time (SoR) on another computer. If the clocks have different times then the calculation of noise caused by other packets will get screwed up because the receiving computer will either stay in RxPending too long, or not long enough. I think that the slewing behavior is worse than the ntpdate behavior of suddenly changing the time, because the time will remain wrong for a longer period of time. --- On Fri, 9/17/10, Kevin Oberman <[email protected]> wrote: > From: Kevin Oberman <[email protected]> > Subject: Re: [ntp:questions] Why does ntp keep changing my conf file? > To: [email protected] > Cc: [email protected] > Date: Friday, September 17, 2010, 9:52 AM > > From: Steve Kostecke <[email protected]> > > Date: 17 Sep 2010 12:34:35 GMT > > Sender: [email protected] > > > > On 2010-09-16, Daniel Havey <[email protected]> > wrote: > > > > > I want ntpdate, and don't really care about > ntpd. > > > > Why? ntpd is both an ntp server and an ntp client. > > > > > I need an ntp server running on one node, and the > other nodes connect > > > to the first node with ntpdate ... > > > > ntpd continuously disciplines the system clock > > > > ntpdate can only apply/initiate an adjustment each > time it runs. The > > system clock will drift in the interim. > > Worse yet, ntpdate may cause the time to step backwards > which really > screws up some stuff that makes silly assumptions about the > "arrow of > time". > > Aside from the fact that ntpdate was deprecated a LONG time > ago, it is > really a poor way to try to sync time. ntpd or chrony would > be a much > better choice. Even sntp would work better. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley > Lab) > E-mail: [email protected] > Phone: +1 510 > 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D > EBB3 987B 3751 > _______________________________________________ > questions mailing list > [email protected] > http://lists.ntp.org/listinfo/questions > _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
