Skip to Content.
Sympa Menu

ndt-users - Re: how are test results being calculated based on WEB100 kernel variables

Subject: ndt-users list created

List archive

Re: how are test results being calculated based on WEB100 kernel variables


Chronological Thread 
  • From: Richard Carlson <>
  • To:
  • Subject: Re: how are test results being calculated based on WEB100 kernel variables
  • Date: Tue, 12 Oct 2010 10:59:22 -0400
Christian;

On 10/11/2010 5:28 AM, Christian Reimsbach wrote:
Thanks for all the very helpful answers and comments.

Since I would like to focus on the (up- and download) throughput first,
in order to better understand the WEB100 variables, here a summary of
what I have learned so far thanks to all the answers and comments:

i) The real download throughput>
DataBytesOut*8/(SndLimTimeRwin+SndLimTimeCwnd+SndLimTimeSender)

ii) The real upload throughput>
DataBytesIn*8/(SndLimTimeRwin+SndLimTimeCwnd+SndLimTimeSender)

The NDT server only analyzes/stores results from the server-2-client test. In addition, the test time value varies slightly between the server and client (some data in flight when the connection closes) and the application and kernel may have slightly different times as well.

So while the web100 values listed above in 'i' are a good approximation of the download speed, small differences are to be expected. The NDT server reports the application view of things, not the kernel (web100) view. Also you would need to run the NDT server (web100srv) process with the '-r | --record' or '--snaplog' options to obtain the client-2-server data needed to obtain the DataBytesIn value, but the SndLimTime* values would all be 0.


Now I have three questions which I would like to ask in the round:

1.) Why does the WEB100 Detailed Analysis show that DataBytesIn = 0 (for all
the tests I have been running so far)?

See above, this is the s2c test so there is no data being sent by the client, thus the DataBytesIn value = 0.

2.) How can one calculate the upload throughput otherwise?
There is no good way to calculate this value using the Web100 data.

3.) According to the WEB100 values below and the formula shown above my
download throughput would be 23.82Mb/s.
This is higher than the value indicated during the 10s inbound (S2C) test
(23.21Mb/s). [A remark at this point: the SndLimTransRwin was zero?!]
If I understand Daniel correctly I should now expect the calculated value to
be lower due to the TCP headers, which have not been taken into account here.

Two points. The DataBytes* variables just count the payload, not the IP or TCP header values. The time difference between 23.8 Mbps and 23.2 Mbps is about 250 msec. This is well within the time variance between when the kernel closed the connection and when the application exited the send loop and completed a few more instructions.

Rich

Thanks and best regards

Christian

On Thu, 2010-10-07 at 18:46 -0400, Daniel Romero wrote:
Hi Christian,

Just remember, DataBytesIn and DataBytesOut doesn't include the TCP
Headers overhead. You will get a little less bandwidth that expected.

Regards,
DR


2010/10/7 Christian
Reimsbach<>
Thanks!

But if I understand correctly, then one should be able to
calculate the throughput thanks to the following variables:

(DataBytesIn | DataBytesOut) * 8 / Duration

In my case download throughput would be: 30157608 [Bytes] *
8 / 10132874 [?s] = 23.80 [?B/s]

Can that be? In particular since according to tcp-kis.txt
"Duration" is measured in second.

Christian



On Thu, 2010-10-07 at 17:37 -0400, Rich Carlson wrote:
> Christian;
>
> The reported throughput values are not calculated or derived from
the
> web100 data. These values are calculated using the measured test
data.
> The server keeps a counter with the number of bytes
sent/received and
> it also calculates the time it spend sending/receiving data from
the
> client. The throughput values are then calculated as bytes/time.
>
> Rich
>
> On 10/7/2010 5:17 PM, Christian Reimsbach wrote:
> > Hi,
> >
> > I am trying to understand how outbound and inbound throughput
are being
> > calculated based on the WEB100 kernel variables.
> >
> > I read Rich's answer to Lize saying that:
> >
> > "The speeds reported in the Test Results section are the
measured speed
> > achieved during this test. The values reported in the More
Details
> > section are calculations of the maximum possible speed based
on the
> > buffer size and RTT. [...] The NDT report calculates the max
possible
> > speed by dividing the appropriate max buffer value (sender,
receiver,
> > congestion control) by the average RTT. The theoretical limit
is
> > calculated using the Mathis et.al. formula where speed is a
function of
> > packet size, RTT, and packet loss."
> >
> > I am still confused where in my case the 23.21Mb/s and 927kb/s
(see
> > below) come from. Or does Rich's answer mean that the "speeds
reported
> > in the Test Results section" cannot be derived out of the
WEB100 variable?
> >
> > Thanks!
> >
> > Christian
> >
> >
> >
> > WEB100 Enabled Statistics:
> > Checking for Middleboxes . . . . . . . . . . . . . . . . . .
Done.
> > Checking for firewalls . . . . . . . . . . . . . . . . . . .
Done.
> > running 10s outbound test (client-to-server [C2S]) . . . . .
927.0kb/s
> > running 10s inbound test (server-to-client [S2C]) . . . . . .
23.21Mb/s
> >
> > ------ Client System Details------
> > OS data: Name = Linux, Architecture = amd64, Version =
2.6.32-25-generic
> > Java data: Vendor = Sun Microsystems Inc., Version = 1.6.0_20
> >
> > ------ Web100 Detailed Analysis ------
> > Cable modem/DSL/T1 link found.
> > Link set to Full Duplex mode
> > Information: throughput is limited by other network traffic.
> > Good network cable(s) found
> > Normal duplex operation found.
> >
> > Web100 reports the Round trip time = 21.57 ms; the Packet size
= 1448
> > Bytes; and
> > 69 packets retransmitted, 369 duplicate acks received, and 373
SACK
> > blocks received
> > The connection stalled 1 times due to packet loss
> > The connection was idle 0.23 seconds (2.3% of the time)
> > S2C throughput test: Packet queuing detected: 1.73%
> > This connection is network limited 99.6% of the time.
> >
> > Web100 reports TCP negotiated the optional Performance
Settings to:
> > RFC 2018 Selective Acknowledgment: ON
> > RFC 896 Nagle Algorithm: ON
> > RFC 3168 Explicit Congestion Notification: OFF
> > RFC 1323 Time Stamping: ON
> > RFC 1323 Window Scaling: ON; Scaling Factors - Server=7,
Client=7
> >
> > Server 'ndt.iupui.donar.measurement-lab.org' is not behind a
firewall.
> > [Connection to the ephemeral port was successful]
> > Client is probably behind a firewall. [Connection to the
ephemeral port
> > failed]
> > Information: Network Middlebox is modifying MSS variable
> > Server IP addresses are preserved End-to-End
> > Information: Network Address Translation (NAT) box is
modifying the
> > Client's IP address
> > Server says [85.168.247.43], but Client says [192.168.0.10]
> >
> > WEB100 Kernel Variables:
> > Client: localhost/127.0.0.1
> > CurMSS: 1448
> > X_Rcvbuf: 87380
> > X_Sndbuf: 926744
> > AckPktsIn: 1854
> > AckPktsOut: 0
> > BytesRetrans: 99912
> > CongAvoid: 1074
> > CongestionOverCount: 0
> > CongestionSignals: 6
> > CountRTT: 1486
> > CurCwnd: 33304
> > CurRTO: 232
> > CurRwinRcvd: 776192
> > CurRwinSent: 5888
> > CurSsthresh: 17376
> > DSACKDups: 2
> > DataBytesIn: 0
> > DataBytesOut: 30157608
> > DataPktsIn: 0
> > DataPktsOut: 20384
> > DupAcksIn: 369
> > ECNEnabled: 0
> > FastRetran: 5
> > MaxCwnd: 403992
> > MaxMSS: 1448
> > MaxRTO: 1263
> > MaxRTT: 485
> > MaxRwinRcvd: 776192
> > MaxRwinSent: 5888
> > MaxSsthresh: 201272
> > MinMSS: 1448
> > MinRTO: 209
> > MinRTT: 4
> > MinRwinRcvd: 5888
> > MinRwinSent: 5792
> > NagleEnabled: 1
> > OtherReductions: 10
> > PktsIn: 1854
> > PktsOut: 20384
> > PktsRetrans: 69
> > RcvWinScale: 7
> > SACKEnabled: 3
> > SACKsRcvd: 373
> > SendStall: 0
> > SlowStart: 391
> > SampleRTT: 26
> > SmoothedRTT: 29
> > SndWinScale: 7
> > SndLimTimeRwin: 0
> > SndLimTimeCwnd: 10087802
> > SndLimTimeSender: 40308
> > SndLimTransRwin: 0
> > SndLimTransCwnd: 29
> > SndLimTransSender: 29
> > SndLimBytesRwin: 0
> > SndLimBytesCwnd: 29560040
> > SndLimBytesSender: 597568
> > SubsequentTimeouts: 0
> > SumRTT: 32048
> > Timeouts: 1
> > TimestampsEnabled: 1
> > WinScaleRcvd: 7
> > WinScaleSent: 7
> > DupAcksOut: 0
> > StartTimeUsec: 694357
> > Duration: 10132874
> > c2sData: 2
> > c2sAck: 2
> > s2cData: 8
> > s2cAck: 4
> > half_duplex: 0
> > link: 100
> > congestion: 1
> > bad_cable: 0
> > mismatch: 0
> > spd: 23.82
> > bw: 29.86
> > loss: 0.000294349
> > avgrtt: 21.57
> > waitsec: 0.23
> > timesec: 10.00
> > order: 0.1990
> > rwintime: 0.0000
> > sendtime: 0.0040
> > cwndtime: 0.9960
> > rwin: 5.9219
> > swin: 7.0705
> > cwin: 3.0822
> > rttsec: 0.021567
> > Sndbuf: 926744
> > aspd: 0.00000
> > CWND-Limited: 769.73
> > minCWNDpeak: 1448
> > maxCWNDpeak: 403992
> > CWNDpeaks: 6
> >
> > The theoretical network limit is 29.86 Mbps
> > The NDT server has a 452.0 KByte buffer which limits the
throughput to
> > 327.83 Mbps
> > Your PC/Workstation has a 758.0 KByte buffer which limits the
throughput
> > to 274.58 Mbps
> > The network based flow control limits the throughput to 142.91
Mbps
> >
> > Client Data reports link is 'T1', Client Acks report link is
'T1'
> > Server Data reports link is 'OC-48', Server Acks report link
is 'T3'



--
Richard Carlson
DOE ASCR -- SC-21.1 / GTN
1000 Independence Ave. SW
Washington, DC 20585
P: (301) 903-9486

Archive powered by MHonArc 2.6.16.

Top of Page