A perfSONAR User's Group

Beaglebone Black node logistics Q&A from Lonnie @ LONI

I got a set of good questions from Lonnie Leger, and as I was answering, I thought, this might read well as a post… With his permission, I paste (one or two after-thoughts in parentheses ).


Probably useful to note that LSU has some Beaglebone Blacks doing things
on their network, perhaps for the sake of face-to-face inquiry.

On 5/1/2014 7:47 AM, Lonnie Leger wrote:
> 1. Why are you choosing this platform versus other mini’s?

Acceptable functionality and low price.

I like the internal flash better than Raspberry Pi’s SD card which
sticks out and invites mechanical strain. I like the regular “barrel”
power connector over RPi’s micro USB for power. Internally, the RPi
connects Ethernet via USB, whereas BeagleBone (all models) has a
non-packet-bus interface to its Ethernet. I am attempting to test
exactly how influential this is for things like latency tests.

All that said, I may have to resort to using more RPis as the BeagleBone
Black supply is very tight, and it may not get better since there is a
new BeagleBone model coming out. CAIDA is using RPi for ARK nodes, and
is apparently non-repentant.

The CuBox low-end model is price competitive, but set back by $10 per
unit shipping from Israel, but I have to make a spreadsheet to see
exactly how damaging this is.

(We have ordered 4 ea.¬†CuBox-i4-Pros, which are supposed to ship May 15th. This is the one with the GigE that is bus-limited to ~430 Mbps. Also, having mentioned the $10 shipping, it’s worthwhile to point out that the CuBox all come in a purpose-built case, something which others leave as an extra. CuBox I-1 can be had for $62.99 + cost for SD card (8 GB $4.95 Amazon) + shipping, which is certainly competitive.

> 2. Have you found an assembly kit provider or you doing the assembly yourself?

Assembly is a major concern of mine. I have several Raspberry Pi’s with
cases that screw together with 4 screws each. Not troubling for a few,
but not something I want to do 100 times.

For both Beaglebone Black and Raspberry Pi, there are snap-together
cases, which makes the assembly much less troublesome. I just order
case/board/power/(SD) and put it together in about 10 seconds. For
BeagleBone, I have an SD which boots, installs OS on interior flash, and
then blinks the board’s LEDs when it’s ready. For RPi, one can just
image cards one after the other on a Linux box. The OS install takes
about 5 minutes per unit, but if you eliminate as much operator
intervention as possible, it’s just time, not trouble.

> 3. Where will you be deploying these device?

I have a few non-CCNIE funded devices that I am using as such things as
a owamp server for perfSONAR to test against, at remote campuses.

For the CCNIE devices, they are intended to be deployed (currently 9
are), on nets that represent “user perspective” on our flagship campus.
The idea being to see what an end-user sees. In practice, many are
getting placed immediately outside the department’s firewall. An obvious
addition to the plan is to put another one inside the firewall, and that
will take coordination.

> 4. How do intend to power the device?

The deployment sites support just plugging a wall-wart into a power
strip and powering the device with it. I have looked into PoE, but
standards-based PoE is expensive, there aren’t any cheap regulators that
step 48v down to 5v, and etc. Still, if you want a PoE-like solution,
this device may do:

Passive Injector/Splitter (Amazon.com)

(Also: bare-wire to power barrel )

I have not looked into powering them from a 24v or 48v DC bus. 24 is
probably easy.

> 5. What test(s) are envisioned by the device?

Mostly latency and loss, and then some DNS resolution tests including
IPv6 resolution/preference. I also intend to do periodic iperf tests.
Throughput tests on the devices mentioned have the capability to fill a
100 Mb Ethernet, which can be informative, but not test high-end path

The perfSONAR parts that I use on the devices to begin with are owamp
and bwctl (newest 1.5 bwctl allows scheduling of throughput, ping,
traceroute tests between hosts). I also intend to get the newer Simple
Lookup Service going on them, as well as having them log to a new-style
PS measurement archive. In phase 1, I will use a central perfSONARBuoy
node to run tests against the sensors, but I need to make the pSB do
authentication first. All of the small devices require auth to run
tests, but pSB doesn’t support it yet.

Results will be side-loaded from psB-MA to Cacti on the same host.

Other thoughts are things like attack logging, reporting rogue IPv6 RA
announcements, temp/humidity sensors, etc.

> 6. If with many devices deployed, how do you intend to conduct management and support?

Each node is as close to identical as I can make it. There should be no
per-node configuration. Each node invents a hostname based on its own
MAC address and CPU architecture, and registers with a Puppet
(puppetlabs.com) Master, which can manage package installation, file
contents, other system config on the “swarm” nodes as a group. Puppet
also receives reports from each device, and status/inventory is brought
together in a web interface. For the web-int I use the Foreman
www.theforeman.org, which installs itself and Puppet on a Linux
management host, for which I am currently using a VM.

> 7. Are you planning to launch a public content about your project?

Yes, I may just make it a feature on perfclub.org, but I imagine UH will
want it somewhere that ends in hawaii.edu.


Comments are currently closed.