ndt-users list created

["chet" <>]

Hi both, I have done what you both suggested but the  test still sits at
running 10s inbound test (server to client) . . . . . .
I have watched the connections establish on the server by issuing
netstat -tan and also watched them disconnect but the test still sits in the
same place, is there anything else I can check that will aid help me in
fault finding my problem

Once again thanks

Martyn
----- Original Message ----- 
From: "Richard Carlson" 
<>
To: "Clayton Keller" 
<>;
 
<>
Sent: Thursday, October 13, 2005 11:19 PM
Subject: Re: Slow Inbound Tests


> Hi Clayton;
>
> Hum, I just ran a test against your server and it completed without any
> problem.  I did not get any errors, just the report below.  I am surprised
> to see that the connection is sender limited (perhaps it's a CPU issue
over
> this network path).
>
> How frequently does this delay occur? (often, frequently, occationally,
> ...)  Is there a record in the web100srv.log file?
>
> FYI, after printing the server to client message, the client sits in a
read
> loop.  There are a couple of timers that should prevent this loop from
> running on forever.  At the end of the loop a message is written to the
> Java console (do you see this message?).  It then prints the speed on the
> screen and goes on to grab the test results from the server.  I'll need to
> think about this some more and setup my local test network.  It would help
> if you could tell me what the network that failed looked like (is it a
> simple client -- switch -- server or something more complex.
>
> Rich
>
> Comments:
>
> Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
> running 10s outbound test (client to server) . . . . . 3.92Mb/s
> running 10s inbound test (server to client) . . . . . . 40.37Mb/s
>
> The slowest link in the end-to-end path is a 100 Mbps Full duplex Fast
> Ethernet subnet
>
> Web100 reports the Round trip time = 34.03 msec; the Packet size = 1380
> Bytes; and
> No packet loss - but packets arrived out-of-order 9.48% of the time
> This connection is sender limited 98.00% of the time.
> This connection is network limited 1.32% of the time.
> The theoretical network limit is 309.42 Mbps
> The NDT server has a 16384.0 KByte buffer which limits the throughput to
> 3761.82 Mbps
> Your PC/Workstation has a 257.0 KByte buffer which limits the throughput
to
> 59.09 Mbps
> The network based flow control limits the throughput to 43.93 Mbps
>   End Of Email Message
>
> At 04:11 PM 10/13/2005, Clayton Keller wrote:
>
> >Clayton Keller wrote:
> >>Richard Carlson wrote:
> >>
> >>>Hi Clayton;
> >>>
> >>>This is a bug in the web100srv code.  I forgot to shutdown the control
> >>>socket at the end of the test.  If there are multiple clients then the
> >>>final results are sent in a LIFO manner, so the first client needs to
> >>>wait until all subsequent clients are done before the results are
returned.
> >>>
> >>>I'll issue a patched version soon.  In the mean time you can patch your
> >>>version by hand by adding the line "shutdown(ctlsockfd, SHUT_RDWR);" to
> >>>the web100srv.c file (on line 1126).
> >>>
> >>>Let me know if that fixes things.
> >>>
> >>>Rich
> >>>
> >>>
> >>>---------------------------------------------------------------
> >>>Original code:
> >>>         if (admin_view == 1) {
> >>>             totalcnt = calculate(SumRTT, CountRTT, CongestionSignals,
> >>> PktsOut, DupAcksIn, AckPktsIn,
> >>>                         CurrentMSS, SndLimTimeRwin, SndLimTimeCwnd,
> >>> SndLimTimeSender,
> >>>                         MaxRwinRcvd, CurrentCwnd, Sndbuf,
DataBytesOut,
> >>> mismatch, bad_cable,
> >>>                         (int)bwout, (int)bwin, c2sdata, s2cack, 1,
debug);
> >>>             gen_html((int)bwout, (int)bwin, MinRTT, PktsRetrans,
Timeouts,
> >>>                         Sndbuf, MaxRwinRcvd, CurrentCwnd, mismatch,
> >>> bad_cable, totalcnt,
> >>>                         debug);
> >>>         }
> >>>
> >>>         /* printf("Saved data to log file\n"); */
> >>>
> >>>         /* exit(0); */
> >>>}
> >>>
> >>>main(argc, argv)
> >>>
> >>>----------------------------------------------------------
> >>>Modified code
> >>>         if (admin_view == 1) {
> >>>             totalcnt = calculate(SumRTT, CountRTT, CongestionSignals,
> >>> PktsOut, DupAcksIn, AckPktsIn,
> >>>                         CurrentMSS, SndLimTimeRwin, SndLimTimeCwnd,
> >>> SndLimTimeSender,
> >>>                         MaxRwinRcvd, CurrentCwnd, Sndbuf,
DataBytesOut,
> >>> mismatch, bad_cable,
> >>>                         (int)bwout, (int)bwin, c2sdata, s2cack, 1,
debug);
> >>>             gen_html((int)bwout, (int)bwin, MinRTT, PktsRetrans,
Timeouts,
> >>>                         Sndbuf, MaxRwinRcvd, CurrentCwnd, mismatch,
> >>> bad_cable, totalcnt,
> >>>                         debug);
> >>>         }
> >>>         shutdown(ctlsockfd, SHUT_RDWR);
> >>>         /* printf("Saved data to log file\n"); */
> >>>
> >>>         /* exit(0); */
> >>>}
> >>>
> >>>main(argc, argv)
> >>>
> >>>
> >>>
> >>>
> >>>At 01:54 PM 10/12/2005, Clayton Keller wrote:
> >>>
> >>>>I wanted to address this to the list. I believe there was a similar
> >>>>post a week or so back but I wanted to address this clean.
> >>>>
> >>>>I currently have web100srv running from /etc/init.d/ndt with the
following:
> >>>>
> >>>>/usr/local/sbin/web100srv -a -m -l /var/log/web100/web100srv.log
> >>>>
> >>>>The system is running on Fedora Core 4 using a patached 2.6.13 kernel
> >>>>from kernel.org.
> >>>>
> >>>>The server itself is also sitting behind a PIX firewall.
> >>>>
> >>>>We have noticed that the Outbound Test will run rather quickly, but
> >>>>when the Inbound, server to client, test is ran it can take upwards of
> >>>>several minutes to complete, many times as much as 4 minutes. There
are
> >>>>other times where from the end user's point-of-view it appears the
test
> >>>>never completes although you can see results for the test appear in
the
> >>>>web100.log file. The test though will continue to sit on the unning
10s
> >>>>inbound test (server to client) . . . . . .
> >>>>portion of the test, and many users are beginning to just close out
the
> >>>>window.
> >>>>
> >>>>At this point I am looking for general issues that I can look into and
> >>>>possibly run debug against as far as these tests are concerned.
> >>>>
> >>>>Clayton Keller
> >>>
> >>>
> >>>
> >>>------------------------------------
> >>>
> >>>
> >>>
> >>>Richard A. Carlson                              e-mail:
> >>>
> >>>Network Engineer                                phone:  (734) 352-7043
> >>>Internet2                                       fax:    (734) 913-4255
> >>>1000 Oakbrook Dr; Suite 300
> >>>Ann Arbor,  MI  48104
> >>Thanks Richard,
> >>I've got a test box I will apply and test to, then look at applying this
> >>to the live box and get some good "in the field testing". I'll let you
> >>know how things go.
> >>Clay
> >Rich,
> >
> >It appears that there is still a long delay in the amount of time it
takes
> >to complete the Inbound test (several minutes from my own personal
> >attempts). Could we be looking at network issues on my end. At time I do
> >see the following message returned as well:
> >
> >"Information: Other network traffic is congesting the link"
> >
> >If you would like to try it out for yourself and see if you can recreate
> >this delay, the test is available at:
> >
> >http://speedtest.ruraltel.net:7123/
> >
> >I'd be grateful for any other info I can get, as far as things to look at
> >and run debug against.
> >
> >Clay
>
> ------------------------------------
>
>
>
> Richard A. Carlson                              e-mail:

> Network Engineer                                phone:  (734) 352-7043
> Internet2                                       fax:    (734) 913-4255
> 1000 Oakbrook Dr; Suite 300
> Ann Arbor,  MI  48104
>