| Hi, the problem of error messages interlaced with standard output (stdin for the hook) is not happening only with JSON out put, also with the default one.
This is what I get from another run
<RECV_OUTPUT> iperf3: interrupt - the server has terminated ----------------------------------------------------------- Server listening on 5340 —————————————————————
Have a nice day Gaetano
On 19 Dec 2014, at 23:13, Gaetano Vocca <> wrote:
Sure Aaron, No problem for me to apply patches, I am still in a very early phase of my work with bwctl so I have much room for intervention.
Thank you very much for your investigation
Cheers Gaetano
Il giorno 19/dic/2014, alle ore 21:43, Aaron Brown <> ha scritto:
Hey Gaetano,
Ah, I see what’s happening. Since iperf3 is running the server code in a loop, it’s spitting out the error message when we kill the server. Unfortunately, I don’t have a good solution to that just yet. I submitted a patch to the iperf3 developer
implementing a “one-off mode” to avoid these errors, but you’d need to apply a patch to both iperf3 and bwctl. Would that work for you?
Cheers,
Aaron
On Dec 19, 2014, at 3:20 PM, Gaetano Vocca <> wrote:
Hi Aaron,
please find attached the file containing the text which is passed by stdin to a Perl script I use as post hook.
I detect a problem in the RECV_OUTPUT section, line 169.
You will also notice that there is an error at line 178 which doesn’t seem to affect the test result. I understand that the hooks are fed by the stdin, would it be possible to send these error notifications to stderr?
Thanks again
Gaetano
On 19 Dec 2014, at 19:06, Aaron Brown <> wrote:
Hey Gaetano,
Could you send the full output you’re seeing?
Cheers,
Aaron
On Dec 19, 2014, at 12:01 PM, Gaetano Vocca <> wrote:
Hi Aaron,
thank you for the patch, I applied it on iperf3.c in the folder bwlib.
Now it works well, I am able to get the test done in both cases (sender and receiver)!
Unfortunately one more problem pops up in the JSON output which is the one I am using for parsing. The structure is not correct due to one exceeding
closing curly brace. I don’t know if this is the right mailing list to highlight this issue, thank you for any suggestion you may have.
Thanks again
Gaetano
Da: Aaron Brown [mailto:]
Inviato: venerdì 19 dicembre 2014 16:06
A: Gaetano Vocca
Cc: Alan Whinery;
Oggetto: Re: [perfsonar-user] BWCTLD segmantation fault on Raspberry Pi
Hey Gaetano,
Could you try applying this patch to bwctl and running it? It uses the iperf3 binary instead of the library:
You should be able to apply it by doing “patch -i /path/to/bwctl_change_iperf3_exec.patch -p1” while in the bwctl directory.
On Dec 19, 2014, at 9:53 AM, Gaetano Vocca <> wrote:
You are right, bwctld needed a restart.
bwctl -T iperf -u -c <receiver ip>
I get the expected results.
To recap, on my Raspberry Pi running latest Raspbian:
1) bwctl
–T iperf3 -u –c <ip> leads to a segmentation fault
2) bwctl
–T iperf –u -c <ip> works fine
3) bwctl
–T iperf3 –c <ip> works fine
Da: Aaron
Brown [mailto:]
Inviato: venerdì 19 dicembre 2014 15:10
A: Gaetano Vocca
Cc: Alan Whinery;
Oggetto: Re: [perfsonar-user] BWCTLD segmantation fault on Raspberry Pi
You’ll need to restart bwctld after you install iperf. It only checks on startup if the various tools are available.
On Dec 19, 2014, at 8:37 AM, Gaetano Vocca <> wrote:
you are right, I tried to perform the exact test you suggested but I encountered a problem.
bwctl -T iperf -y J -u -c <receiver ip>
from the Raspberry I get:
bwctl: Requested tools supporting the requested options not available by both servers. See the '-T' option
bwctl: Available tools that support the requested options: iperf3
I also compiled bwctl by running
./configure --enable-iperf --enable-nuttcp --with-iperf3=/usr/local/bin/iperf3
to explicitly support iperf. So I thought to go by direct call to iperf3.
Please let me know if there is anything else I can do to help investigating.
Da: Aaron
Brown [mailto:]
Inviato: venerdì 19 dicembre 2014 13:35
A: Gaetano Vocca
Cc: Alan Whinery;
Oggetto: Re: [perfsonar-user] BWCTLD segmantation fault on Raspberry Pi
On Dec 19, 2014, at 6:09 AM, Gaetano Vocca <> wrote:
thank you, I was able to install iperf on the Raspberry by means pf apt-get.
Coming to Aaron’s question below, I was able to run iperf3
iperf3 -u -c <always the same receiver>
from the Raspberry and it worked, so it seems more a bwctl issue, correct?
I’m trying to narrow it down to bwctl or bwctl when running iperf3, which is why i suggested doing a specifically bwctl/iperf test.
Da: [mailto:] Per
conto di Alan Whinery
Inviato: giovedì 18 dicembre 2014 23:51
A:
Oggetto: Re: [perfsonar-user] BWCTLD segmantation fault on Raspberry Pi
I usually get iperf by doing "apt-get install iperf" on a standard Raspbian install...
On 12/18/2014 12:34 PM, Gaetano Vocca wrote:
Thank you but I am actually looking for Iperf in order to follow Aaron 's suggestion.
Il giorno 18/dic/2014, alle ore 23:30, Brian Tierney <> ha scritto:
On Thu, Dec 18, 2014 at 2:22 PM, Gaetano Vocca <> wrote:
Hi Aaron,
Thank you for your kind answer.
I will surely try but would you please point me to the repository for Iperf?
Thank you
Gaetano
> Il giorno 18/dic/2014, alle ore 22:13, Aaron Brown <> ha scritto:
>
> Hi Geatano,
>
> Could you try running it with iperf or nuttcp instead of iperf3, to see if it’s a bwctl issue or an iperf3 issue.
>
> Cheers,
> Aaron
>
>> On Dec 18, 2014, at 2:11 PM, wrote:
>>
>> Hello,
>> this is my first post and I would like to say hi to the list members and thank
>> you for all the nice work about the bwctl suite.
>>
>> It is indeed about bwctld that I am writing here because I am trying to run it
>> on a Raspberry Pi with latest Raspbian (Sept 2014).
>> I downloaded the latest (at time) sources (1.5.2) and I went through the whole
>> building flow without any problem. I am able to run tests in almost any way
>> except for the case in which the Raspberry is the "sending" machine (e. g.
>> bwctl -T iperf3 -u -c <receiver ip>) of UDP traffic.
>> In fact, in such case, I find in the logs
>>
>> raspberrypi bwctld[2589]: FILE=endpoint.c, LINE=1455, _BWLEndpointStatus:
>> Child #2590 exited from signal #11
>>
>> This is deterministic, it happens all the times but only when running the test
>> from the Raspberry with -u and -c. I tested the same code on a regular PC and
>> it worked fine.
>>
>> Do you have an idea of what could be the issue?
>>
>> Thank you in advance
>> Gaetano
>
|
