NDT-DEV email list created

[Aaron Brown <>]

Hey Sevastian,

I'm preparing to move to Virginia so haven't been able to look at the various requests. I'm presuming this work and the work Peter has been doing are incompatible. Is that accurate? If so, is there a plan to get them to work together so they can both be merged? Also, are the protocol changes you've proposed compatible with the json protocol and what do they look like?

Cheers,

Aaron

On Thursday, June 25, 2015, Sebastian Kostuch <> wrote:

Hi,
I've added additional test run where server is run with extended test options and client requests those tests.
I've also tested MultiplePorts changes when using old client/server with our new one to ensure that nothing
will break when connecting old client with new server and new client with old server. It seems like everything
is working ok and there should be no issues with using these versions so if there won't be any feedback blocking
from merging these changes into master I will do so tomorrow.

Regards
Sebastian

On 24.06.2015 18:14, Peter Boothe wrote:

A unit-testing framework was introduced to NDT a little while back.  It can be seen in action in all the files named *_unit_tests.c, and the complete source code of the unit testing framework can be found in unit_testing.c and unit_testing.h.  It's compatible with Automake and Autoconf, which actually have built-in support for unit testing.

This means that we can now type "make check", and pieces of the code will be unit-tested and end-to-end tested. Not all the code is tested, but hopefully over time an increasing percentage of the code will be. This way we can make sure, as part of the build process, that old bugs haven't reappeared and that new features work as advertised.

I recognize that the MultiplePorts features were not built with unit-testing in mind, so instead of trying to shim unit-testing onto its component parts (which looks like it would be a big pain), can we add some end-to-end tests of the new functionality (and keep the unit tests of the old functionality) in web100srv_unit_tests.c?  That way we can be sure that these changes (a) do actually work and (b) don't break old clients, and we can encode those guarantees in code to make sure they stay true.  It shouldn't require too much new work to do - I think the code would be an almost line-for-line copy of the test_e2e() function, but with a different command line for starting the NDT client.

  -Peter

On Wed, Jun 24, 2015 at 7:37 AM, Sebastian Kostuch <> wrote:

Hi all,
I've ended up with fixing issues that Aaron suggested in comments to multiple streams support commit (link here), thanks for all of them.
All changes are available on MultiplePorts branch. We look forward to merge this branch into master so NDT will gain some new functionalities
regarding extended throughput tests.

These changes are ready to review and it would be very appreciated if someone could check if code looks ok and all works as expected
(I've tested it on my own however it would be good if someone would confirm that there are no new issues after these changes).

If you have any comments then please leave them as a line note in proper commit or write as an answer to this mail and I will address
them all.

Below are listed the most important changes that MultiplePorts branch include:
    * added 2 new tests which extend current throughput ones (Java client runs them by default, in C client you need to use --enables2cext or/and --enablec2sext options)
    *  options related to extended tests (for details please see 'Extended tests code' section in server manual):
        - setting duration of throughput test
        - enable throughput snapshots with possibility to specify its delay and offset
        - setting number of streams used in mentioned tests (up to 7)
    * added possibility to save web100/web10g variables related to each stream in separated file (--savewebvalues option)
    * packet trace include packets from all streams however only the ones from first stream are used for network testing (there is already separated thread on extending this functionality in future)
    * every stream is being snapshotted, however due to some high CPU usage on some configurations I've added possibility to disable snapshots at all (--disablesnaps option), they are enabled by default as they were so far

Thank you for any feedback.

Regards
Sebastian

--

ᴹ̶LAB | Measure the Internet, save the data, and make it universally accessible and useful.