Response Mapping

[fabianporta]

Hi,

We are having some issues with iperf since the Server Report is not always shown in the exact same way.

For example, when receiving UDP traffic (server side), the first line appears when the iperf clients connects the server and the second line appears when the traffic is done:

[  3] local 192.168.1.132 port 5001 connected with 192.168.1.112 port 1282

[  3]  0.0-120.0 sec  6.35 MBytes  0.44 Mbits/sec  7.038 ms  509/ 5036 (10%)

read failed: Connection refused 

I need to detect "[*]  0.0-*]" prompt and also read the "\d+\sMbits/sec" value, which is the throughput value that I need, all on the same line!

Apparently, if a line is identified as prompt, iTest does not consider this line as part of the response.

How can I solve it?

Thanks,

Fabian 

[KumarS]

Another way of looking at the problem is that: "iperf -s" does not produce a prompt. It waits for clients to connect, prints some information and continues to run unless interrupted by "control-c".

So I would do the following:

command s1   iperf -s     <-- mark this step to execute in a new thread

.

.

. do your other client stuff here

.

.

.

when you are done with client stuff, you can do:

break s1 [char control-c]

This will stop the "iperf -s" step and iperf -s step will have the complete response. You can put any analysis rule on that step to extract and process data.

[fabianporta]

Hi Kumar,

For some odd reason, when killing the Server with a Ctrl-C, the Server report not allways shows up... this is why I'm waiting for the report to appear.

Fabian 

[KumarS]

You are saying that "iperf -s" does not print report if "control-c" is sent to it. In that case, I think you should try to get a fixed version of iperf.

Another reason could be that you may need to give "iperf" server some time to print results after last client disconnects. In that case, you have to put some sleep duration between the last client and "control-c" step.

Ultimately, if there is genuinely a bug in iperf and you cannot deal with it, you can change the prompt in iTest for that step to look for anywhere in the response. That will not remove the prompt. But that is dangerous because you are moving on from a step which is really not complete or may send more data later in that session causing you problems with responses to other steps in that session. You will have to make sure that "iperf -s" is killed before you have any other step in that session.

[fabianporta]

Yes, this happens because our Access Point buffers the data that can not send until it has available bandwidth to send it to the mobile...

For instance, if  the client sends 1 Mb UDP during 30 seconds and the available bandwidth is only 500Kb, the server will show the report 30 seconds after the client finished to send data.

We are testing Throughput with several channel conditions, which result in different available bandwidth for each scenario.

This causes the waiting time for the iperf server to finish receiving the pushed data is also different everytime.

We've been trying to get this to work better the last few days without luck. 

[KumarS]

I still think the cleaner solution is to wait for maximum amount of time you think iperf needs after the last client is done to print results and then use ctrl-c.

This is because even if you add a prompt which matches one of the data lines, from my experience, all the lines of iPerf look same and the prompt will match any of those lines thus making the step complete too early without getting all the results.

But even if you could find some unique last line in the response, iTest will always remove the prompt from the response. We can add a feature in a future release so that there is an option to control if prompts are removed from the response. iTest removes the prompt from the response - but inserts it into structured data. That might be some help in the sense that you have not lost that information. You may not be able to use it very well in conjunction with the rest of the data in the response very easily though.

[fabianporta]

Thanks for the clarifications Kumar.

Just to know... how do I reference the prompt on the structured data? 

[KumarS]

iTest inserts a "prompt()" query on the step. So you can use query command in your analysis rule on the same step or store the response in a variable and use query command on that variable. The query command syntax is:

[query . prompt()]    <-- if you want to extract prompt on the same step without storing the response

[query variablename   prompt()]    <-- if you have stored the prompt in a variable and you want to extract prompt on some other step.

[PaulD]

Another common way to do this is to add an analysis rule that uses a query which is "prompt()" and that stores the result in a variable, say prompt1.  After that step completes, you can then refer to the value of the prompt from that step using $prompt1.  This stops you from needing to store the entire response just to be able to use the prompt later.