evristzam / ndt

Automatically exported from code.google.com/p/ndt
Other
0 stars 0 forks source link

Option --adminview on web100srv(ndtd) causes calculation failures since 3.6.5+ #79

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
While testing the next version of NDT for M-Lab, I have observed that since 
version 3.6.5 up to the current HEAD, the option "--adminview" or "-a" causes 
various calculation errors, for instance with max_theoretical_throughput, that 
are exposed to the client applet.

To reproduce this behavior, build and run a recent NDT server, provide the 
following command line arguments:

    WEB100SRV_OPTIONS="-a -dddddd --log_dir $SLICEDATADIR "
    WEB100SRV_OPTIONS+="--snaplog --tcpdump --cputime --multiple "
    WEB100SRV_OPTIONS+=" --max_clients=40"

With these options, as a result of the calculation error, invalid information 
is returned to the client applet, which generates an error:

    Error parsing test results!
    java.lang.NumberFormatException: For input string: "-nan"

If you then click on 'More Details...', notice that the list of values stops at 
"bw: -nan":
    ...
    link: 100
    congestion: 1
    bad_cable: 0
    mismatch: 0
    spd: 10.24
    bw: -nan

The value "bw:" corresponds to the, max_theoretical_thruput calculation.  If 
you look in the server output you will see something like:

    --packetloss=1 over 8950=0.000112. Link spd=6
    --packets out of order: 0.040060
    --max_theoretical_thruput: -nan. From 1448,0.159434,0.000112
    --window sizes: SndWinScale= -1077280188, RcvwinScale=-1077280184,
    rwin=-0.203188, swin=-0.203187, cwin=-0.203208

There is some corruption occurring, since the input values for the 
max_theoretical_throughput are ok, but the result "-nan" is wrong.  Also, the 
*winScale values are clearly incorrect.

When the "--adminview" option is removed from the server, the calculations are 
performed successfully.

So, a short-term work-around is to disable the option.  However, it is clearly 
a bug that enabling this feature results in incorrect calculations exposed to 
the client.

Original issue reported on code.google.com by solt...@opentechinstitute.org on 4 Mar 2013 at 7:17

GoogleCodeExporter commented 9 years ago

Original comment by smale...@soldevelo.com on 14 Feb 2014 at 11:05

GoogleCodeExporter commented 9 years ago
Is this issue still occur? I can't reproduce this at the latest trunk rev.
My "bw" (in applet), "max_theoretical_thruput" and "*winScale" (in server) 
values looks fine.

Original comment by smale...@soldevelo.com on 14 Feb 2014 at 11:50

GoogleCodeExporter commented 9 years ago
I think that it's no occur any more, but any one should also check it.

Original comment by smale...@soldevelo.com on 14 Mar 2014 at 3:54

GoogleCodeExporter commented 9 years ago

Original comment by smale...@soldevelo.com on 14 Mar 2014 at 3:54

GoogleCodeExporter commented 9 years ago
Can you confirm Sebastian's observations?

Original comment by jslawin...@soldevelo.com on 19 Mar 2014 at 9:22

GoogleCodeExporter commented 9 years ago
Yes, I also wasn't able to reproduce this bug. All mentioned values look ok.

Original comment by skost...@soldevelo.com on 19 Mar 2014 at 9:48

GoogleCodeExporter commented 9 years ago

Original comment by skost...@soldevelo.com on 19 Mar 2014 at 12:40