NDT-DEV email list created

[Tiziana Refice <>]

On Thu, Mar 13, 2014 at 10:11 PM, Matt Mathis <> wrote:

I strongly suggest that you capture the message "This connection is receiver limited xx.xx% of the time" from the server.  If it is present, the client itself is at least partially the bottleneck, and the results are a false fail as a network speed test.

Be aware that the network is a real time device, requiring application attention every few mS or uS depending on the link speed.  Typical GUIs consider it fine to stall the main thread for 10s of mS while the make some pretty drawing, however this is way too long for all but the slowest networks.  (True threading, which permits asynchronous execution solves this, but I am under the impression that typical GUIs don't support it).

Anyhow the c-client should be able to hit 941 Mb/s on the same LAN (The NPAD c-client does so easily).   I would be impressed if any scripted clients can come anywhere close.  As you add eye candy, you lower the maximum data rate for which the tool is useful, and expose users to false speed tests, especially on older devices.   Given that services above 20Mb/s are pretty common this should be a real concern.

Totally agree that any UI improvement should not affect the accuracy of the test.

That's why I think it's a good idea to implement the UI in _javascript_, with non blocking callbacks to Flash.

However, I don't have any experience with the new-ish multi-threading support in actionscript. 

Rich, I don't believe that there is any useful way to detect this problem for c2s tests.  Correct?

Thanks,

--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our services to speak in defiance of unjust governments.   We treat privacy and security as matters of life and death, because for some users, they are.

On Sun, Mar 9, 2014 at 10:21 AM, Richard Carlson <> wrote:

Sebastian;

Thank you for taking on the task of updating the NDT package and client.  As the original author of the NDT system I would like to make a few remarks.  Please consider them as you move forward.

First off, note that this system is called the Network Diagnostic Tool (NDT) not the Network Speed Tester.  The idea behind the tool was to help both the user and the network administrator understand WHY a client achieved the observed results.  If the only goal was to print the connection speed, then this system would be a whole lot simpler.

So, while I think it is possible and worthwhile to look for ways to improve the UI, I suggest that it is important to go beyond simply reporting the achieved test speed.

One of the main goals of the NDT was to tell the user not just the achieved upload/download speed, but what factors limited that speed. Those factors include the TCP configuration settings on the users PC and the server, the network link capacity, the type of network link (wired or wireless), other competing traffic, and broken/failing hardware.

For example it use to be that most TCP stacks had a small 64 KByte fixed TCP buffer setting that would limit the achieved speed below the network capacity.  The NDT server displays that information at the end of the test.  It would be interesting to display this in rea-ltime as well, say as a red line on a speedometer like display.  The TCP buffer size and RTT values can be extracted from the server during the middlebox test and sent to the client for display as necessary.

Adding animation to the client, making the text appear/disappear as appropriate and in informative places without dominating the screen are all good ideas.  But also think about ways to let the user know WHY the system reported the achieved speeds.  Help them know when it's time to complain to the ISP and when it isn't.

The Diagnostic function is pretty unique in network testers.  Any mechanism that helps highlight this function will only improve the NDT's usefulness.

Thanks again for helping make NDT a better tool.

Regards;
Rich


On 03/07/2014 04:35 AM, Sebastian Kostuch wrote:

Hi,
still looking forward to your comments :). At the beginning of next week
I will probably attempt to
create some tickets related to these improvements so it would be nice to
know which of my thoughts
are worth implementing and which are not (also I am very receptive for
your own ideas).

Kind regards,
Sebastian Kostuch

On 26.02.2014 14:51, Sebastian Kostuch wrote:

Hi,
after investigating current JS UI I think that part which lacks the
most of some improvements is the
one showing currently running tests. So most of my proposals will
concecrate on this view.
Here is the list of all of my suggestions:
1. I think that what could make present UI more attractive to user are
live results.
    I mean that during download and upload tests it would be good to
show some kind of gauge
    presenting speed at current moment.
    So during speed tests we could add some kind of speedometer gauge
at the center (with the
    current results shown within it). During test its indicator will
dynamically point at current speed.
2. Move addresses of server and client to the top left and top right
part of page accordingly (also
    with little smaller font size for labels).
3. "Preparing your tests" text could dissapear right after this stage
is completed. Also this information
    (and text indicating which test is currently running) would be
placed right below gauge. What about
    making this text blinking also?
4. After first speed test result would be saved and shown on the
bottom-left part of page. Accordingly
    after second one proper text will be shown on botom-right (and
after a while whole page will dissapear
    to show summary one).
5. To make UI nicer we could add some kind of animations on left and
right sides of page that will
    be graphical representation of currently running speed test. I
mean that i.e. during download test
    there will be small arrows moving from top to the bottom part of
site (or maybe showing one by
    one and after some amount of them will be reached then animation
will start from beginning).
6. On summary page we could add some small nice looking text field
which will show web100/web10g
    variables (it will be auto-scrolling and when user clicks on this
then he/she will be redirected to
    advanced page). Or maybe instead of text field add some small
board on which these values will
    display and dissapear within set time one by one (or better more
at the same time). Maybe good
    place for this element would be between "Download speed" result
and "Test again" button
    (probably both results rectangles need to be made a bit smaller in
height to achieve it).
7. Variable's values on advanced page could be displayed in table to
make them more legible.

What do you think about such changes? Also I'm receptive to your ideas
about what could be
done to make current JS UI look nicer.

Regards,
Sebastian Kostuch