Jump to content

Why: Up & Down Questions


Recommended Posts

I don't know why but testmy Central USA is horridly slow for me. My results. Any suggestion are welcome.

Central USA: 1mbps

East USA: 5mbps

West USA >10mbps

Ok my upload tests are consistent at 500kbps out of my advertised 1mbps. On every upload test, it starts, 1-2 seconds of no transfer, followed by stable speeds. So I would expect +80% efficiency. But I no its 50% of my capacity over and over. Only once in 7 months have I exceeded 60% of advertised upload on testmy.net yet youtube, steam, and email uploads all hit 1mbps.

A 5.8 MB upload took 92 seconds. For more then 85 of those seconds task manager said transfer rate was around 1mbps. Yet my upload result was 519kbps. How in the world can task manager report 1mb/s for over 85 seconds yet testmy reports 519kbps average for 92 seconds. I don't flipping get it! :txt-please: help mez :huh:

Images are of a 2 second pause captured by task manager followed by stable 1mb/s.

And 1 second pause captured by netlimiter followed by stable 120kByte/sec.



Link to post
Share on other sites

:::.. Upload Test Results ..:::

Upload Connection:: 521 Kbps or 0.5 Mbps

Upload Test Size:: 5.8 MB or 5983 kB or 6126840 bytes

Upload Speed:: 65 kB/s

Tested At:: http://TestMy.net version:12

Validation Link:: https://testmy.net/db/s2uf1Px

Test Time:: 2012-08-01 09:53:10 Local Time

1MB Upload in 15.75 Seconds - 1GB Upload in ~4 Hours - 9X faster than 56K

This test of exactly 5983 kB took 91.951 seconds to complete

Running at 52% of hosts average (Road Runner)

But netlimiter reports that i transfered not 5.8MB but 10.2MB in the 92 second test! How can this be? I tested twice and both times the 5.8MB test transfered around 10MB.

Link to post
Share on other sites

  • 2 weeks later...

But netlimiter reports that i transfered not 5.8MB but 10.2MB in the 92 second test! How can this be? I tested twice and both times the 5.8MB test transfered around 10MB.

There is protocol overhead, check this out...

Gross bit rate

In digital communication systems, the physical layer gross bitrate,[2] raw bitrate,[3] data signaling rate,[4] gross data transfer rate[5] or uncoded transmission rate[3] (sometimes written as a variable Rb[2][3] or fb[6]) is the total number of physically transferred bits per second over a communication link, including useful data as well as protocol overhead.

In case of serial communications, the gross bit rate is related to the bit transmission time 3bed6d6ba303f7b673ae0c1e7021cb49.png as: 76951189284f616e59c4c258f153bd8c.png

The gross bit rate is related to, but should not be confused with, the symbol rate or modulation rate in baud, symbols/s or pulses/s. Gross bit rate can be used interchangeably with "baud" only when there are two levels per symbol, representing 0 and 1 respectively, meaning that each symbol of a data transmission system carries exactly one bit of data; something not true for modern modem modulation systems and modern LANs

Information rate

The physical layer net bitrate,[7]information rate,[2]useful bit rate,[8]payload rate,[9]net data transfer rate,[5]coded transmission rate,[3]effective data rate[3] or wire speed (informal language) of a digital communication channel is the capacity excluding the physical layer protocol overhead, for example time division multiplex (TDM) framing bits, redundant forward error correction (FEC) codes, equalizer training symbols and other channel coding. Error-correcting codes are common especially in wireless communication systems, broadband modem standards and modern copper-based high-speed LANs. The physical layer net bitrate is the datarate measured at a reference point in the interface between the datalink layer and physical layer, and may consequently include data link and higher layer overhead.


For technical reasons (hardware/software protocols, overheads, encoding schemes, etc.) the actual bitrates used by some of the compared-to devices may be significantly higher than what is listed above.

Source: http://en.wikipedia.org/wiki/Bit_rate

Search that WikipediA page for "overhead" and it will help you understand why your program reports differently - Many years ago (before 2004) I used to show an additional stat on the results page that I called "truspeed" which calculated an estimated overhead. With the advent of many additional types of connections over the years that calculation became just a guess... a shot in the dark, because I have no way of really knowing the true overhead. And it's different for different connection types and situations. So it was removed, I like reporting statistics... not guesses.

... So, I take it that this pause in your tests is a new phenomenon that you're just recently experiencing... right?

TestMy.net is starting a timer an instant before your computer is told to upload or download the data then stopping the timer exactly the moment after the last bit is sent or received. There is nothing between that timer other than the test data. Netlimiter and other programs have no way of being as precise as the TestMy.net program itself... don't read too deeply into comparison between your results shown here and local programs you're running to calculate your transfer rate... they can't be compared accurately. Although, the information from Netlimiter can be used to help you visualize an issue such as that pause. By the way, in the near future I hope to have a graph during the test to help visualize that information better within TestMy.net... I have allot of other features on my plate that I'm working on but that's one that I'm excited to get finished... sorry, no ETA.

Link to post
Share on other sites

I see that you started getting bad results from the default server after June 9th. Your route to that server mutual have some congestion along the path. If that's the case there is little that you can do... it's most likely a problem with Comcast. That server is located in one of the most popular hosting locations so if you see bad results to that server... your speed is degraded to ALLOT of other websites as well.

My provider is directly peered with Comcast but over the past couple of months I've had allot of Comcast users report this. Hopefully Comcast is aware of this and working to resolve the issue. Sometimes a major route will be compromised for whatever reason and this forces the provider to route more traffic than they should through a different route. The result is like trying to push the amount of water a firehouse uses through a garden hose... or a straw. There just isn't enough bandwidth available to make it happen in a timely mannor.

After looking at your results and taking into account other Comcast users who've complained recently... I'd bet that it's a routing issue. These issues usually resolve on their own... complaining to your provider is usually a waste of time. They most likely already know about it... it just takes time for them to open up more bandwidth.

Also, sometimes it can be that there is a DDoS attack that is being carried out over that route... slowing down everything along that route in the process.

Link to post
Share on other sites

Yes the data being sent is essentially wrapped in a package which has the recipients address and the "cardboard" package has weight in addition to the weight of the contents, But I was really expecting something like 10% overhead 90% data and not 40% overhead with 60% data.

Between March and June 2012 my ISP changed from "RR" to "Roadrunner" and somewhere around that time I noticed the pause at the beginning of every upload test.

You are correct that net-limiter is just a ballpark figure. When using it I saw something I could not explain.

5.8 MB upload transferred 10.2 MB

30 MB download transferred 25MB

Thanks for your input guys.

Link to post
Share on other sites


  • Create New...