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: Aaron Brown <>
  • To: Jordan McCarthy <>
  • Cc: "" <>
  • Subject: Re: [ndt-dev] Final(?) Release Candidate for NDT 3.7.0
  • Date: Thu, 9 Apr 2015 19:04:35 +0000
  • Accept-language: en-US
  • Authentication-results: opentechinstitute.org; dkim=none (message not signed) header.d=none;

Hey Jordan,

Given the performance … eccentricities that have been encountered, we’ll need
to do another -rc with some changes to the warning message (along with having
it use the flash applet’s definition of ‘good environment’). Given that the
WebSockets branch has been stable, my thought is that we could merge that in
for -rc4. Then when we do work some more work on the websocket client, it’s
just a minor release to update the client instead of the whole websocket
environment too. What do others think?

Cheers,
Aaron


> On Apr 9, 2015, at 2:00 PM, Jordan McCarthy
> <>
> wrote:
>
> -----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