[Planetlab-users] probing for bandwidth measurements

[Larry Peterson]

Neil may be hesitant to promote ScriptRoute, but I'm not so
constrained...

Taking accurate measurements on PlanetLab involves a non-trivial
learning curve, which ScriptRoute has already climbed. It makes
a lot of sense that the community of users that want to use
PlanetLab to measure the Internet rally around a common
measurement platform, such as ScriptRoute. This would help
avoid the naive mistakes that cause remote sites to complain
about excessive probes, and we could ensure that the measurement
slice has the right scheduling parameters (both a sufficient
share and low latency). This would likely also cause users
to queue for access to the measurement slice, which would take
load of the system for everyone else. A final advantage is that
we'd have a concentrated effort that could provide feedback on
what the core needs to do to better support measurements. As
it is, there seem to be a lot of "silent failures" that are
never translated into actionable feedback.

We'd have to figure out how to promote the development of new
measurement techniques, but surely this could be supported using
a scripting-based platform.

Larry

On May 4, 2005, at 11:13 PM, Neil Spring wrote:

> Manfred,
>
> Frankly, I don't believe what you say is true, but only because I 
> think there are methods that planetlab supports but frequently aren't 
> used.
>
> On May 2, 2005, at 5:26 PM, Manfred Georg wrote:
>> 1) You generally can't send enough data to congest the links, since
>> planetlab nodes are normally rate limited.
>
> This is totally true.  A feature, actually, that Planetlab prevents 
> you from doing harm.
>
>> 2) It's difficult to use a packet pair approach because of lag in the
>> operating system.  Note that planetlab has a layer more of OS type
>> stuff on top of what you usually get.  Depending on what you're doing
>> this can really screw up timings.  Expecially if someone in another
>> slice decides to heavily use the CPU for a bit.
>
> This, I think, is not true.  Sure, there's more stuff on the machine, 
> but sendto(); sendto(); does about the same amount of work in 
> planetlab as off [1].   On recent planetlab, there's real libpcap in 
> there collecting timings of both sent and received packets before they 
> go to the driver and after they come off.   This and the new scheduler 
> go a long way toward making timing-sensitive measurements possible.
>
> This is not to say that PlanetLab is the ideal platform for all 
> network measurement.  There are, of course, "issues" with NTP, clock 
> skew, the suitability of busy waiting, what it means to measure a 
> network when you're rate-limited, how not to trip over IDSs, etc.
>
> For accurate timing, use libpcap (*NEVER* gettimeofday()) to know when 
> packets are sent and received, or, use scriptroute, which used libpcap 
> for this purpose from day one and tries to busy-wait for sending 
> short-interval packet trains.  I try to avoid plugging my own code on 
> this list, but it does deal with these problems and was designed to 
> provide a portability layer for network measurement tools on and off 
> planetlab.
>
> I, and I think PlanetLab staff, would appreciate the bug report that 
> shows some active measurement that works off-planetlab is not possible 
> on-planetlab if properly written to the interfaces at hand.  What I 
> mean to say is, if you find a problem, file a bug.  That way, when 
> they fix stuff (as I believe they largely have), we can avoid 
> criticizing planetlab for the flaws it had in v2.
>
> -neil
> [1] there's that nifty PeriScope paper that tries to solve the problem 
> of actually getting a packet pair on normal linux.
>
> _______________________________________________
> Users mailing list: Users at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/users
>