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: Christian Reimsbach <>
  • To: ndt-users <>
  • Subject: Re: how are test results being calculated based on WEB100 kernel variables
  • Date: Mon, 11 Oct 2010 11:28:29 +0200

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)


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)?

2.) How can one calculate the upload throughput otherwise?

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.

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'
>




Archive powered by MHonArc 2.6.16.

Top of Page