Skip to Content.
Sympa Menu

ndt-dev - Re: [ndt-dev] [ndt] r1012 committed - Download/upload speed in flash client is now being updated during test...

Subject: NDT-DEV email list created

List archive

Re: [ndt-dev] [ndt] r1012 committed - Download/upload speed in flash client is now being updated during test...


Chronological Thread 
  • From: Sebastian Kostuch <>
  • To:
  • Subject: Re: [ndt-dev] [ndt] r1012 committed - Download/upload speed in flash client is now being updated during test...
  • Date: Mon, 28 Apr 2014 08:49:15 +0200
Hi Richard
diagnostic messages says that my computer has only 223 KB buffer size which
limits throughput to 489.02 Mb/s (it is very close value to my maximum result for
upload speed). Also I am having information that "The slowest link in the end-to-end
path is a a 622 Mbps OC-12 subnet", it is weird that only flash client detects such link
while the others sees Gigabit Ethernet. Time spent results: r=98.6%, c=0%, s=1.4%
(for some comparison I am also showing you these values when performing test with
C client: r=96.5% c=0% s=3.5%). These results are almost the same despite how many
times I run tests.
You can also see my whole logs from single test performed on flash client (both server
and client side) in attached files.

Regards
Sebastian

On 23.04.2014 23:51, Richard Carlson wrote:
Sebastian;

What do the NDT diagnostic messages say the problem is?

Where is the time being spent (client, network, or server?)

Does the TCP congestion window open and if so how far.

The whole purpose of the NDT system was to go beyond just printing out a single number that had no real reference to anything.

If your client isn't displaying this data, then extract it from the server log file. I, for one, would be interested in knowing if the server is correctly identifying the problems.

Rich

On 04/23/2014 04:15 AM, Sebastian Kostuch wrote:
Hi,
I have performed some tests once again but this time using two computers
connected
together using Gigabit Ethernet to imitate real usage environment.
Average speeds on C
client were around 900Mb/s on download and upload when in flash they
were again
way lower (~120 download/430 upload). These results are very similar to
these obtained
in localhost test so I think it is confirmation that flash client
currently isn't able to achieve
higher speeds than that.

Regards
Sebastian

On 11.04.2014 09:44, Sebastian Kostuch wrote:
Hi Will
Results from my previous email were the one related to upload speeds only
as I have mentioned there. Meanwhile I was trying to achieve something
similar to download speed as well but I had encountered exactly the
same problems you have mentioned. To avoid infinite while loop I am
just counting time passed since sending/reading first data (similar to
the
Java's code) and break when specified time has passed (also handling
some special errors that may occure during this time and break loop
as well then). When connecting to localhost server data arrive
immediately
when RECEIVE_DATA stage has begun so I run code for retrieving them
right after line setting this (so outside events). However after reading
first packet with 64KB size I was always left with empty socket buffer
(I mean bytesAvailable property). Still trying to do something with it
but in fact making sockets operations in flash outside events
seems rather tricky and not the way it was supposed to be used (or
maybe I am doing something wrong when trying to achieve this ;)).

I am sending you my code related to testing upload speed if you are
interested. The one with download speed does not work at all ATM
due to problems you have also noticed in previous messages. Also
sorry for my delay but I wasn't available during this time.

Regards,
Sebastian

On 09.04.2014 19:40, Will Hawkins wrote:
I was thinking about this some more ...

Using a straight while loop to read the data outside events means that
the socket connection has to happen between the connect() and the first
read() otherwise the socket will throw EOF when we do a read. Assuming
errors and terminating conditions (like EOFs) mean "would block, try
again" there's the distinct possibility that we'll end up looping
infinitely, etc.

This is the reason that we really want to use their events -- so we can
know when a socket connects, at the least. However, once you are w/in an
event handler, the underlying thread is paused and, like I said before,
the I/O is paused and progress is not made.

I'm eager to see your code, Sebastian! You're obviously a magician! :-)

Will

On 04/09/2014 12:43 PM, Will Hawkins wrote:
Sebastian,

Thanks for sending this along. I've also been working on getting
improvements in the Flash client and realized that the event-driven I/O
is the cause of the slow speed. Did you look at some of the strace()
output that I sent along in a separate email thread? It shows how the
I/O events are generated out of a main runloop that pauses 10ms on
every
iteration (on the Linux Flash runtime) (unless there are UI events). In
other words, we can only get *io-arrived* events at that interval.

In trying to find a way around this, I explored threads, as you
suggested. I had to use an Actionscript compiler on a Mac since, like
you said, the compiler available for Linux does not support threads. I
could not get much additional throughput.

The fundamental problem that I ran into was related to the fact that
there was no way to escape event-driven socket "idiom". In other words,
I found that if I attempted to "block" in a *io-arrived* event to read
the entirety of the stream then the underlying thread would not
continue
to process IO and the whole thing ground to a halt.

This is the fundamental reason that we are looking at moving to the
URLLoader model for the S2C test (rather than straight sockets like we
use for the C2S, Meta, etc). This option allows Flash to do the IO
optimization behind the scenes and notify us only when the entire
download is done (and/or the server closes the connection).

That said, are you willing to send me your code? I would love to see
it.
I can send you the testing packages that I've written to test out
threading, etc.

Thanks for continuing to do great work on this!
Will


On 04/09/2014 07:24 AM, Sebastian Kostuch wrote:
Hi,
recently I was trying to improve results obtained in flash client and
finally I was able to find some way to make them better. Currently
all data sending/retrieving processes are done when some specified
events occurs. In java client however it is based just on simple
while loop
where these data are proceeded. When I replaced event written code
to be similar to this java one then I was able to achieve around
2800Mb/s on localhost NDT server which is big improvement compared
to previous ~400. So my assumption is that these events are fired too
seldom to get such higher speeds so data are being less often
proceeded.

Also with these new changes I am having some issues when using Chrome
built-in version of flash player which is simply crashing during
C2S test.
I will let you know if I will manage to fix it and also will try to
get
something
similar in download test.

Just wanted to share information that the problem
with flash client achieving so low speeds could probably be related
to code
not just technology itself. Maybe it will help others to find even
better
solution :).

When it comes to multi-threading I think that it would help
a little but mostly on issue related to GUI updating during
performing such
test so the thread would be supposed to run code only related to test
(currently GUI freezes during while loop but we would use JS UI in the
end so maybe it isn't the most important thing ATM). Unfortunately I
am not able to try to write some multi-threaded code as such version
of SDK and player isn't available on Linux systems (last officially
supported
one is 11.2 while multi-threading was added on 11.4).

Regards,
Sebastian

On 04.04.2014 18:11, Tiziana Refice wrote:

On Fri, Apr 4, 2014 at 12:52 PM, Sebastian Kostuch
<

<mailto:>>
wrote:

Hi
I have performed upload/download tests on clients available in
repo (connecting to localhost server).
They all were run under same conditions (Ubuntu 12.04 Kernel
3.9.1
patched with Web10G-0.9-patch) and you
can see results in attached file. I will list here only average
results (upload[Mb/s]/download[Mb/s])

C Java Flash (version
12.0.0.77)
17311.23/16152.68 16631.00/13752.13 417.31/111.32

I also noticed that in results I had very small PC buffer size
(around 250KB) when compared to
Java one (around 3MB) which I think limits these speeds.
So I suppose that the goal is to try to determine whether it is
flash technology restriction or maybe code issue.
If these speeds will remain far lower than Java/C ones then
would
it make sense to use current flash
client instead of java applet? Or should it be dropped for some
time when maybe some newer version will
improve these results?


Any idea if multi-thread Flash would help here?


Regards
Sebastian Kostuch


On 27.03.2014 23 <tel:27.03.2014%2023>:02, Will Hawkins wrote:

I have submitted a patch to NDT to close the listening
sockets
as soon
as the client connects (for both s2c and c2s tests).

I deployed code with that fix to one of the testing
servers and
confirmed that it does what is expected. It does *not*
change the
results. In other words, the URLLoader in Flash does not
appear to be
attempting to either a) pipeline or b) use multiple
threads to
fetch
content over HTTP. This is what we expected, but it's
good to
confirm.

I will let you know when the code is merged.

The next step is to guarantee that there is no local caching
being done
by the URLLoader. I doubt there is, but we should be sure
just
in case
(Thanks to Matt for suggesting that we test this!).

Will

On 03/21/2014 04:56 PM, Matt Mathis wrote:

Sounds reasonable. I wonder if this approach holds
up if
the client
attempts to use multiple threads? Could you tell if
there
was a second
connection attempted, but it was hung?

From your description, I bet the ndt server does not
close the listen
port once it has accept()'d the data connection. It
probably should.
(The the second request would get an immediate error
rather than an
indeterminant wait).

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 Fri, Mar 21, 2014 at 1:43 PM, Will Hawkins

<
<mailto:>

<mailto:
<mailto:>>>
wrote:



On 03/21/2014 03:20 PM, Will Hawkins wrote:
> Excellent question. My hunch is that it will do
this single-threaded
> (although asynchronously). I am going to check in
to this and I
will let
> you know asap.
>
> Will
>
> On 03/21/2014 03:05 PM, Matt Mathis wrote:
>> Did you check to see how many concurrent
connections it used?
The risk
>> with this approach is that it is entirely legal
for the URL loading
>> machinery to use multiple concurrent
connections.
>>

Although there does not seem to be a way to
determine
if the runtime is
using concurrent connections, I think that we can
infer that it is NOT.

The server allows for exactly one connection for
each
of the ephemeral
ports that it uses for a particular test with a
particular client. I
just ran a S2C test and, concurrent with the test,
attempted to connect
to the same port (using nc). Although the
connection
appeared to have
succeeded, it was not able to "receive" any of the
test data.

It would seem, then, that even if the URLLoader was
attempting to make
concurrent connections, it would not make the test
results any better.
Would you agree with that?

Will
>> 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 Fri, Mar 21, 2014 at 11:48 AM, Will Hawkins
>>
<
<mailto:>
<mailto:
<mailto:>>
<mailto:
<mailto:>
<mailto:
<mailto:>>>>
>> wrote:
>>
>> Hello there!
>>
>> I will send you the full results of the
speed
testing that
we've done as
>> a separate email. We too have noticed
that the
Flash client
does not
>> seem to be as accurate as data rates
increase.
>>
>> However, I've made some progress today and
thought I'd use this
>> opportunity to share:
>>
>> First, nothing about the upload test has
changed. I've left
that alone.
>> This is all about the download test (S2C).
>>
>> I changed the NDT server to spit out a
valid,
minimal set of HTTP
>> response headers before it starts sending
random data. Then,
on the
>> Flash client side, I've treated that data
like
an HTTP
request and used
>> a built-in URL loading class. I thought this
might get around
some of
>> the event-driven I/O latency that seems
to be
a problem (see
follow-up
>> email).
>>
>> Indeed there is some progress. From my
desk to
the testing
server at
>> nuq, I was able to get about 42 mbps
download
speeds. This is
>> approximately 12 mbps higher than I was able
to get with the
>> socket-based version.
>>
>> More importantly, I got similar results
between the Flash
client and the
>> Java client. Both report around 42 mbps
download and around
80% receiver
>> limited. They are eerily similar,
actually. I
will keep
testing to see
>> what I find but I wanted to send this out.
>>
>> Will
>>
>> On 03/21/2014 02:35 PM, Matt Mathis wrote:
>> > Circumstantial evidence suggests that the
flash runtime event
>> processing
>> > may be synchronized to the display refresh
rate.... It
would be
>> > interesting to know it changing the
display
settings
changed the
>> maximum
>> > performance.
>> >
>> > 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 Fri, Mar 21, 2014 at 11:19 AM,
Tiziana Refice
>>
<

<mailto:>

<mailto:

<mailto:>>

<mailto:

<mailto:>

<mailto:

<mailto:>>>
>> >
<mailto:

<mailto:>

<mailto:

<mailto:>>

<mailto:

<mailto:>

<mailto:
<mailto:>>>>>
wrote:
>> >
>> > Will and Matt have been doing some
experiments about that
>> recently.
>> >
>> > Will, could you share the results with
Sebastian?
>> >
>> >
>> > On Fri, Mar 21, 2014 at 10:17 AM,
Sebastian Kostuch
>> >
<

<mailto:>

<mailto:

<mailto:>>

<mailto:

<mailto:>

<mailto:
<mailto:>>>
>>
<mailto:

<mailto:>

<mailto:

<mailto:>>

<mailto:
<mailto:>

<mailto:
<mailto:>>>>>
wrote:
>> >
>> > I think that when connecting to
localhost speed
should be much
>> > more higher (unfortunately I am
not
able to achieve
better
>> > results connecting to another
server). I have just
noticed
>> that
>> > when using C/Java client
results are
in fact way better
>> > (around 14Gb/s for upload and
almost
9Gb/s
download). So it
>> > seems like flash client is somehow
restricted
(tested on
>> > different flash version and
results
are the same).
Could also
>> > someone confirm that on higher
speeds flash client
doesn't
>> > give similar speeds compared to
Java/C ones?
>> >
>> > Regards,
>> > SK
>> >
>> >
>> > On 21.03.2014 10
<tel:21.03.2014%2010> <tel:21.03.2014%2010>
<tel:21.03.2014%2010>
>> <tel:21.03.2014%2010>:51, Tiziana Refice wrote:
>> >> Ideally, it would be better to
test
this change at
much
>> higher
>> >> speed (i.e., as close to 1Gbps as
possible).
>> >> Would it be possible for you to
make such test?
>> >>
>> >>
>> >> On Wed, Mar 19, 2014 at 12:01 PM,
Sebastian Kostuch
>> >>
<

<mailto:>

<mailto:

<mailto:>>

<mailto:
<mailto:>

<mailto:
<mailto:>>>
>>
<mailto:

<mailto:>

<mailto:

<mailto:>>

<mailto:
<mailto:>

<mailto:
<mailto:>>>>>
wrote:
>> >>
>> >> Hi Tiziana,
>> >> I have performed some simple
test which was
executing
>> >> flash client 10 times on my
changes (with
timer set
>> to 1s)
>> >> and on newest trunk
version of
client. Both
were made
>> >> toward localhost NDT server
(newest web10g) to
>> achieve big
>> >> speed. Here are results
(download/upload in Mb/s):
>> >>
>> >> *trunk version*
*version from
Issue131 branch*
>> >> 110.9/439.0
128.1/486.0
>> >> 121.8/456.8
122.2/471.9
>> >> 104.1/471.9
123.6/452.7
>> >> 120.5/478.7
126.4/451.0
>> >> 123.2/515.1
113.3/468.9
>> >> 120.8/462.7
130.8/476.8
>> >> 121.0/433.3
116.7/442.5
>> >> 109.1/473.7
115.6/442.8
>> >> 128.0/469.3
112.5/467.6
>> >> 118.8/469.0
126.5/496.2
>> >>
>> >> average:
>> >> 117.82/466.95
121.57/465.64
>> >>
>> >> These results are very
similar
to each other
so it seems
>> >> that these new events won't
impact accuracy of
test.
>> Is it
>> >> valuable proof for you?
>> >>
>> >> Regards,
>> >> Sebastian Kostuch
>> >>
>> >>
>> >> On 17.03.2014 11:40, Tiziana
Refice wrote:
>> >>> I am concerned this change
(which adds new
events that
>> >>> will fire during the execution
of the test)
will affect
>> >>> the accuracy of the test.
>> >>> I would prefer to have test
data that show
that this is
>> >>> not the case, especially for
very high speeds
(e.g.,
>> >>> 900+Mbps). See last email by
Matt Mathis to
ndt-dev on
>> >>> this topic for details on the
issue.
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Mar 12, 2014 at
12:17 PM,
>>
<

<mailto:>

<mailto:

<mailto:>>

<mailto:

<mailto:>

<mailto:

<mailto:>>>
>> >>>
<mailto:

<mailto:>

<mailto:
<mailto:>>
>>
<mailto:

<mailto:>

<mailto:
<mailto:>>>>>
wrote:
>> >>>
>> >>> Revision: 1012
>> >>> Author:



<mailto:>

<mailto:

<mailto:>>
>>
<mailto:

<mailto:>

<mailto:
<mailto:>>>
>> >>>

<mailto:
<mailto:>

<mailto:

<mailto:>>
>>
<mailto:

<mailto:>

<mailto:
<mailto:>>>>
>> >>> Date: Wed Mar 12
12:17:39 2014 UTC
>> >>> Log: Download/upload
speed in flash
client is
>> >>> now being updated during
test duration
>> >>>
>> >>>
http://code.google.com/p/ndt/source/detail?r=1012
>> >>>
>> >>> Modified:
>> >>>
/branches/Issue131/flash-client/src/TestC2S.as
>> >>>
/branches/Issue131/flash-client/src/TestS2C.as
>> >>>
>> >>>
=======================================
>> >>> ---
/branches/Issue131/flash-client/src/TestC2S.as
>> >>> Fri Feb 21 07:41:20
2014 UTC
>> >>> +++
/branches/Issue131/flash-client/src/TestC2S.as
>> >>> Wed Mar 12 12:17:39
2014 UTC
>> >>> @@ -30,6 +30,8 @@
>> >>> * This class performs
the
Client-to-Server
>> >>> throughput test.
>> >>> */
>> >>> public class TestC2S {
>> >>> + private const
SPEED_UPDATE_TIMER:int =
>> 1000; // ms
>> >>> +
>> >>> // Valid values for
_testStage.
>> >>> private static const
PREPARE_TEST1:int = 0;
>> >>> private static const
PREPARE_TEST2:int = 1;
>> >>> @@ -45,12 +47,14 @@
>> >>> private var
_c2sTestSuccess:Boolean;
>> >>> // Time to send data
to server on
the C2S
>> socket.
>> >>> private var
_c2sTestDuration:Number;
>> >>> + private var
_c2sTestStartTime:Number;
>> >>> private var
_ctlSocket:Socket;
>> >>> private var
_c2sSocket:Socket;
>> >>> private var
_c2sSendCount:int;
>> >>> // Bytes not sent
from last send
operation on
>> >>> the C2S socket.
>> >>> private var
_c2sBytesNotSent:int;
>> >>> private var
_c2sTimer:Timer;
>> >>> + private var
_speedUpdateTimer:Timer;
>> >>> private var
_dataToSend:ByteArray;
>> >>> private var
_msg:Message;
>> >>> private var
_serverHostname:String;
>> >>> @@ -64,6 +68,7 @@
>> >>>
>> >>> _c2sTestSuccess =
true; //
Initially the
>> test
>> >>> has not failed.
>> >>> _c2sTestDuration = 0;
>> >>> + _c2sTestStartTime
= 0;
>> >>> _dataToSend = new
ByteArray();
>> >>> _c2sSendCount = 0;
>> >>> _c2sBytesNotSent = 0;
>> >>> @@ -175,6 +180,8 @@
>> >>>
>> >>> _c2sTimer = new
>> Timer(NDTConstants.C2S_DURATION);
>> >>>
_c2sTimer.addEventListener(TimerEvent.TIMER,
>> >>> onC2STimeout);
>> >>> + _speedUpdateTimer
= new
>> Timer(SPEED_UPDATE_TIMER);
>> >>> +
>> >>>
>>
_speedUpdateTimer.addEventListener(TimerEvent.TIMER,
>> >>> onSpeedUpdate);
>> >>> _msg = new Message();
>> >>> _testStage =
START_TEST;
>> >>>
TestResults.appendDebugMsg("C2S test:
>> >>> START_TEST stage.");
>> >>> @@ -244,6 +251,16 @@
>> >>>
TestResults.appendDebugMsg("Timeout for
>> >>> sending data on C2S
socket.");
>> >>> closeC2SSocket();
>> >>> }
>> >>> +
>> >>> + private function
>> onSpeedUpdate(e:TimerEvent):void {
>> >>> + _c2sTestDuration =
getTimer() -
>> _c2sTestStartTime;
>> >>> + _c2sBytesNotSent =
_c2sSocket.bytesPending;
>> >>> + var
c2sByteSent:Number = (
>> >>> + _c2sSendCount *
>> >>>
NDTConstants.PREDEFINED_BUFFER_SIZE
>> >>> + +
(NDTConstants.PREDEFINED_BUFFER_SIZE -
>> >>> _c2sBytesNotSent));
>> >>> +
>> >>> +
TestResults.ndt_test_results::c2sSpeed =
>> >>> (c2sByteSent *
NDTConstants.BYTES2BITS);
>> >>> + }
>> >>>
>> >>> private function
startTest():void {
>> >>> if
(!_msg.readHeader(_ctlSocket))
>> >>> @@ -267,9 +284,10 @@
>> >>>
removeCtlSocketOnReceivedDataListener();
>> >>>
>> >>> _c2sTimer.start();
>> >>> +
_speedUpdateTimer.start();
>> >>> // Record start
time right before
it starts
>> >>> sending data, to be as
>> >>> // accurate as
possible.
>> >>> - _c2sTestDuration =
getTimer();
>> >>> + _c2sTestStartTime =
getTimer();
>> >>>
>> >>> _testStage =
SEND_DATA;
>> >>>
TestResults.appendDebugMsg("C2S test:
>> >>> SEND_DATA stage.");
>> >>> @@ -288,9 +306,11 @@
>> >>> private function
closeC2SSocket():void {
>> >>> // Record end time
right after it
stops
>> >>> sending data, to be as
accurate as
>> >>> // possible.
>> >>> - _c2sTestDuration =
getTimer() -
>> _c2sTestDuration;
>> >>> + _c2sTestDuration =
getTimer() -
>> _c2sTestStartTime;
>> >>>
TestResults.appendDebugMsg(
>> >>> "C2S test
lasted " +
_c2sTestDuration + "
>> >>> msec.");
>> >>> +
_speedUpdateTimer.stop();
>> >>> +
>> >>>
>>
_speedUpdateTimer.removeEventListener(TimerEvent.TIMER,
>> >>> onSpeedUpdate);
>> >>> _c2sTimer.stop();
>> >>>
>> >>>
_c2sTimer.removeEventListener(TimerEvent.TIMER,
>> >>> onC2STimeout);
>> >>>
>> >>>
=======================================
>> >>> ---
/branches/Issue131/flash-client/src/TestS2C.as
>> >>> Fri Feb 21 07:41:20
2014 UTC
>> >>> +++
/branches/Issue131/flash-client/src/TestS2C.as
>> >>> Wed Mar 12 12:17:39
2014 UTC
>> >>> @@ -31,6 +31,7 @@
>> >>> public class TestS2C {
>> >>> // Timer for single
read operation.
>> >>> private const
READ_TIMEOUT:int =
15000; //
>> 15sec
>> >>> + private const
SPEED_UPDATE_TIMER:int =
>> 1000; // ms
>> >>>
>> >>> // Valid values for
_testStage.
>> >>> private static const
PREPARE_TEST1:int = 0;
>> >>> @@ -48,17 +49,18 @@
>> >>> private var
_ctlSocket:Socket;
>> >>> private var
_msg:Message;
>> >>> private var
_readTimer:Timer;
>> >>> + private var
_speedUpdateTimer:Timer;
>> >>> private var
_s2cByteCount:int;
>> >>> private var
_s2cSocket:Socket;
>> >>> private var
_s2cTimer:Timer;
>> >>> // Time to send data
to client on
the S2C
>> socket.
>> >>> private var
_s2cTestDuration:Number;
>> >>> + private var
_s2cTestStartTime:Number;
>> >>> private var
_s2cTestSuccess:Boolean;
>> >>> private var
_serverHostname:String;
>> >>> private var
_testStage:int;
>> >>> private var
_web100VarResult:String;
>> >>>
>> >>> -
>> >>> public function
TestS2C(ctlSocket:Socket,
>> >>> serverHostname:String,
>> >>>
>> callerObj:NDTPController) {
>> >>> _callerObj =
callerObj;
>> >>> @@ -67,6 +69,7 @@
>> >>>
>> >>> _s2cTestSuccess =
true; //
Initially the
>> test
>> >>> has not failed.
>> >>> _s2cTestDuration = 0;
>> >>> + _s2cTestStartTime
= 0;
>> >>> _s2cByteCount = 0;
>> >>> _web100VarResult =
"";
>> >>> }
>> >>> @@ -172,6 +175,8 @@
>> >>> }
>> >>> _readTimer = new
Timer(READ_TIMEOUT);
>> >>>
_readTimer.addEventListener(TimerEvent.TIMER,
>> >>> onS2CTimeout);
>> >>> + _speedUpdateTimer
= new
>> Timer(SPEED_UPDATE_TIMER);
>> >>> +
>> >>>
>>
_speedUpdateTimer.addEventListener(TimerEvent.TIMER,
>> >>> onSpeedUpdate);
>> >>> _s2cTimer = new
>> Timer(NDTConstants.S2C_DURATION);
>> >>>
_s2cTimer.addEventListener(TimerEvent.TIMER,
>> >>> onS2CTimeout);
>> >>> _msg = new Message();
>> >>> @@ -234,6 +239,13 @@
>> >>> _readTimer.start();
>> >>> receiveData();
>> >>> }
>> >>> +
>> >>> + private function
>> onSpeedUpdate(e:TimerEvent):void {
>> >>> + _s2cTestDuration =
getTimer() -
>> _s2cTestStartTime;
>> >>> +
TestResults.ndt_test_results::s2cSpeed =
>> >>> _s2cByteCount
>> >>> +
*
>> >>> NDTConstants.BYTES2BITS
>> >>> +
/
>> >>> _s2cTestDuration;
>> >>> + }
>> >>>
>> >>> private function
startTest():void {
>> >>> if
(!_msg.readHeader(_ctlSocket))
>> >>> @@ -258,9 +270,10 @@
>> >>>
>> >>> _readTimer.start();
>> >>> _s2cTimer.start();
>> >>> +
_speedUpdateTimer.start();
>> >>> // Record start
time right before
it starts
>> >>> receiving data, to be as
>> >>> // accurate as
possible.
>> >>> - _s2cTestDuration =
getTimer();
>> >>> + _s2cTestStartTime =
getTimer();
>> >>>
>> >>> _testStage =
RECEIVE_DATA;
>> >>>
TestResults.appendDebugMsg("S2C test:
>> >>> RECEIVE_DATA stage.");
>> >>> @@ -290,9 +303,11 @@
>> >>> // Record end time
right after it
stops
>> >>> receiving data, to be as
accurate
>> >>> // as possible.
>> >>> _s2cTimer.stop();
>> >>> - _s2cTestDuration =
getTimer() -
>> _s2cTestDuration;
>> >>> + _s2cTestDuration =
getTimer() -
>> _s2cTestStartTime;
>> >>>
TestResults.appendDebugMsg(
>> >>> "S2C test
lasted " +
_s2cTestDuration + "
>> >>> msec.");
>> >>> +
_speedUpdateTimer.stop();
>> >>> +
>> >>>
>>
_speedUpdateTimer.removeEventListener(TimerEvent.TIMER,
>> >>> onSpeedUpdate);
>> >>> _readTimer.stop();
>> >>>
>> >>>
_readTimer.removeEventListener(TimerEvent.TIMER,
>> >>> onS2CTimeout);
>> >>>
>> >>>
_s2cTimer.removeEventListener(TimerEvent.TIMER,
>> >>> onS2CTimeout);
>> >>> @@ -485,7 +500,6 @@
>> >>>
removeCtlSocketOnReceivedDataListener();
>> >>>
>> >>>
TestResults.appendDebugMsg("S2C test:
>> END_TEST
>> >>> stage.");
>> >>> -
>> >>> if (_s2cTestSuccess)
>> >>>
TestResults.appendDebugMsg(
>> >>>
>> ResourceManager.getInstance().getString(
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>









Client System Details
OS data:: Linux, Architecture: x86
Flash Info: Version = LNX 13,0,0,182
The slowest link in the end-to-end path is a
a 622 Mbps OC-12 subnet
This connection is receiver limited 98.57% of the time
622 Mbps OC-12 link found.
Link set to Full Duplex mode
No network congestion discovered.
Good network cable(s) found
Normal duplex operation found.
Web100 reports the Round trip time = 3.47ms
the Packet size = 65468bytes
No packet loss was observed.
C2S throughput test: Packet queuing detected: 0.00%
S2C throughput test: Packet queuing detected: 0.00%
Web100 reports TCP negotiated the optional Performance Settings to:
RFC 2018 Selective Acknowledgement:
ON
RFC 896 Nagle Algorithm:
OFF
RFC 3168 Explicit Congestion Notification:
OFF
RFC 1323 Time Stamping:
ON
RFC 1323 Window Scaling:
ON; Scaling Factors - Server=8, Client=8
The theoretical network limit is 14396575.85 Mbps
The NDT server has a 647.72 KByte buffer which limits the throughput to
2917.47 Mbps
Your PC/Workstation has a 223.00 KByte buffer which limits the throughput to
502.22 Mbps
The network based flow control limits the throughput to 1439.84 Mbps
Client Data reports link is OC-12
Client Acks report link is OC-12
Server Data reports link is OC-12
Server Acks report link is OC-12
=== Results sent by the server ===
SegsOut: 2888
DataSegsOut: 2888
DataOctetsOut: 188890628
HCDataOctetsOut: 188890628
SegsRetrans: 0
OctetsRetrans: 0
SegsIn: 2879
DataSegsIn: 0
DataOctetsIn: 0
HCDataOctetsIn: 0
ElapsedSecs: 10
ElapsedMicroSecs: 146041
StartTimeStamp: 0
CurMSS: 65468
PipeSize: 65468
MaxPipeSize: 196404
SmoothedRTT: 4
CurRTO: 204
CongSignals: 0
CurCwnd: 654680
CurSsthresh: 1178424
Timeouts: 0
CurRwinSent: 43776
MaxRwinSent: 43776
ZeroRwinSent: 0
CurRwinRcvd: 129024
MaxRwinRcvd: 228352
ZeroRwinRcvd: 0
SndLimTransRwin: 1
SndLimTransCwnd: 0
SndLimTransSnd: 1
SndLimTimeRwin: 9986748
SndLimTimeCwnd: 0
SndLimTimeSnd: 145230
RetranThresh: 8
NonRecovDAEpisodes: 0
SumOctetsReordered: 0
NonRecovDA: 0
SampleRTT: 0
RTTVar: 48
MaxRTT: 8
MinRTT: 0
SumRTT: 9992
HCSumRTT: 9992
CountRTT: 2880
MaxRTO: 212
MinRTO: 204
IpTtl: 64
IpTosIn: 0
IpTosOut: 0
PreCongSumCwnd: 0
PreCongSumRTT: 0
PostCongSumRTT: 0
PostCongCountRTT: 0
ECNsignals: 0
DupAckEpisodes: 0
RcvRTT: 0
DupAcksOut: 0
CERcvd: 0
ECESent: 0
ActiveOpen: 0
MSSSent: 65483
MSSRcvd: 65495
WinScaleSent: 8
WinScaleRcvd: 8
TimeStamps: 1
ECN: 3
WillSendSACK: 1
WillUseSACK: 1
State: 6
Nagle: 1
MaxSsCwnd: 654680
MaxCaCwnd: 0
MaxSsthresh: 1178424
MinSsthresh: 393984
InRecovery: 2
DupAcksIn: 0
SpuriousFrDetected: 0
SpuriousRtoDetected: 0
SoftErrors: 0
SoftErrorReason: 0
SlowStart: 0
CongAvoid: 0
OtherReductions: 0
CongOverCount: 0
FastRetran: 0
SubsequentTimeouts: 0
CurTimeoutCount: 0
AbruptTimeouts: 0
SACKsRcvd: 0
SACKBlocksRcvd: 0
SendStall: 0
DSACKDups: 0
MaxMSS: 65468
MinMSS: 21888
SndInitial: 2080884982
RecInitial: 1191323571
CurRetxQueue: 0
MaxRetxQueue: 0
CurReasmQueue: 0
MaxReasmQueue: 0
SndUna: 2269617726
SndNxt: 2269683194
SndMax: 2269683194
ThruOctetsAcked: 188732744
HCThruOctetsAcked: 188732744
RcvNxt: 1191323571
ThruOctetsReceived: 0
HCThruOctetsReceived: 0
CurAppWQueue: 789245
MaxAppWQueue: 1309360
CurAppRQueue: 0
MaxAppRQueue: 0
LimCwnd: 4294901828
LimSsthresh: 0
LimRwin: 130990
LimMSS: 65495
-~~~Web100_old_var_names~~~-: 1
ECNEnabled: 0
NagleEnabled: 0
SACKEnabled: 3
TimestampsEnabled: 1
PktsRetrans: 0
DataPktsOut: 2888
MaxCwnd: 654680
SndLimTimeSender: 145230
DataBytesOut: 188890628
SndLimTransSender: 1
PktsOut: 2888
CongestionSignals: 0
RcvWinScale: 8
X_Rcvbuf: 262190
X_Sndbuf: 1326540
-~~~Web100_old_var_names~~~-: 1
c2sData: 6
c2sAck: 6
s2cData: 6
s2cAck: 6
half_duplex: 0
link: 100
congestion: 0
bad_cable: 0
mismatch: 0
spd: 145.01
bw: 14065390.62
loss: 0.000000000
avgrtt: 3.55
waitsec: 0.00
timesec: 10.00
order: 0.0000
rwintime: 0.9810
sendtime: 0.0190
cwndtime: 0.0000
rwin: 1.7422
swin: 10.1207
cwin: 4.9948
rttsec: 0.003551
Sndbuf: 1326540
aspd: 0.00000
CWND-Limited: 0.00
minCWNDpeak: -1
maxCWNDpeak: -1
CWNDpeaks: -1
c2sData: 6
c2sAck: 6
s2cData: 6
s2cAck: 6
half_duplex: 0
link: 100
congestion: 0
bad_cable: 0
mismatch: 0
spd: 127.83
bw: 12317274.32
loss: 0.000000000
avgrtt: 4.06
waitsec: 0.00
timesec: 10.00
order: 0.0000
rwintime: 0.9883
sendtime: 0.0117
cwndtime: 0.0000
rwin: 1.0000
swin: 10.1207
cwin: 4.9948
rttsec: 0.004055
Sndbuf: 1326540
aspd: 0.00000
CWND-Limited: 0.00
minCWNDpeak: -1
maxCWNDpeak: -1
CWNDpeaks: -1
c2sData: 6
c2sAck: 6
s2cData: 5
s2cAck: 5
half_duplex: 0
link: 100
congestion: 0
bad_cable: 0
mismatch: 0
spd: 107.96
bw: 10407524.63
loss: 0.000000000
avgrtt: 4.80
waitsec: 0.00
timesec: 10.00
order: 0.0000
rwintime: 0.9890
sendtime: 0.0110
cwndtime: 0.0000
rwin: 1.2656
swin: 10.1207
cwin: 4.9948
rttsec: 0.004799
Sndbuf: 1326540
aspd: 0.00000
CWND-Limited: 0.00
minCWNDpeak: -1
maxCWNDpeak: -1
CWNDpeaks: -1
c2sData: 6
c2sAck: 6
s2cData: 6
s2cAck: 6
half_duplex: 0
link: 100
congestion: 0
bad_cable: 0
mismatch: 0
spd: 126.62
bw: 12212644.63
loss: 0.000000000
avgrtt: 4.09
waitsec: 0.00
timesec: 10.00
order: 0.0000
rwintime: 0.9860
sendtime: 0.0140
cwndtime: 0.0000
rwin: 1.9336
swin: 10.1207
cwin: 4.9948
rttsec: 0.004090
Sndbuf: 1326540
aspd: 0.00000
CWND-Limited: 0.00
minCWNDpeak: -1
maxCWNDpeak: -1
CWNDpeaks: -1
c2sData: 6
c2sAck: 6
s2cData: 6
s2cAck: 6
half_duplex: 0
link: 100
congestion: 0
bad_cable: 0
mismatch: 0
spd: 131.46
bw: 12631532.77
loss: 0.000000000
avgrtt: 3.95
waitsec: 0.00
timesec: 10.00
order: 0.0000
rwintime: 0.9898
sendtime: 0.0102
cwndtime: 0.0000
rwin: 1.9336
swin: 10.1207
cwin: 4.9948
rttsec: 0.003954
Sndbuf: 1326540
aspd: 0.00000
CWND-Limited: 0.00
minCWNDpeak: -1
maxCWNDpeak: -1
CWNDpeaks: -1
c2sData: 6
c2sAck: 6
s2cData: 6
s2cAck: 6
half_duplex: 0
link: 100
congestion: 0
bad_cable: 0
mismatch: 0
spd: 149.14
bw: 14396575.85
loss: 0.000000000
avgrtt: 3.47
waitsec: 0.00
timesec: 10.00
order: 0.0000
rwintime: 0.9857
sendtime: 0.0143
cwndtime: 0.0000
rwin: 1.7422
swin: 10.1207
cwin: 4.9948
rttsec: 0.003469
Sndbuf: 1326540
aspd: 0.00000
CWND-Limited: 0.00
minCWNDpeak: -1
maxCWNDpeak: -1
CWNDpeaks: -1
Apr 28 08:46:10  localhost port 49379
Signal 10 received by process 8514
127.0.0.1:41922 --> 127.0.0.1:3002  link=System Fault; packets=83756
Running Average = 850.06 Mbps  Average speed = 571.90 Mbps
	T1=0 (0.00%); Ethernet=0 (0.00%); T3=20 (0.02%); FastEthernet=114 (0.14%);
OC-12=57290 (68.40%); 	Gigabit Ethernet=16876 (20.15%); OC-48=9454 (11.29%); 10 Gigabit Enet=0 (0.00%);
	Retransmissions=0 (0.00%); Unknown=1 (0.00%);
127.0.0.1:3002 --> 127.0.0.1:41922  link=System Fault; packets=41876
Running Average = 856.38 Mbps  Average speed = 568.82 Mbps
	T1=1 (0.00%); Ethernet=0 (0.00%); T3=7 (0.02%); FastEthernet=41 (0.10%);
OC-12=28753 (68.66%); 	Gigabit Ethernet=8354 (19.95%); OC-48=4720 (11.27%); 10 Gigabit Enet=0 (0.00%);
	Retransmissions=0 (0.00%); Unknown=0 (0.00%);
Signal 17 received by process 8513
Signal 17 received by process 8513
Signal 12 received by process 8522
127.0.0.1:3003 --> 127.0.0.1:52371  link=System Fault; packets=2718
Running Average = 190.46 Mbps  Average speed = 190.72 Mbps
	T1=0 (0.00%); Ethernet=0 (0.00%); T3=0 (0.00%); FastEthernet=412 (15.16%);
OC-12=2294 (84.40%); 	Gigabit Ethernet=0 (0.00%); OC-48=3 (0.11%); 10 Gigabit Enet=0 (0.00%);
	Retransmissions=0 (0.00%); Unknown=8 (0.29%);
127.0.0.1:52371 --> 127.0.0.1:3003  link=System Fault; packets=2710
Running Average = 190.71 Mbps  Average speed = 171.82 Mbps
	T1=1 (0.04%); Ethernet=0 (0.00%); T3=0 (0.00%); FastEthernet=412 (15.20%);
OC-12=2294 (84.65%); 	Gigabit Ethernet=0 (0.00%); OC-48=2 (0.07%); 10 Gigabit Enet=1 (0.04%);
	Retransmissions=0 (0.00%); Unknown=0 (0.00%);
Signal 17 received by process 8513
Apr 28 06:46:10,localhost,0,0,481495,0,9992,2880,0,0,2888,0,65468,0,2879,228352,1326540,654680,9986748,0,145230,188890628,1,0,1,1178424,204,129024,100,0,0,0,0,6,6,6,6,0,2888,0,8,3,0,0,8,0,0,0,0,0,0,188732744,-1,-1,-1
Signal 17 received by process 8009

Archive powered by MHonArc 2.6.16.

Top of Page