Skip to Content.
Sympa Menu

ndt-dev - Re: [ndt-dev] Final(?) Release Candidate for NDT 3.7.0

Subject: NDT-DEV email list created

List archive

Re: [ndt-dev] Final(?) Release Candidate for NDT 3.7.0


Chronological Thread 
  • From: Jordan McCarthy <>
  • To:
  • Subject: Re: [ndt-dev] Final(?) Release Candidate for NDT 3.7.0
  • Date: Thu, 09 Apr 2015 14:00:57 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi everybody,

I'm relieved to be able to report (a) that I've been able to replicate
Jeremy's observations of weirdly low upload speeds in the Flash client
by running tests against the server that he set up, and (b) that the
performance disparities exhibited by that server do not appear to show
up in the M-Lab test environment. So I *think* whatever problem he
encountered is likely the result of some misconfiguration on the
server itself, rather than any specific problem with RC3.

Jordan McCarthy
Open Technology Institute @ New America
Public Key: 0xC08D8042 | 4A61 3D39 4125 127D 65EA DDC2 BFBD A2E9 C08D 80
42

On 04/06/2015 03:59 PM, Aaron Brown wrote:
> Hey Jordan,
>
>> On Apr 6, 2015, at 3:40 PM, Jordan McCarthy
>> <>
>> wrote:
>>
> Completely agreed. In fact, this was the very reason that we
> added environment-detection code to the flash client that (by
> default) completely prevents it from running on anything except
> the environments you mentioned, and shows a warning message
> explaining the problem:
> http://files.opentechinstitute.org/~mccarthy/flash-error.html.
>
>> Ok, that information isn’t getting to the javascript client then.
>> Is there a nice way to call and check if it’s on a bad platform?
>
> I am quite concerned about Jeremy's reports, however, because they
> do indeed point to yet another, hitherto unseen cause of
> performance disparities between Flash and everything else. And it
> is true that there has clearly been considerable historical
> instability in the Flash runtime's treatment of socket I/O (as
> evidenced by the fact that the older versions of the runtime used
> by *NIX return such horrible numbers).
>
>> Would it be possible for you to work with Jeremy to figure out
>> what’s going on? If we’re seeing poor results on the only known
>> good platform, that’s not a good sign…
>
>> Cheers, Aaron
>
>
> Jordan
>
> Jordan McCarthy Open Technology Institute @ New America Public Key:
> 0xC08D8042 | 4A61 3D39 4125 127D 65EA DDC2 BFBD A2E9 C08D 80 42
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCgAGBQJVJr5ZAAoJEL+9ounAjYBCzvgH+wU8Iugs9+s6svF4YH7pNfVq
i1LoQKzeF8QDYds6zDbUF8O8+yMDT6ifOiJq/q9bA5kf1PumFlB4UQYL6vkHOsa9
hsnGadKKTVZsrx5Nilou5i/SxJbp0h4lCO1Ko3XvEs1KEq3QaU8ji09Sot9ReXjB
J81KY0NtHZZEIQad0S/N142kt3ITCjYvGGi7hV2G8/+/Ddp14rbG8eFDSXZL1MED
Fe+m0iCSVjHsUHzJQ5ChLliu6YQhivAgCGa4WleEpUbB3tpxUcIheO1aMVi1ceuO
lbFX5D99Qxom2UOpmsaZ4Ywsdg7CLRyNNgGVBkiCkCcIWyTAd74tdRlLemOgTlw=
=m4hd
-----END PGP SIGNATURE-----



Archive powered by MHonArc 2.6.16.

Top of Page