On 8/29/13 6:36 PM, Nalini Elkins wrote:
>
>
> On 8/29/13 5:47 AM, Nalini Elkins wrote:
> > Please take a look at:
> >
> >
> http://www.ripe.net/data-tools/stats/ttm/test-traffic-measurement-service
> >
> >
> > Note that what they provide is:
> >
> > * NTP-server, the test-boxes can act a stratum 1 server for the
> machines on your network, providing time-stamps with an accuracy of 10
> microseconds.
> >With respect to the IETF 87 presentation/discussion I think is is a
> >dicussion of the quality of time and it relationship to the general
> >utility of of pdm optional header, not the availability of specific
> >point solutions.
>
> Let me back up and see if I can restate your basic concern in simple
> words so that I am sure that I understand you.
>
> I believe that you are concerned that the timestamps provided by NTP
> will not be accurate enough if the timestamps are taken from more than
> one administrative domain.
The clock in the computer is providing the timestamp, ntp is
syncronizing the clock in the computer to another clock.
> Our PDM proposal depends on fairly reliable timestamps.
It depends on the accuracy of clocks generating the timestamps with
respect to each other.
> So, if the timestamps are not reliable, then the PDM is not very useful.
If a diagnostic result is dependant on low number of ms or usec level
timestamp level accuracy and you don't have that, then yes. A related
question is how do you know when you do or don't? if you have long
timeseries data for two devices you may have evidence of the magnitude
of the eror. If packets arrive from the future with respect to your
clock that's a nice and gross indicator. Looking at a packet trace in
the past, the information availble to reconstruct the state of the
clocks is only the timestamps, baring external sources of that information.
>
> Please let me know if I have understood you.
>
> Thanks,
> Nalini
>
>
>
