[Planetlab-users] probing for bandwidth measurements
gaurav at cse.iitd.ernet.in
Fri May 6 11:36:13 EDT 2005
Constantine, I will have to agree with you abt testing on simulators and
emulators, but the point i was making was that in case of networks with
bandwidth < 100Mbps using raw sockets shud work fine on a linux
machine with average usage, we need not worry much abt the context
switching, coz perturbations caused are quite less,
One thing that i would like to ask is as someone suggested not to use
gettimeofday() and instead use libcap, how much difference does it make to
use lipcap instead of gettimeofday(), how can scriptroute help ?
On Fri, 6
May 2005, Constantine Dovrolis wrote:
> some quick comments and a couple of pointers:
>> But if we are measuring gigabit networks then the order of error will
>> be almost similar to our sending rate which is a big problem, which i
>> guess can be handled by using some filter mechanism or some averaging
>> So, according to me bandwidth estimation techniques should work fine
>> for measurement in upto 100Mbps networks..
> Bandwidth measurements in networks where the bottleneck is faster
> than 100Mbps are definitely harder, but still doable. First, we
> need to worry about interrupt coalescence, detect it automatically,
> and find a way to filter the measurements so that we stil get the
> right result. This is what we did with both Pathrate and Pathload at:
> Second, you need to consider that "dispersion" errors due to queueing
> are not of a fixed magnitude, but they depend on the capacity of the
> bottleneck. Suppose that a cross traffic 1500byte packet interferes
> between your packet pair causing a dispersion error. The magnitude
> of the error is 1.2ms at a 10Mbps link, 120usec at a FE link, and 12usec
> at a GigE link.
> People have done bandwidth measurements in Gigabit paths. I suggest
> you look at the following paper:
> It is based on measurements from both a gigabit testbed and from some
> Internet2 paths.
> An important point that this paper showed is that there can be major
> differences between tools that all appear as "similar", from the outside.
> This is why I think we should be careful with general statements about
> what works and what doesn't.
>> test beds and simulators always give you the desired results because
>> they are 100 % deterministic, but for quantities such as network
>> parameters which are dependent on complex queuing and hell lot of
>> different factors a solution which works well for a test bed might not
>> work in a real scenario.
> This is not true. Testbeds (or emulated networks such as EmuLab) use
> real hosts and routers, and so they would involve all the queueing
> or end-host effects you would have in the real world. The
> traffic generation process can be realistic if it is trace-driven (even
> though "realistic" is not synonymous with "real" here).
> Simulations, on the other hand, are absolutely necessary as well
> in my opinion. The reason is that they can be used to do repeatable
> and controllable experiments, helping the designer to examine the effect
> of different factors and load conditions. Simulations cannot replace
> the value of real-world measurements, but the latter cannot replace
> the former either..
>> On Thu, 5 May 2005, Constantine Dovrolis wrote:
>>> 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:
>>>> It seems some folks have very recent experience with pathrate on
>>> 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.
>>> Users mailing list: Users at lists.planet-lab.org
More information about the Users