Skip to Content.
Sympa Menu

perfsonar-dev - Re: [pS-dev] RE: Question about interpreting One Way Delay data.

Subject: perfsonar development work

List archive

Re: [pS-dev] RE: Question about interpreting One Way Delay data.


Chronological Thread 
  • From: Roland Karch <>
  • To:
  • Subject: Re: [pS-dev] RE: Question about interpreting One Way Delay data.
  • Date: Mon, 23 Jul 2007 10:55:36 +0200
  • Organization: DFN-Labor, Regionales RechenZentrum Erlangen (RRZE)

On Sun, Jul 22, 2007 at 11:20:46AM -0600, Jeff W. Boote wrote:
> A lot also depends on the load-balancing hardware. Some hardware is smart
> enough to keep address tuples (src,dest,port) going the same route. In this
> case, owamp for example would only ever see one route from the
> load-balancer. (For the same test session since each session happens on a
> unique port.)

This is indeed what I can confirm from actual experience. In a setup of
"leaf" type PoPs connected via two independent SDH links from the same
"core network" PoP, we saw exactly this smart hardware effect. Normally,
changes in OWD were only noticeable during outages/maintenances on one
of the redundant paths. I would even assume that most hardware is at
least this smart, since sending "one packet left, one right, ..." will
introduce heavy jitter and reordering. OWDV and reordering are indeed
the main metrics I'd look for to find out about "load balancing gone
wrong" compared to route flapping.

Apart from that, I can only agree with Wenji's suggestion to correlate
data with traceroute. The added benefit of having traceroute data is
indeed the main reason why we do schedule regular route measurements
within the GEANT network's measurement points.

Greetings,
Roland
--
Roland Karch, DFN-Labor
Friedrich-Alexander-Universit�t Erlangen-N�rnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstra�e 1, 91058 Erlangen, Germany
Tel. +49 9131 85-27806, -28800, Fax: +49 9131 302941
mailto:
http://www-win.rrze.uni-erlangen.de/

Attachment: signature.asc
Description: Digital signature




Archive powered by MHonArc 2.6.16.

Top of Page