Tiny iperf3 UI 04/26/2022

[aanon4]

(see #337 for the main discussion)

A super lightweight and simple iperf testing page.

Proposing this as an alternative (and probably better) approach to running an iperf3 server by default. In this case the server is launched on demand when the client needs it. This is similar to iperfspeed but without the sophistication; but still makes a useful testing tool without the constant memory footprint.

curl http://<client-node>:8080/cgi-bin/iperf?target=<server-node>

[ab7pa]

This is a super simple, low memory way to make it easier for non-command-line operators to do iperf testing. Very low impact to node resources -- "only buy what you need" approach.

[ab7pa]

Maybe instead of expecting an empty target we might use "localserver" or some other keyword to indicate that iperf3 should be started in server mode on the local node?

Maybe be a little more verbose on lines 44 and 49 to say what just happened?
44: something like "Enter a node URL for the client/sender (iperf?target=client URL) to start the test, or enter iperf?target=localserver to start the iperf3 server on localnode"
49: something like "Started iperf3 server/receiver on this node"

[dman776]

An alternate thought, should this just be in advanced config option to auto start IPerf? Disabled by default

…

Sent from my iPad

On Apr 22, 2022, at 8:16 AM, Steve AB7PA ***@***.***> wrote:  Maybe instead of expecting an empty target we might use "localserver" or some other keyword to indicate that iperf3 should be started in server mode on the local node? Maybe be a little more verbose on lines 44 and 49 to say what just happened? 44: something like "Enter a node URL for the client (target= or enter target=localserver to start iperf3 server on localnode" 49: something like "Started iperf3 server on this node" — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[aanon4]

The problem with “off by default” in advanced config is that it becomes “never on” because no one will ever turn it on, which I think defeats the purpose.

[K6AH]

I agree with Tim on this. Although there may be rationale for an Advanced Config option Enabled by default.

[aanon4]

So - perhaps - this version of the change (auto-running iperf3 when needed) but with an advanced option to disable completely?

[K6AH]

That sounds right.

[dman776]

Agreed Thanks, Darryl

…

On Apr 23, 2022, at 6:12 PM, Andre Hansen ***@***.***> wrote:  That sounds right. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[aanon4]

Tightened the (already) minimal UI code, switch 'target=' to 'server=' (which is a bit more obvious), and added the 'off' switch.

[K6AH]

...and if it wasn't clear from earlier comments, I think this should be an incentive to upgrade to the new UI. So let's leave it out of earlier releases... but of course, it's up for discussion.

[aanon4]

I think that's a shame. Unless I misunderstood @dman776 last week, I don't think the new UI is shipping soon and it really should be enough of an incentive to upgrade in itself.

[K6AH]

Yeah, okay, I guess I don't feel that strongly about it.

[ab7pa]

Just thinking out loud here... What would we think about some different iperf3 command line arguments? Currently the default test is a TCP transfer, but we might avoid all the network handshaking overhead if we ran UDP transfers.

[ae6xe]

comparison of TCP and UDP tests would be ideal, or having both options. Make the iperf3 arguments an advanced setting? If this is the only options we think anyone would be interested in changing, then make the TCP or UDP a checkbox in the UI? (This is a client side only option?)

[aanon4]

Easy to just add it as an extra command line param - protocol=??? - then you have the option

[aanon4]

Did a little testing with UDP, and for whatever reason (and I also tested this between other machines) the UDP test tops out at 1Mb/sec compared to the TCP test which is at least 10x that.

[ae6xe]

Something must be wrong, we'd expect UDP (on a quality link) to have higher numbers, given no handshaking overhead.

[aanon4]

You should try it. This is between two Threadripper machines on a 40Gb/sec network. TCP performance is what you'd expect, UDP is 1Mb/sec. I tried a couple of AREDN nodes (RF link) doing 15Mb/sec TCP .. and 1Mb/sec UDP.

[aanon4]

The only way to increase the measured UDP performance is to run with the -P option to bump the thread count up.

[aanon4]

Ah ha .. there's another option "-b 0" which fixes this.

[aanon4]

Getting this PR into the nightly would really help the link bandwidth tests I hope to run? One less step for testing.

[dman776]

Let's discuss on the call tomorrow. I'm ok with tuis as is.

[ab7pa]

Are we sure we want to give people the option of crippling the included iperf3 feature??? To me, the new advancedconfig section may confuse most folks -- they won't understand that it's intended for disabling iperf3 altogether on their node. Its utility is limited to a small subset of nodes with very constrained memory footprint which you want to be sure that nobody ever uses for an iperf test. I guess we could explain that clearly in the onboard help file and the online documentation (if they will take the time to read it).

On second thought... it really won't hurt anything if they disable iperf3 altogether. If they mistakenly disable iperf3, so what -- they never had that feature before anyway. ¯\(ツ)/¯

[aanon4]

Strictly speaking it only disables the simple UI. They can still log into two nodes and run it manually between them.

[ab7pa]

I'm all for this simple UI. Small, lightweight, clever approach.

[ab7pa]

Strictly speaking it only disables the simple UI. They can still log into two nodes and run it manually between them.

Good point. Maybe phrase it like that in the advancedconfig desc:
desc = "Enable the simple iperf URL feature" or something like that.

[ab7pa]

I just got back home after a trip. In testing the iperf URL feature I notice that if I enter a URL like this iperf?server= then the node does start the iperf3 server in daemon mode, but the browser window never displays the iperf server running (one time) message — seems to be waiting for the os.execute to complete?

Also, if I do not include the local.mesh suffix then the server will refuse the connection.

/cgi-bin/iperf?server=ab7pa-a75
iperf3: error - unable to connect to server: Connection refused

[aanon4]

iperf?server= is not really suppose to be used by hand, you should just let the client do that itself (which it will). Odd that the message is missing though - can you check the page source?

I can add '.local.mesh' automatically if no domain prefix is given explicitly.

[ae6xe]

"The UDP test shows much better throughput over RF on my nodes. Wonder whether we should make UDP the default test instead of TCP?"

Ether protocol works for me, although UDP may result in an elevated perception of performance when the usage is not fully understood -- this is the higher number. However, our goal should be to inform end users. The usage information could elaborate on why UDP will be a higher number than TCP on quality links (because there's no waiting on ack responses, and can flood the sending pipe with UDP). Now if the link is marginal, and this UDP traffic has high loss, it will be a terrible result in performance (and voice is gabbled or not heard at all).

[ab7pa]

I agree that iperf?server= is not supposed to be used directly, but I thought I'd test it anyway because you know someone is going to enter it and wonder what it's doing spinning like that. :) The page keeps trying to load, so page source never becomes available.

[aanon4]

I'm inclined to keep TCP as the default option because it's already the default option for iperf3, and so expected.

[aanon4]

Okay - I think that's fixed the various problem reported

[ab7pa]

Yep. Everything looks good.