Skip to Content.
Sympa Menu

ndt-dev - Re: [ndt-dev] NDT new version release

Subject: NDT-DEV email list created

List archive

Re: [ndt-dev] NDT new version release

Chronological Thread 
  • From: Sebastian Kostuch <>
  • To:
  • Subject: Re: [ndt-dev] NDT new version release
  • Date: Wed, 06 Aug 2014 07:24:47 +0200

Hi again,
I have implemented automatic detection of installed browser plugins (java/flash). Changes are
available on Issue154 branch. Feel free to review :).

On 04.08.2014 07:22, Sebastian Kostuch wrote:
Thank you all for your feedback. I will let you know as soon as there will be some progress in implementing
this feature :)


On 01.08.2014 19:26, Will Hawkins wrote:
I agree with Aaron and Jakub.

On 08/01/2014 11:01 AM, Jakub Sławiński wrote:
I agree with Aaron. If user can use Java client then it should be used
instead of the Flash one.


On 08/01/2014 04:56 PM, Aaron Brown wrote:
Hey Sebastian,

That’s a tricky question. There are pros and cons with each:

Java: pro: it performs well on all platforms. con: people are disabling it (though with the signing cert, some of these problems may go away)
Flash: pro: pretty much everyone has it. con: it doesn’t perform well in certain configurations.

I guess my preference would be Java due to the performance issues with Flash. What do others think?


On Jul 31, 2014, at 3:38 AM, Sebastian Kostuch <> wrote:

Hi Aaron,
thanks for your response. I will then make changes such as you proposed. Would it be better to use flash or java as default if users have both plugins installed on their system?


On 29.07.2014 16:42, Aaron Brown wrote:
Hi Sebastian,

The best case scenario would be to have the index page choose a sensible default depending on whether flash or java are installed, and make it easy for them to select it on the page if they want something different.


On Jul 25, 2014, at 1:42 AM, Sebastian Kostuch <> wrote:

Hi Aaron,
we will do our best to try to help you with mentioned task. When it comes to swapping "backend"
client then ATM there is script available (" which allows to choose if user prefers
flash or java backend and properly updates HTML code. Is such a solution acceptable or should we
rather make it different way?


On 22.07.2014 19:22, Aaron Brown wrote:
Hey Jakub,

On Jul 22, 2014, at 10:52 AM, Jakub Sławiński <> wrote:


I think we will be able to help with the mentioned issues.

Sebastian, can we already swap between flash and java backend on the
html level? Moreover, can we help with packaging up RPMs?
If you could create RPMs for the flash components, that’d be great. There’s a spec file in the trunk of the repository that you can add an additional flash client component to.



On 07/21/2014 04:58 PM, Aaron Brown wrote:
Hey Jakub,

The big open part is getting the flash client packaged so that an admin can do a “yum install [package]”, and have it just work. Among other things, it’ll need to package up something to serve the default flash socket xml stuff, and include a way, in the HTML, to swap between the flash or java applet as the ‘backend’ of the javascript so folks can run either. If you guys can work on packaging up RPMs, that’d be great.


On Jul 21, 2014, at 10:48 AM, Jakub Sławiński <> wrote:


is there any progress regarding new NDT release? What has left to be
done and how we can help to make it happen?


On 07/11/2014 03:15 AM, Richard Carlson wrote:

The approach you describe sounds reasonable. I would be happy to help
test things out once you have them ready.


On 07/09/2014 08:53 PM, Will Hawkins wrote:
Mr. Carlson,

Thank you for adding your insight on this. I certainly appreciate having
the chance to work with people as respected in the measurement world as
you and Matt.

I agree that the goal should be not to tell the user that they are
incapable of choosing a good browser. In fact, I don't actually like
Chrome (shh, don't tell anyone!). I also agree that, in the case where
the user is running a "bad" browser/os combination, the measurements
made with this Flash client will be indicative of general performance on
their connection when running Flash applications (with the caveat that
HTTP-based network i/o is significantly faster than socket-based i/o
because it is implemented better by the runtime across platforms). As a
final note of agreement, I concur that NDT is more than just a "speed

The way that we are going to actually implement this is with a series of
configurable knobs. The person embedding the Flash client in their HTML
will have the option to treat an incompatible browser/os combination as
an error or a warning. They deployer will get to handle that condition
in a callback and display an appropriate message (so that they could say
something in "big bold letters", which I liked!).

If that type of scenario is acceptable to you, the decision is more
about the appropriate default (error or warning). We are close to
finishing up an implementation. Would you be willing to review that when
it's ready and see if it meets your expectations?

Thanks again for adding your thoughts! I was hoping that you'd weigh in.
We have Matt M on a separate thread adding his thoughts as well so I am
confident that we will come to a solid resolution.


On 07/09/2014 08:40 PM, Richard Carlson wrote:

I'm not sure I agree with this idea. While I agree that letting the
user know that the test results are bad due to the Flash runtime
problem, I'm not at all convinced that the proper response is to say
'use Chrome'. It just seems a bit strong to me, like you are saying the
user is too stupid to run a good browser.

I'd prefer to let the test run and put in big bold letters across the
results page or in some other manner indicate that the limiting factor
is the client's flash runtime. That way the user is being informed and
the logged test results can also contain the same notation so they can
be discarded if necessary.

After all, they will get that performance when running other flash apps,
so it would be good for them to know what the limits are.

The whole purpose of the NDT system is to provide advanced diagnostic
messages, not just run speed tests. Showing the user that the test
results are limited and explaining why would be much better than telling
them to 'trust me and replace your browser's flash runtime'.

So for me, the real question is can you make a simple and intuitive
image or text that clearly shows that the problem is the flash runtime
and not the NDT service.


On 07/08/2014 03:09 AM, Sebastian Kostuch wrote:
Hi Will,
IMHO it would be good to disable possibility of running test when
we detect that flash client is being run from within not supported
platform. With this there won't be faked results noted on server
side's statistics.
Also looking forward to any further information
regarding new release :).


On 03.07.2014 02:40, Will Hawkins wrote:
Sebastian and Aaron (and everyone, really),

We at MLab are in the final throes of getting our platform ready
for the
Flash client. In so doing, we've gotten deep into the weeds on the
performance/measurement implications of the Flash runtime.

I wanted to present you with our findings and get your input.

On all platforms (Windows, Mac, Linux), running the Flash client in
Google Chrome works a-ok. On Windows, running the Flash client in all
other browsers work great too. On Linux and Mac, however, that is not
the case.

On Mac and Linux where the user runs the NDT Flash client under
runtime (i.e., browsers other than Chrome [even Chromium does not
work]), there is not enough network i/o fidelity to produce
for connections with > ~ 50mbps throughput (on the s2c side).

In other words, Google's independent implementation of the Flash
performs well enough on all platforms, but Adobe's implementation
performs well enough only on Windows.

Because MLab collects lots of data, we don't want our results to be
spoiled by tests whose results are artificially limited. We are
attempting to work out a way to "encourage" users to run the test
in the
environment where we will get the most accurate results. To do so,
settled on the following plan:

1. When the flash client detects that it is being run within a
non-optimal environment, display the following: "Unfortunately, this
test cannot run within your current browser environment. Please run
the test from within Google Chrome, or download M-Lab's Firefox

2. Disallow the flash client from running on any platform that
identifies itself as something other than Windows / Chrome.

What do people think about this plan? Reasonable?

As always, it's great working with everyone in NDT land. I look
to continuing the work :-)


On 06/18/2014 03:06 AM, Sebastian Kostuch wrote:
Hi Will
indeed these changes results in higher speeds (I was able to get ~760
which is quite similar to yours). Also I have checked flash client as
for new JS UI and both speeds are being updated correctly in
This is
really great work! Thanks for this. I have merged these changes into
trunk so
they would be also present in new release.
Also as you probably have noticed I have fixed compilation error when
web100 so I closed appropriated issue related to this.


On 17.06.2014 22:52, Will Hawkins wrote:
Hello Sebastian and Aaron (and MLab'ers CC'd),

We found a way to juice the Flash client and achieve the performance
necessary to accurately measure high-speed network connections.

The change is in r1082.

The solution was counterintuitive (at least for me). Instead of
attempting to read data from the socket as quickly as possible, the
TestS2C class just gets out of the way for the duration of the
test. It
registers only for the "socket close" event. The runtime has the
necessary speed to keep up with the network.

The only problem with this method is keeping the user interface
up-to-date on progress throughout the test. Sebastian, this is
where I
need you to double check. I believe that the code in r1082 properly
updates _s2cByteCount in the appropriate spot for those real-time
updates (specifically onSpeedUpdate). But, please double check!

We were able to measure a connection at ~ 775 mbps using the Flash
client, but it would be great to have as many people test this as
possible. To do so, you can use a pre-compiled version at

On a separate, but related note, please also review r1083 for
in the NDT release. This change allows the client to re-query JS for
test's hostname just before launching a test. This gives the wrapper
page the opportunity to do a AJAX query to determine the test's
hostname. This is important for MLab because we do dynamic server
selection using a web-based API.

I am eager to hear whether you have success with these changes or
not. I
hope you do!


On 06/17/2014 10:53 AM, Will Hawkins wrote:
Just FYI: I believe that we have happened on to an actual solution
the "limit" to the performance of the S2C test. I am going to
it today and do some testing.

If possible, could we hold out on doing a release for a little
pending this investigation?


On 06/16/2014 01:50 AM, Sebastian Kostuch wrote:
Hi Will,
what you mentioned seems reasonable. Would it be possible to merge
changes into trunk in nearest time so we could make new release
example tomorrow
or the day after tomorrow?


On 13.06.2014 17:36, Will Hawkins wrote:

Thanks for sending this out! We (at MLab) are very interested in
deploying a new version of the code so this 'release' looks
like a
good place to fit together! :-) In other words, we (again, MLab)
definitely going to do what you said in 3!

I am out of the office, but I wanted to quickly respond to
point 2.
See below!

Thanks again for driving this process forward!!


On 6/13/14, 4:47 AM, Sebastian Kostuch wrote:
NDT has been updated recently with some major changes (like
json support, new JS UI) so as I have mentioned in some earlier
that would be probably
good time to make new release. I have few questions related to
1. New JS UI would fit well within this new release, however
related to this are still
on work branches and need review. Any feedback would be very
appreciated. These are
following issues: 129, 132, 133.
2. Is Issue144 (URLLoader to flash) supposed to be contained
also in
nearest release version?
If yes, then how does progress with work on this look like? If I
correctly then you, Will,
mentioned that they are well tested and thus almost ready,
Some of these are still up for debate. I am going to forward an
that I just sent to the MLab team with an update on the conundrum
around the HTTP test to give you a sense about why they are up

But, there are also changes in that branch that *need* to be
incorporated into anything that gets released. For instance,
There are parts of r1064 that will have to be integrated no
what (any of the changes that have to do with splitting start
test and
finalize test stages).

Does that make sense?

3. Along with new release on googlecode what do you think about
these changes also
on M-Lab site? They bring many new features at all.

Looking forward to your answers and I hope that next week
could be
celebrated with making
new release of NDT :).

Kind regards
Sebastian Kostuch

Archive powered by MHonArc 2.6.16.

Top of Page