OT SpeedTest

[OldGuy]

Other than going to SpeedTest.com is there a way to do a speed test
locally on the PC.
i.e. go to some server from an app on the pc and get a speed reading?

Having big internet access problems here. The ISP is Verizon.

 

[OldGuy]

OldGuy has brought this to us :

Other than going to SpeedTest.com is there a way to do a speed test locally
on the PC.
i.e. go to some server from an app on the pc and get a speed reading?

Having big internet access problems here. The ISP is Verizon.

Getting .33 MBPS download speed at SpeedTest.Net.
Line is supposed to be 3 MBps so 10x slow.

 

[OldGuy]

It happens that Bill in Co formulated :

Is that supposed to be 3 Mbps (3 megabits per sec)? If so, that would
translate into 3/8 MBps or 0.375 (megaBytes per sec) which is close to that
other figure.

Well translate some other way.
When I got 1.5Mbps day before yesterday download speed.
Yesterday was .4Mbps

 

[RobertMacy]

Is that supposed to be 3 Mbps (3 megabits per sec)? If so, that would
translate into 3/8 MBps or 0.375 (megaBytes per sec) which is close to
that
other figure.

usually there's at least a start bit, stop bit so that's 10 bits per 8 bit
character. which divides out perfectly.

 

[Paul]

OK, I'm still a bit confused. So do we assume 8 bits per byte for the
Internet data access here, or 10 bits per byte as Robert mentioned (when we
try to convert between the kbps (bits per sec) and kBps (bytes per sec)
service speeds)?

http://en.wikipedia.org/wiki/Asymmetric_digital_subscriber_line

"The total maximum capacity derived from summing the bits-per-bin is
reported by DSL modems and is sometimes termed sync rate.

This will always be rather misleading, as the true maximum link capacity
for user data transfer rate will be significantly lower; because extra
data are transmitted that are termed *protocol overhead*, reduced figures
for PPPoA connections of around 84-87 percent, at most, being common.
"

Other encapsulation methods are possible, with different overhead numbers.

http://en.wikipedia.org/wiki/Point-to-point_protocol_over_Ethernet#Protocol_overhead

The encapsulation methods used are more for telco convenience,
than efficiency. They could probably have found more efficient
ways of packaging the data than the ones we have today.

*******

It's my guess that's where the loss comes from, rather than
from byte delineation.

You can find ATM cells, using header CRC errors for delineation.
If the CRC checker gives a "good" pulse at the same place
every time, every 8*53 bit times, then you know you've found
the ATM cells (which are used for PPPOA). The state machine in
figure one, says seeing six pulses in the same place every
time, is sufficient to declare SYNC.

http://www.cecs.uci.edu/~papers/ipdps06/pdfs/57-RAW-paper-1.pdf

The HEC is CRC over the header bytes. It checks for header
byte corruption, but also allows a synchronizer to be
constructed.

http://en.wikipedia.org/wiki/Asynchronous_transfer_mode

So that's an example of a delineator that has no overhead
at all. Considering that the HEC is needed anyway, to help
ensure the cell goes to the right destination VPI:VCI.
(On my ADSL modem, VPI:VCI is set to 0:35 for example. I
presume all the cells sent to me have that value in the header,
and any other values would be rejected.)

Paul

 

[RobertMacy]

OK, I'm still a bit confused. So do we assume 8 bits per byte for the
Internet data access here, or 10 bits per byte as Robert mentioned (when
we
try to convert between the kbps (bits per sec) and kBps (bytes per sec)
service speeds)?

As you've noticed, when somebody sells, they'll give you the largest
number possible.

Shouldn't the 'test program' take into account everything and tell you the
'real' transfer rate? Personally don't know your exact transfer protocol.
But, you must keep in mind that ANY protocol probably puts in some amount
of overhead. In other words, you will always be transferring more bits
than you use. How many? I'll defer to the experts. I'm on dial-up so my
transfer rates are really, really slow and luckily only have START-STOP
bit, no check sum bit, which would have made that 11 bits of overhaed per
8 bit byte. From memory some of the esoteric protocols run long strings,
but have a lot of framing, so they're more efficient than 10 to get 8, but
not that much more efficient. And if you study it there are tradeoffs
between little 'likelihood' of an error and getting away with sending very
long strings. and something like for every double length of DATA, requires
half as many bytes of overhead, etc. Bu haven't studied that stuff in a
LONG time.

IMO, For you, you'd have to find the EXACT protocol you're using and do
some asking with those details. But no matter what protocol you are using
the rate is somewhere between exact [very unlikely] and 10 bits for every
8 useable bits.

 

[Paul]

Shouldn't the 'test program' take into account everything and tell you
the 'real' transfer rate?

The ADSL data stream is encapsulated. There
are two possibilities.

1) ADSL modem connected directly to computer.
ADSL modem/router set to "bridged mode", then connected to computer.
This achieves the same result, so these are grouped together.

2) ADSL modem connected to router, then router to computer.
ADSL modem/router set to "normal mode", with router functional.

In (1), the PPPOE is disassembled by a part of the Windows network stack.
If you were counting bytes here, you'd see all of them.

In (2), which is the normal setup for a home user with ADSL
connection and multiple computers to be fed by the one connection,
the encapsulation bytes are removed at the router. A byte count
from the router would be complete. A byte count done at the
computer, would be without the encapsulation bytes, as they've
already been removed in the router.

And at least some tests you do on a computer, like a download byte
rate test, further removes the TCP/IP header bytes, and just
considers the payload.

So lots of stuff gets thrown out of the math, before the user
gets to count the bytes.

The modem/router could help here, but seldom has
a decent GUI for this sort of thing. Just the lack of
a DMT performance page on the ADSL modem/router, shows
how little they care about such things. If we had one
of those, we could take a screenshot and send it to the
ISP when there is trouble. As it is, we have to use
a tool like this.

http://dmt.mhilfe.de/

For my modem/router, that tool only works with an older
version of firmware. The newer version, the statistics
interface was removed. I guess it was too useful. And
you may also have trouble with that tool, as it might
only work in one of the "bridged" versus "normal" modes.
Probably the "normal" mode is the one to use. The tool
telnets into the external box and collects the stats.
If you look on one of the popular sites, you might find
examples of the usage of that tool, with your
particular brand of ADSL modem.

Paul

 

[J. P. Gilliver (John)]

Is that supposed to be 3 Mbps (3 megabits per sec)? If so, that would
translate into 3/8 MBps or 0.375 (megaBytes per sec) which is close to that
other figure.

(You beat me to that one, Bill.) For local facilities, the networking
tab in task manager will show what speed data is passing through at (as
a percentage of the theoretical maximum of whatever channel you're using
- perhaps 100 MB for ethernet and perhaps 54 MB for wifi). There are
plenty of third-part app.s as well - I use BitMeter, because I like the
audio - I can hear when something's doing a download I wasn't expecting
(you can set it to make a little bip every 100K, 1M, etc.).2