[Planetlab-users] probing for bandwidth measurements

[Constantine Dovrolis]

Neil,

there are several things here:

>
> I'm looking forward to Manish's report -- I'd like to know what train
> he can get on plain linux but not on planetlab.  It's tough to send
> packets uniformly at 5ms spacing with any other process running even on
> a plain linux machine.
>

Manish can elaborate on how we do this at pathload. Long interarrivals
are controlled with timers while short interarrivals are controlled
with busy waiting. This has not be a problem in the experiments that
we did (using linux, freebsd, and solaris boxes) in our testbed, or
in machines that are not as heavily loaded as planetlab. Pathload
uses techniques to detect whether the send or receive hosts experienced
significant context switching while the streams were sent/received.
In that case, the tool typically aborts the measurements or
raises warnings.

> To be clear, my position, without much evidence, is that PlanetLab is
> at least as good as a shared linux machine, (ignoring the rate-limits)
> and that defensive programming is required everywhere to ensure that
> what you think you send is really what you sent.  I believe that
> Pathrate is the hardest possible tool to get right on Planetlab because
> of its need for precise timing over relatively long durations (unlike,
> say, packet chirps which need less time).

I disagree with this in two ways:

1. Planetlab is a much harder environment for available bandwidth
measurements (not to be confused with capacity or bottleneck bandwidth
measurements), because the latter require  precise rate probing and
sensitive timing measurements, and both of these requirements are harder
to achieve as the load of the sending or receiving host increases.
The presence of rate limiters at Planetlab makes things even harder
because most available bandwidth tools need to be able to control
the rate of the outgoing streams.

2. Pathrate does capacity measurements. Pathload does available
bandwidth measurements. It is the latter type of measurements
that are the most problematic in Planetlab, as the following talk
also showed.

> Would someone who attended last week's meeting summarize:
>
> http://www.planet-lab.org/Talks/2005-05-01/planetLab_meeting_050105.ppt
>
> It seems some folks have very recent experience with pathrate on
> planetlab.


I was not at that Planetlab meeting but this presentation was also
given at PAM 2005, which I attended. That work focused on capacity
measurements, not available bandwidth. The authors decided
to use Pathrate because that was the most accurate and stable tool
for that type of measurements. The authors, as far as I know,
wanted to also do available bandwidth measurements but they faced
problems with all the existing tools. As I explained earlier that
should not be a surprise; Planetlab nodes are too heavily loaded
for available bandwidth measurements. Whenever we want to do
such measurements, we prefer to use RON hosts or other machines
around the world where we have an account. For more controllable
experiments, we prefer to use our lab testbed, using trace-driven
cross traffic generation.



Constantine