Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] GPS

Subject: perfsonar development work

List archive

Re: [pS-dev] GPS


Chronological Thread 
  • From: Jochen Reinwand <>
  • To: "" <>
  • Cc: Nicolas Simar <>
  • Subject: Re: [pS-dev] GPS
  • Date: Wed, 1 Aug 2007 09:03:44 +0200
  • Organization: DFN Verein

Hi Nicolas, all,

What Verena wrote is of course right, but I want to add a few things. Perhaps
this mail thread becomes some sort of a FAQ, that will be included on our web
page. It should be added to our software repository as well...

On Tuesday 31 July 2007 17:44, Verena Venus wrote:
> Am Tuesday 31 July 2007 17:13 schrieb Nicolas Simar:
> > the question that is typically asked is
> > 1) why do we need OWD?
>
> .... instead of ping? The answer to this question would probably be: If you
> have an asymmetric path where one direction is significantly slower (or
> faster ;) ) than the other direction, you cannot see this with ping,
> because ping measures only the round trip time.
> You need to measure both directions seperately to find out such behaviour.

We had this asymmetric path change at least once. See the anomalies document
I
created for the LHC discussion (page 3). It wasn't sent to the list if I
remember it correctly. It can be found here:
http://www.win-labor.dfn.de/ippm/Examples.pdf

But there is another point using ping:
Ping relies on ICMP and ICMP is quite often handled different when passing
through the network. Especially it might be disabled completely or it might
get disabled based on "unlawful" traffic patterns due to security or
performance issues. Looks like this is happening with our box in Gent. We get
lots of errors from Nagios via the ping service, because it has a packet loss
of 100%. Hades measurements from and to the Gent are not loosing any packets.

> > 2) why do we need a 1 ms accuracy?
>
> Some effects on the network are very small but may have a noticable impact
> on an application. If the accuracy of your measurement is not high enough,
> you cannot see the correlation.

For example for an alert system it prevents lots of false alerts, if the
accuracy is much higher than the effects you want to monitor. That even small
changes in OWD might indicate a great problem you can see in our examples
document in "First German Wikipedia DVD" on page 11.

> > 3) why wouldn't NTP be good enough?
>
> This question surely is mistakeable...
> NTP is perfectly fine. It depends on the time _source_ how "good" it is.
> If you are using a GPS clock as time source in your NTP daemon, you
> probably cannot get something better.
> Synchronising your NTP to a far away time source over modem cable and half
> of the internet surely is quite bad.
>
> So probably it's more the question of why not using NTP servers on the net
> rather than using a clock directly. And this depends on the delay between
> your system and the NTP server. Using more than one NTP server also helps
> to make your time "better".

To say it in other words: NTP is _always_ used to get the current time! It
depends on the configuration of the NTP how accurate this time stamp is. A
GPS antenna with limited sight to the sky should most likely be replaced by
an NTP server using a atom time source standing 2 metres away from the
measurement box. If you have such a machine nearby...

regards,
Jochen

--
Jochen Reinwand, DFN-Labor
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-28689, -28800, Fax +49 9131 302941

www.win-labor.dfn.de



Archive powered by MHonArc 2.6.16.

Top of Page