perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Michael Tiernan writes:

I know there's a CPU muscle issue for doing all the heavy lifting PS would impose on a system so I wonder if anyone's thought of creating a simplified target that can respond to tests from a more powerful host?

These days, you don’t even need something simplified.  Ed Colone at UMich has RPi 4s running the testpoint bundle that will do 900 Mb/s across an Ethernet cable without breaking a sweat.  That’s a real milestone, because as recently as two years ago we recommended against using them for throughput.

Implementation example might be to facilitate "Work from home" operations where the "Company" could test links out to employee's endpoints for reliability and a modest standard of speed test. (As well as availability.)  …  Plant a simple SBC unit at the target's home and let it respond to test requests from a primary server.

I work at home and regularly do testing from there while developing and can offer a couple of pointers that might help get you there:

Make this as plug-and-play as you can for the employees.  Plugging an Ethernet cable into their router and getting a DHCP address is easy; getting WiFi to work is harder because the SSID and authentication info have to be put on the SBC beforehand.

Most of these will end up behind NAT, which pretty much precludes asynchronously requesting measurements from the outside.  Asking for holes to be opened in firewalls for it to work would be a logistical nightmare, so I’d avoid that.

pSConfig is a big help here.  Give each of your SBCs a standard name (e.g., mit-at-home-1234), point them at a template downloaded from MIT with the tests you want to run and they’ll do the right thing.  Archive the results to a system on campus and you can relate the SBC names to employees on your end or embed that in reference information in the template(s) for the tasks you run.  Obviously, you won’t be able to do inbound UDP throughput testing, but you can measure TCP in both directions by testing SBC-to-MIT and reversing the direction.  I’d imagine that a lot of the other things you might want to be looking at (latency, DNS, HTTP and network reachability) are easily done outward from behind the NAT.

Luke Whitworth’s suggestions about how not to abuse the flash are good, especially in an application like this one where the machines don’t really need to retain state.

(Yes, I know that this goes against the primary design goal of PS of "De-centralized" operations but it seems like a reasonable offshoot.)

There’s nothing wrong with that at all.  Every perfSONAR node is independent, but there’s a large contingent of them that do nothing but take marching orders from a central source.

HTH.

--Mark