ndt-users list created

[Richard Sanger <>]

Good to hear this is working now. :)

It would be nice to never have tests failing, so if you find anything more out about this let us know.
NDT is good at recovering when stuff breaks, so even if this happens the server should continue to run.
Whenever a client connects, NDT fork()'s itself and the child handles the test.

The child can leak memory/segfault without breaking the whole NDT server, and it will always be killed after 45ish seconds so it wont hang.

Once this happens NDT can start the next clients test.

On Sat, Apr 13, 2013 at 6:45 AM, Daniel A. Ramaley <> wrote:

I installed your kernel packages, recompiled the userland (i didn't
think that was necessary, but also didn't think it would hurt), and then
recompiled NDT after applying the patch you sent.

And now it works! Well, mostly. One time after rebooting the NDT server
the tests hung on the firewall test. But when i killed ndtd and
restarted it, it was fine. And when i rebooted again, it was fine. So it
is an intermittent issue at best. Unfortunately, the one time it did
happen i was not running ndtd with any debug flags so i don't have any
useful output from it. But, most of the time it seems to work OK.

Thank you for your work on this.

--Dan

On 2013-04-12 at 10:34:26, Richard Sanger wrote:
>Hi Daniel,
>
>I've tried ndt-web10g on a 3.2 kernel and sadly it appears the
>web10g-userland-2.0.4 doesn't actually work with the patched 3.2
>kernel. Instead you should be using the estats_userland-2.0.1, which
>wont work with ndt-web10g because they changed the name of the
>library name from estats to tcpe along with the function names (from
>estats_* to tcpe_*).
>
>So for now the best way forward would be to use a newer kernel, 3.5
>will work (3.4 also might??).
>My 3.5 kernel is

>here<https://drive.google.com/folderview?id=0B-PiO7DvhNkJUDNwcTZjVGtJN
>mc&usp=sharing>I've been using this with Debian squeeze myself without

>issues.
>
>I've attached a patch intended to be applied on top of the new Web10G
>branch (revision 812).
>I don't have commit access on the subversion myself so I'll pass this
>on and hopefully it'll be in there soon.

>This will fix the "*test_min() failed to get web10g connection data,
>rc=0*" issue that I found for the 3.5 kernel.

>
>As for troubleshooting Web10G this is what I see using a 3.5 kernel.
>The following line shows in dmesg once I modprobe tcp_estats_nl
>[   391.503075] tcp_estats netlink module initialized.
>Don't expect anything in /proc/web100 this is the old way of doing
>things which Web100 used and early versions of Web10G.
>The new patches are all netlink now (hence the nl at the end of
>tcp_estats_nl).
>

>You should also try running *listconns *which is found in
>web10g-userland-2.0.4/util/C.
>Make a TCP connection 'wget google.com' and then run *listconns* or
>*sudo listconns* straight after/during because connections only stick

>around for a couple of seconds. You should the connection.
>
>Cheers,
>Richard

__
Daniel A. Ramaley
Network Engineer 2

Dial Center 112, Drake University
2407 Carpenter Ave / Des Moines IA 50311 USA
Tel: +1 515 271-4540
Fax: +1 515 271-1938
E-mail: