Neither XP nor Mac OS X can be relied on to have accurate time sync, although they in theory come with time syncing enabled by default. Unfortunately, you just can't rely on synchronized clocks in all but the most controlled of circumstances (and I think it's almost always a poor idea, even then). Bruce On Thu, Nov 13, 2008 at 1:45 PM, Das, Saumitra <saumitra@xxxxxxxxxxxx> wrote: > Hi Roni, > > > > What I mean is that typical machines on the planetlab testbed (linux > based) show this drift. This may be alleviated with xp boxes since they may > sync silently with time.windows.com when a network connection is up. In > linux, clock drift problems have been known to exist because ntpdate may not > be setup to work often enough. > > > > Thanks > > Saumitra > > > > From: Roni Even [mailto:ron.even.tlv@xxxxxxxxx] > Sent: Thursday, November 13, 2008 6:24 AM > To: Das, Saumitra; p2psip@xxxxxxxx > Cc: ietf@xxxxxxxx > Subject: RE: [P2PSIP] P2PSIP diagnostics: PING discussion > > > > Hi, > > I am not sure what you mean NTP refresh, if the test was using the system > clock than you would expect in XP that it will be updated every tick which > is 10 or 15 msec which can account for the error. NTP is used in RTP (RFC > 3550) for synchronization and the RTP time is using the system clock which > may add skew but it is not because of NTP. > > > > > > Roni Even > > > > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Das, > Saumitra > Sent: Wednesday, November 12, 2008 11:31 AM > To: p2psip@xxxxxxxx > Cc: ietf@xxxxxxxx > Subject: Re: [P2PSIP] P2PSIP diagnostics: PING discussion > > > > Hi Song, > > > > Even in the planetlab testbed, the following paper at PAM 2008 ( > http://pam2008.cs.wpi.edu/slides/pathak.ppt ) shows that more than 40% of > nodes have more than 20ms NTP error. In a general overlay we are likely to > find a larger fraction of nodes with error in their NTP time (since the > planetlab testbed is managed by the people who own the machines while > general overlay nodes are unlikely to be that well maintained). Unless NTP > refresh is made mandatory within a p2psip implementation, relying on ntp > would be unlikely to be helpful to diagnostics > > > > Thanks > > Saumitra > > > > www.saumitra.info > > > > > > =============== > > > > Dear all, > > > > In P2PSIP base protocol, Ping is used to test connectivity along a path. > > However, connectivity quality can not be measured well without some useful > > information, such as the timestamp and HopCounter. In p2psip diagnostics > > draft version 03 http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt > > we extend the Ping message payloads with a few kinds of useful information > > for connectivity quality check purposes. > > > > The initiator node receiving the Ping response should compute the overlay > > hops to the destination peer for the statistics of connectivity quality from > > the perspective of overlay hops. > > > > About the Timestamp, we are not sure if the NTP time is a good candidate for > > it, or we have other ways to describe it, or we don't need the timestamp at > > all. But if NTP time is used in the overlay, then it is a good choice, > > because every peer along the message path will know when the message is > > generated, and it is easy for the peer along the path to calculate the > > message latency. However many overlays may not be synchronized with the NTP > > time. Any comments? > > > > > > > > Best Regards, > > Song Haibin > > Email: melodysong at huawei.com > > Skype: alexsonghw > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@xxxxxxxx > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf