perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Dan Pritts writes:

 

pscheduler result returns:

…
Error from localhost:
  iperf3 returned an error: error - unable to connect to server: Connection refused
…
Error from perf0.us-east-1.icpsr.umich.edu:
  iperf3 returned an error: exiting

My eyes skimmed past the "iperf3 returned an error: exiting" it when I looked earlier, it's pretty vague.

 

The iperf3 plugin as it exists in 4.1.6 has some deficiencies in how diagnostics are collected during failures.  This was brought to our attention in February and has improvements in the pipeline for 4.2.  There are several situations where the reporting from iperf3 itself is vague, but this isn’t one of them.

The iperf3 plugin doesn’t do anything special as far as binding to a particular address by default, so NAT (real 1:1 NAT, not cable modem-style PAT) shouldn’t have any effect on the server side.

ps told me that the iperf3 command that runs (successfully) for an ipv6 test was

/usr/bin/iperf3 -s -1 --json -p 5201 -B perf0.us-east-1.icpsr.umich.edu -6

Running the same command with a -4 suggests that it actually is attempting to bind to a particular address.  And it sends multiple "error"s in the json, and I bet pscheduler was only grabbing the last one.  If I'd seen "cannot assign requested address", well, I'd have KNOWN that it was a NAT problem. :)

Let me start with a disclaimer/excuse/deflection/whatever:  despite being associated with all things pScheduler, I was not the developer of the throughput test and iperf2/iperf3/nuttcp tool plugins.  I can cover the 90% behavior cases off the top of my head but have to dig through the code to understand the other 10%, which is clearly where this lives.

 

There is a complex decision tree in the iperf3 plugin that determines whether or not to bind, and it looks to have been built without NAT in mind.  There may be room to make it less aggressive, but I need to check with the original author to make sure it won’t break any of the other intended use cases.  If we can’t, it would be possible to add test parameters to a future release that bypass the entire process and say, “don’t argue, just bind here or don’t bind at all.”  The down side is that it could create complications for pSConfig, but what fun is life without complications?

This all points to a tool-by-tool analysis, like you say.  NBD, just a week or two project for an experienced engineer who's already got a million things on their plate.

 

I’ve skipped the plate and pulled a chair directly up to the buffet.  :-)  We’ll get this looked at and see what can be done to improve it.

 

--Mark