Why the discrepancy between Speedtest and Wget?
My customer complains about low internet speeds. When measured with Speedtest.net speeds are acceptable. Periodic measured downloads are 10% to 30% of the nominal speed. I cannot explain that.
Some background. The problematic connection is on one of those sunny Caribbean islands where fast internet is not the greatest asset. Lately internet speeds became decent, up to 200 Mbps. But ping round trip to (say) Amsterdam is about 180 ms.
The customer has a 100 Mbps fiber connection. When carrying out a speedtest on a Windows machine (speedtest.net) to the ISP CO we obtain 95 Mbps. When using the same speed test to Amsterdam we reach 60-70 Mbs. Fully acceptable.
Some time ago I installed a RasPi which periodically wgets a file from one of my servers in Amsterdam. In a datacenter, which is directly connected to AMS-IX. Using this command:
wget -O /dev/null --report-speed=bits http://aserv.example.net/~myuser/links/M77232917.txt
The .txt file is 23MByte of numbers. (Actually it is the one but largest Mersenne Prime, 23e6 digits)
When I download that file on the problematic network, wget reports this:
dev/null 100%[====================================================================>] 22.81M 11.6Mb/s in 17s
2019-02-08 14:27:55 (11.2 Mb/s) - ‘/dev/null’ saved [23923322/23923322]
That is at the same time speedtest.net reports 60-70 Mbps.
I know that the Raspi has its limitations. But this speed varies wildly. One time the RasPi report this 11 Mbps, the next time 22 Mbps. But sometimes as low as 1.5 Mbps.
When I do this test with a really powerful laptop, top speeds are somewhat higher (up to 30 Mbps), but also show the same lows. So it indicates a RasPi limitation on the high side, but not the 10 Mbps on the low side.
I issued exactly the same command from a server in München, Germany in a datacenter. Speed 96 Mbps.
Then from a consumer 100 Mbps fiber connection in the Netherlands: 65 Mbps.
Then, at my home which has nominal 10 Mbps ADSL. Speedtest shows 10Mbps. Wget gives 8.5 Mbps. Which is equal in my book.
This precludes any limitation on the server which acts as host for the file download.
I do not expect that anyone can point out the cause of the slowness of the connection at the customer premises. But can anyone explain the discrepancy between the speedtest.net and the wget?
Is there something the speedtest ignores, or does it measure only the peaks? Or is wget seriously influenced by long ping times?
I feel that the wget test gives the real, effective speed, while speedtest is mainly to show the advertised speed.
internet performance-monitoring wget network-speed
|
show 2 more comments
My customer complains about low internet speeds. When measured with Speedtest.net speeds are acceptable. Periodic measured downloads are 10% to 30% of the nominal speed. I cannot explain that.
Some background. The problematic connection is on one of those sunny Caribbean islands where fast internet is not the greatest asset. Lately internet speeds became decent, up to 200 Mbps. But ping round trip to (say) Amsterdam is about 180 ms.
The customer has a 100 Mbps fiber connection. When carrying out a speedtest on a Windows machine (speedtest.net) to the ISP CO we obtain 95 Mbps. When using the same speed test to Amsterdam we reach 60-70 Mbs. Fully acceptable.
Some time ago I installed a RasPi which periodically wgets a file from one of my servers in Amsterdam. In a datacenter, which is directly connected to AMS-IX. Using this command:
wget -O /dev/null --report-speed=bits http://aserv.example.net/~myuser/links/M77232917.txt
The .txt file is 23MByte of numbers. (Actually it is the one but largest Mersenne Prime, 23e6 digits)
When I download that file on the problematic network, wget reports this:
dev/null 100%[====================================================================>] 22.81M 11.6Mb/s in 17s
2019-02-08 14:27:55 (11.2 Mb/s) - ‘/dev/null’ saved [23923322/23923322]
That is at the same time speedtest.net reports 60-70 Mbps.
I know that the Raspi has its limitations. But this speed varies wildly. One time the RasPi report this 11 Mbps, the next time 22 Mbps. But sometimes as low as 1.5 Mbps.
When I do this test with a really powerful laptop, top speeds are somewhat higher (up to 30 Mbps), but also show the same lows. So it indicates a RasPi limitation on the high side, but not the 10 Mbps on the low side.
I issued exactly the same command from a server in München, Germany in a datacenter. Speed 96 Mbps.
Then from a consumer 100 Mbps fiber connection in the Netherlands: 65 Mbps.
Then, at my home which has nominal 10 Mbps ADSL. Speedtest shows 10Mbps. Wget gives 8.5 Mbps. Which is equal in my book.
This precludes any limitation on the server which acts as host for the file download.
I do not expect that anyone can point out the cause of the slowness of the connection at the customer premises. But can anyone explain the discrepancy between the speedtest.net and the wget?
Is there something the speedtest ignores, or does it measure only the peaks? Or is wget seriously influenced by long ping times?
I feel that the wget test gives the real, effective speed, while speedtest is mainly to show the advertised speed.
internet performance-monitoring wget network-speed
Another way to check speed is to dossh personal-server cat /dev/zero | pv > /dev/null
, on a personal server that you know is not rate limited to be slower than the speed you're expecting.
– JoL
Feb 8 at 20:23
I skimmed your question. And it sounds like you have a large bandwidth and maybe significant round trip delay scenario also known as a "long fat network". I've experienced this sort of thing personally and solved it by opening up many connections (I used rsync). Can you try opening many wget instances (try 5, 10, 20)? Wikipedia page is: bandwidth delay product.
– Trevor Boyd Smith
Feb 9 at 13:05
Wget reports in bytes by default: [james@lamia root]$ wget -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 112MB/s in 0.9s [james@lamia root]$ wget --report-speed=bits -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 932Mb/s in 0.9s
– james
Feb 9 at 14:46
Consider running an iperf server for tcp and a second for udp on your DC-hosted machine. Then as part of the cron job call a test from your client and see how the speeds compare with the http get.
– Criggie
Feb 10 at 1:03
What kind of file is it anyway? Is it compressible and the server supports http compression? While you cannot fix bandwidth issues you might be able to make the file smaller.
– Salman A
Feb 10 at 12:11
|
show 2 more comments
My customer complains about low internet speeds. When measured with Speedtest.net speeds are acceptable. Periodic measured downloads are 10% to 30% of the nominal speed. I cannot explain that.
Some background. The problematic connection is on one of those sunny Caribbean islands where fast internet is not the greatest asset. Lately internet speeds became decent, up to 200 Mbps. But ping round trip to (say) Amsterdam is about 180 ms.
The customer has a 100 Mbps fiber connection. When carrying out a speedtest on a Windows machine (speedtest.net) to the ISP CO we obtain 95 Mbps. When using the same speed test to Amsterdam we reach 60-70 Mbs. Fully acceptable.
Some time ago I installed a RasPi which periodically wgets a file from one of my servers in Amsterdam. In a datacenter, which is directly connected to AMS-IX. Using this command:
wget -O /dev/null --report-speed=bits http://aserv.example.net/~myuser/links/M77232917.txt
The .txt file is 23MByte of numbers. (Actually it is the one but largest Mersenne Prime, 23e6 digits)
When I download that file on the problematic network, wget reports this:
dev/null 100%[====================================================================>] 22.81M 11.6Mb/s in 17s
2019-02-08 14:27:55 (11.2 Mb/s) - ‘/dev/null’ saved [23923322/23923322]
That is at the same time speedtest.net reports 60-70 Mbps.
I know that the Raspi has its limitations. But this speed varies wildly. One time the RasPi report this 11 Mbps, the next time 22 Mbps. But sometimes as low as 1.5 Mbps.
When I do this test with a really powerful laptop, top speeds are somewhat higher (up to 30 Mbps), but also show the same lows. So it indicates a RasPi limitation on the high side, but not the 10 Mbps on the low side.
I issued exactly the same command from a server in München, Germany in a datacenter. Speed 96 Mbps.
Then from a consumer 100 Mbps fiber connection in the Netherlands: 65 Mbps.
Then, at my home which has nominal 10 Mbps ADSL. Speedtest shows 10Mbps. Wget gives 8.5 Mbps. Which is equal in my book.
This precludes any limitation on the server which acts as host for the file download.
I do not expect that anyone can point out the cause of the slowness of the connection at the customer premises. But can anyone explain the discrepancy between the speedtest.net and the wget?
Is there something the speedtest ignores, or does it measure only the peaks? Or is wget seriously influenced by long ping times?
I feel that the wget test gives the real, effective speed, while speedtest is mainly to show the advertised speed.
internet performance-monitoring wget network-speed
My customer complains about low internet speeds. When measured with Speedtest.net speeds are acceptable. Periodic measured downloads are 10% to 30% of the nominal speed. I cannot explain that.
Some background. The problematic connection is on one of those sunny Caribbean islands where fast internet is not the greatest asset. Lately internet speeds became decent, up to 200 Mbps. But ping round trip to (say) Amsterdam is about 180 ms.
The customer has a 100 Mbps fiber connection. When carrying out a speedtest on a Windows machine (speedtest.net) to the ISP CO we obtain 95 Mbps. When using the same speed test to Amsterdam we reach 60-70 Mbs. Fully acceptable.
Some time ago I installed a RasPi which periodically wgets a file from one of my servers in Amsterdam. In a datacenter, which is directly connected to AMS-IX. Using this command:
wget -O /dev/null --report-speed=bits http://aserv.example.net/~myuser/links/M77232917.txt
The .txt file is 23MByte of numbers. (Actually it is the one but largest Mersenne Prime, 23e6 digits)
When I download that file on the problematic network, wget reports this:
dev/null 100%[====================================================================>] 22.81M 11.6Mb/s in 17s
2019-02-08 14:27:55 (11.2 Mb/s) - ‘/dev/null’ saved [23923322/23923322]
That is at the same time speedtest.net reports 60-70 Mbps.
I know that the Raspi has its limitations. But this speed varies wildly. One time the RasPi report this 11 Mbps, the next time 22 Mbps. But sometimes as low as 1.5 Mbps.
When I do this test with a really powerful laptop, top speeds are somewhat higher (up to 30 Mbps), but also show the same lows. So it indicates a RasPi limitation on the high side, but not the 10 Mbps on the low side.
I issued exactly the same command from a server in München, Germany in a datacenter. Speed 96 Mbps.
Then from a consumer 100 Mbps fiber connection in the Netherlands: 65 Mbps.
Then, at my home which has nominal 10 Mbps ADSL. Speedtest shows 10Mbps. Wget gives 8.5 Mbps. Which is equal in my book.
This precludes any limitation on the server which acts as host for the file download.
I do not expect that anyone can point out the cause of the slowness of the connection at the customer premises. But can anyone explain the discrepancy between the speedtest.net and the wget?
Is there something the speedtest ignores, or does it measure only the peaks? Or is wget seriously influenced by long ping times?
I feel that the wget test gives the real, effective speed, while speedtest is mainly to show the advertised speed.
internet performance-monitoring wget network-speed
internet performance-monitoring wget network-speed
edited Feb 8 at 14:54
Hans Linkels
asked Feb 8 at 14:41
Hans LinkelsHans Linkels
18816
18816
Another way to check speed is to dossh personal-server cat /dev/zero | pv > /dev/null
, on a personal server that you know is not rate limited to be slower than the speed you're expecting.
– JoL
Feb 8 at 20:23
I skimmed your question. And it sounds like you have a large bandwidth and maybe significant round trip delay scenario also known as a "long fat network". I've experienced this sort of thing personally and solved it by opening up many connections (I used rsync). Can you try opening many wget instances (try 5, 10, 20)? Wikipedia page is: bandwidth delay product.
– Trevor Boyd Smith
Feb 9 at 13:05
Wget reports in bytes by default: [james@lamia root]$ wget -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 112MB/s in 0.9s [james@lamia root]$ wget --report-speed=bits -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 932Mb/s in 0.9s
– james
Feb 9 at 14:46
Consider running an iperf server for tcp and a second for udp on your DC-hosted machine. Then as part of the cron job call a test from your client and see how the speeds compare with the http get.
– Criggie
Feb 10 at 1:03
What kind of file is it anyway? Is it compressible and the server supports http compression? While you cannot fix bandwidth issues you might be able to make the file smaller.
– Salman A
Feb 10 at 12:11
|
show 2 more comments
Another way to check speed is to dossh personal-server cat /dev/zero | pv > /dev/null
, on a personal server that you know is not rate limited to be slower than the speed you're expecting.
– JoL
Feb 8 at 20:23
I skimmed your question. And it sounds like you have a large bandwidth and maybe significant round trip delay scenario also known as a "long fat network". I've experienced this sort of thing personally and solved it by opening up many connections (I used rsync). Can you try opening many wget instances (try 5, 10, 20)? Wikipedia page is: bandwidth delay product.
– Trevor Boyd Smith
Feb 9 at 13:05
Wget reports in bytes by default: [james@lamia root]$ wget -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 112MB/s in 0.9s [james@lamia root]$ wget --report-speed=bits -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 932Mb/s in 0.9s
– james
Feb 9 at 14:46
Consider running an iperf server for tcp and a second for udp on your DC-hosted machine. Then as part of the cron job call a test from your client and see how the speeds compare with the http get.
– Criggie
Feb 10 at 1:03
What kind of file is it anyway? Is it compressible and the server supports http compression? While you cannot fix bandwidth issues you might be able to make the file smaller.
– Salman A
Feb 10 at 12:11
Another way to check speed is to do
ssh personal-server cat /dev/zero | pv > /dev/null
, on a personal server that you know is not rate limited to be slower than the speed you're expecting.– JoL
Feb 8 at 20:23
Another way to check speed is to do
ssh personal-server cat /dev/zero | pv > /dev/null
, on a personal server that you know is not rate limited to be slower than the speed you're expecting.– JoL
Feb 8 at 20:23
I skimmed your question. And it sounds like you have a large bandwidth and maybe significant round trip delay scenario also known as a "long fat network". I've experienced this sort of thing personally and solved it by opening up many connections (I used rsync). Can you try opening many wget instances (try 5, 10, 20)? Wikipedia page is: bandwidth delay product.
– Trevor Boyd Smith
Feb 9 at 13:05
I skimmed your question. And it sounds like you have a large bandwidth and maybe significant round trip delay scenario also known as a "long fat network". I've experienced this sort of thing personally and solved it by opening up many connections (I used rsync). Can you try opening many wget instances (try 5, 10, 20)? Wikipedia page is: bandwidth delay product.
– Trevor Boyd Smith
Feb 9 at 13:05
Wget reports in bytes by default: [james@lamia root]$ wget -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 112MB/s in 0.9s [james@lamia root]$ wget --report-speed=bits -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 932Mb/s in 0.9s
– james
Feb 9 at 14:46
Wget reports in bytes by default: [james@lamia root]$ wget -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 112MB/s in 0.9s [james@lamia root]$ wget --report-speed=bits -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 932Mb/s in 0.9s
– james
Feb 9 at 14:46
Consider running an iperf server for tcp and a second for udp on your DC-hosted machine. Then as part of the cron job call a test from your client and see how the speeds compare with the http get.
– Criggie
Feb 10 at 1:03
Consider running an iperf server for tcp and a second for udp on your DC-hosted machine. Then as part of the cron job call a test from your client and see how the speeds compare with the http get.
– Criggie
Feb 10 at 1:03
What kind of file is it anyway? Is it compressible and the server supports http compression? While you cannot fix bandwidth issues you might be able to make the file smaller.
– Salman A
Feb 10 at 12:11
What kind of file is it anyway? Is it compressible and the server supports http compression? While you cannot fix bandwidth issues you might be able to make the file smaller.
– Salman A
Feb 10 at 12:11
|
show 2 more comments
6 Answers
6
active
oldest
votes
In addition to the other reasons posted, TCP connections don't work well with large files when the bandwidth-delay product becomes large.
Like on an otherwise fast connection to an island.
See Wikipedia's entry on TCP tuning.
So Speedtest can dump a small file through the connection at 95 mb/sec, but wget
can only get 10 mb/sec on a 20 MB file.
2
This is new knowledge for me. Very good. Indeed, the bandwidth-delay product is high (2.25 MB if I calculated correctly). A quick look showed a default buffer of 87kB and a maximum of 3.5 MB. (I assume Byte not bits). I have to dive more deeply into this to better assess it. If, in combination speedtest downloads a lot of small files and records the max speed on that, it explains a lot.
– Hans Linkels
Feb 8 at 15:38
add a comment |
ISPs often prioritize traffic to speedtest.net so that they can brag how fast their connections are, while in reality, they don't provide that much bandwidth. They're perfectly aware that most users will only check that site for confirmation.
You also have to keep in mind that transfer speed relies both on the client and the server. In today's world most servers throttle in one way or another.
Finally, it's pointless to expect stable bandwidth for overseas connections. There's just no such thing. It has to go through an infinite number of switches, fibers, datacenters to reach the final location. And all it takes is just one moving part to slow down.
I understand your statements, except for throttling on the server side. It is my own server, and when the client is in a different data center (about 1200km away) the speed is consistently 95 Mbps. Even if the client is on a 100 Mb consumer connection it is 65 Mbps.
– Hans Linkels
Feb 8 at 14:59
9
Can you document you claim ? "ISPs often prioritize traffic to speedtest.net"
– Soleil
Feb 8 at 15:03
1
@Soleil Didn't take too much Googling: myce.com/news/…
– MonkeyZeus
Feb 8 at 18:39
6
An ISP prioritizing speedtest traffic is as likely as a major car maker faking emissions tests.
– Barmar
Feb 9 at 6:50
3
Anecdotally, I was once able to 'fix' a stuttering Super Bowl stream by sending traffic to speedtest.net repeatedly from a Raspberry Pi. Seemed like they prioritized my whole connection as long as there was speedtest traffic present - night and day difference. It's not much evidence that ISPs do shady stuff, but it's something.
– Undo
Feb 9 at 21:58
|
show 6 more comments
wget
give good practical measure of the speed. The tests of Speedtest probably include kind of parallelism which can explain higher numbers.
For good average speed test I think the time for download should be at least 90-120 seconds (to get good average)
I am working on installing a more powerful logging computer and to increase the file size.
– Hans Linkels
Feb 8 at 15:00
Can you develop "kind of parallelism" ? I don't see any way/reason since there is a priori 1 connection.
– Soleil
Feb 8 at 15:04
1
@Soleil, IMHO they download few files, not only one. You can test it by run fewwget
and sum the speed
– Romeo Ninov
Feb 8 at 15:05
1
I could parallelize my measurement, but what is the benefit? I already demonstrated that other clients reach full speed. The difference is that the problematic connection has a 180 ms latency. The fast connections < 10 ms. Would parallel diminish latency effects? Just asking.
– Hans Linkels
Feb 8 at 15:08
1
@RomeoNinov I checked, there is no such parallelism (speedtest.net). One file per upload and one per download ([1-2]MB each).
– Soleil
Feb 8 at 15:11
|
show 3 more comments
One reason could be that often the maximum speed cannot be reached by just a single TCP connection.
Speedtest.net recently introduced a single connection mode. Try this and see if it makes a difference.
Then, for the download use for example aria2 with parameters to use multiple conections and compare.
e.g. aria2c -d /dev -o null --allow-overwrite=true --file-allocation=none --max-connection-per-server=8 --min-split-size=1M http://aserv.example.net/~myuser/links/M77232917.txt
add a comment |
Use https://fast.com/ , this is a Netflix based speed test meaning it cannot be differentiated by ISP's from Netflix itself.
This is a more accurate test than any other test generally. People won't be worried about how fast a webpage loads, but rather how quickly the videos buffer due to the increased bandwith necessary to display a video.
ISP's often boost speeds based on the domain someone is connecting to if it's a speed test or using port 8080. Whereas Netflix uses port 80, a slower port when it is being prioritized.
https://www.ispreview.co.uk/index.php/2016/01/ookla-accuses-uk-broadband-isp-manipulating-internet-speedtests.html
https://www.myce.com/review/internet-providers-caught-inflating-speed-test-results-78458/introduction-1/
1
"meaning it cannot be differentiated by ISP's from Netflix itself" - That is untrue, the ISP can definitely see both the DNS request and the SNI on the HTTPS connection.
– Kevin
Feb 9 at 9:29
@Kevin fast.com contacts netflix servers to download from, meaning it emulates videos from netflix itself. Although I will grant you ISPs may catch onto the fact that connecting to that specific site which subsequently contacts Netflix based servers requires prioritization similar to speedtest.net
– Jonathan
Feb 9 at 20:11
It's not exactly rocket science. All they have to do is unthrottle Netflix for a few minutes or hours after they see a fast.com connection. The upside, of course, is that you can go to fast.com to get yourself unthrottled, then close the tab and watch Netflix for real.
– Kevin
Feb 9 at 21:34
Personally I suspect it is computer science or at least related to it rather than rocket science. It seems some of the bigger ISPs (e.g. Bell) haven't caught onto fast.com over the past few years. Either way running a script on your computer that connects to fast.com in order to up your download speed every little while if the throttling is bad enough would be viable.
– Jonathan
Feb 10 at 1:32
add a comment |
Is it just me or did no one notice he said Mbps and the wget command list "MB/s".
60mbp/s and actually getting 11.2Mb's is normal.
Mbps and MB/s are two different speeds.
"a Megabit is 1/8 as big as a Megabyte, meaning that to download a 1 MB file in 1 second you would need a connection of 8 Mbps. " So 11mbx8=88mbps...11.2Mb is actually good for a connection reporting 60-70mbps.
Are people having memory lose awnering this. You'll never get 70mb/s with a speedtest speed of 70Mbps
The output ofwget
is Mb/s which translates to Megabits/s. MB/s would translate to MegaBytes/s. Just run your ownwget
command and verify the result.
– Thomas
Feb 9 at 11:33
@james: Yes by default, but in OP thewget
command includes--report-speed=bits
which results inMb/s
which isMbit/s
. Running without--report-speed=bits
givesMB/s
which translates toMByte/s
. Note theb
andB
.
– Thomas
Feb 9 at 16:30
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f952978%2fwhy-the-discrepancy-between-speedtest-and-wget%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
In addition to the other reasons posted, TCP connections don't work well with large files when the bandwidth-delay product becomes large.
Like on an otherwise fast connection to an island.
See Wikipedia's entry on TCP tuning.
So Speedtest can dump a small file through the connection at 95 mb/sec, but wget
can only get 10 mb/sec on a 20 MB file.
2
This is new knowledge for me. Very good. Indeed, the bandwidth-delay product is high (2.25 MB if I calculated correctly). A quick look showed a default buffer of 87kB and a maximum of 3.5 MB. (I assume Byte not bits). I have to dive more deeply into this to better assess it. If, in combination speedtest downloads a lot of small files and records the max speed on that, it explains a lot.
– Hans Linkels
Feb 8 at 15:38
add a comment |
In addition to the other reasons posted, TCP connections don't work well with large files when the bandwidth-delay product becomes large.
Like on an otherwise fast connection to an island.
See Wikipedia's entry on TCP tuning.
So Speedtest can dump a small file through the connection at 95 mb/sec, but wget
can only get 10 mb/sec on a 20 MB file.
2
This is new knowledge for me. Very good. Indeed, the bandwidth-delay product is high (2.25 MB if I calculated correctly). A quick look showed a default buffer of 87kB and a maximum of 3.5 MB. (I assume Byte not bits). I have to dive more deeply into this to better assess it. If, in combination speedtest downloads a lot of small files and records the max speed on that, it explains a lot.
– Hans Linkels
Feb 8 at 15:38
add a comment |
In addition to the other reasons posted, TCP connections don't work well with large files when the bandwidth-delay product becomes large.
Like on an otherwise fast connection to an island.
See Wikipedia's entry on TCP tuning.
So Speedtest can dump a small file through the connection at 95 mb/sec, but wget
can only get 10 mb/sec on a 20 MB file.
In addition to the other reasons posted, TCP connections don't work well with large files when the bandwidth-delay product becomes large.
Like on an otherwise fast connection to an island.
See Wikipedia's entry on TCP tuning.
So Speedtest can dump a small file through the connection at 95 mb/sec, but wget
can only get 10 mb/sec on a 20 MB file.
answered Feb 8 at 15:03
Andrew HenleAndrew Henle
990510
990510
2
This is new knowledge for me. Very good. Indeed, the bandwidth-delay product is high (2.25 MB if I calculated correctly). A quick look showed a default buffer of 87kB and a maximum of 3.5 MB. (I assume Byte not bits). I have to dive more deeply into this to better assess it. If, in combination speedtest downloads a lot of small files and records the max speed on that, it explains a lot.
– Hans Linkels
Feb 8 at 15:38
add a comment |
2
This is new knowledge for me. Very good. Indeed, the bandwidth-delay product is high (2.25 MB if I calculated correctly). A quick look showed a default buffer of 87kB and a maximum of 3.5 MB. (I assume Byte not bits). I have to dive more deeply into this to better assess it. If, in combination speedtest downloads a lot of small files and records the max speed on that, it explains a lot.
– Hans Linkels
Feb 8 at 15:38
2
2
This is new knowledge for me. Very good. Indeed, the bandwidth-delay product is high (2.25 MB if I calculated correctly). A quick look showed a default buffer of 87kB and a maximum of 3.5 MB. (I assume Byte not bits). I have to dive more deeply into this to better assess it. If, in combination speedtest downloads a lot of small files and records the max speed on that, it explains a lot.
– Hans Linkels
Feb 8 at 15:38
This is new knowledge for me. Very good. Indeed, the bandwidth-delay product is high (2.25 MB if I calculated correctly). A quick look showed a default buffer of 87kB and a maximum of 3.5 MB. (I assume Byte not bits). I have to dive more deeply into this to better assess it. If, in combination speedtest downloads a lot of small files and records the max speed on that, it explains a lot.
– Hans Linkels
Feb 8 at 15:38
add a comment |
ISPs often prioritize traffic to speedtest.net so that they can brag how fast their connections are, while in reality, they don't provide that much bandwidth. They're perfectly aware that most users will only check that site for confirmation.
You also have to keep in mind that transfer speed relies both on the client and the server. In today's world most servers throttle in one way or another.
Finally, it's pointless to expect stable bandwidth for overseas connections. There's just no such thing. It has to go through an infinite number of switches, fibers, datacenters to reach the final location. And all it takes is just one moving part to slow down.
I understand your statements, except for throttling on the server side. It is my own server, and when the client is in a different data center (about 1200km away) the speed is consistently 95 Mbps. Even if the client is on a 100 Mb consumer connection it is 65 Mbps.
– Hans Linkels
Feb 8 at 14:59
9
Can you document you claim ? "ISPs often prioritize traffic to speedtest.net"
– Soleil
Feb 8 at 15:03
1
@Soleil Didn't take too much Googling: myce.com/news/…
– MonkeyZeus
Feb 8 at 18:39
6
An ISP prioritizing speedtest traffic is as likely as a major car maker faking emissions tests.
– Barmar
Feb 9 at 6:50
3
Anecdotally, I was once able to 'fix' a stuttering Super Bowl stream by sending traffic to speedtest.net repeatedly from a Raspberry Pi. Seemed like they prioritized my whole connection as long as there was speedtest traffic present - night and day difference. It's not much evidence that ISPs do shady stuff, but it's something.
– Undo
Feb 9 at 21:58
|
show 6 more comments
ISPs often prioritize traffic to speedtest.net so that they can brag how fast their connections are, while in reality, they don't provide that much bandwidth. They're perfectly aware that most users will only check that site for confirmation.
You also have to keep in mind that transfer speed relies both on the client and the server. In today's world most servers throttle in one way or another.
Finally, it's pointless to expect stable bandwidth for overseas connections. There's just no such thing. It has to go through an infinite number of switches, fibers, datacenters to reach the final location. And all it takes is just one moving part to slow down.
I understand your statements, except for throttling on the server side. It is my own server, and when the client is in a different data center (about 1200km away) the speed is consistently 95 Mbps. Even if the client is on a 100 Mb consumer connection it is 65 Mbps.
– Hans Linkels
Feb 8 at 14:59
9
Can you document you claim ? "ISPs often prioritize traffic to speedtest.net"
– Soleil
Feb 8 at 15:03
1
@Soleil Didn't take too much Googling: myce.com/news/…
– MonkeyZeus
Feb 8 at 18:39
6
An ISP prioritizing speedtest traffic is as likely as a major car maker faking emissions tests.
– Barmar
Feb 9 at 6:50
3
Anecdotally, I was once able to 'fix' a stuttering Super Bowl stream by sending traffic to speedtest.net repeatedly from a Raspberry Pi. Seemed like they prioritized my whole connection as long as there was speedtest traffic present - night and day difference. It's not much evidence that ISPs do shady stuff, but it's something.
– Undo
Feb 9 at 21:58
|
show 6 more comments
ISPs often prioritize traffic to speedtest.net so that they can brag how fast their connections are, while in reality, they don't provide that much bandwidth. They're perfectly aware that most users will only check that site for confirmation.
You also have to keep in mind that transfer speed relies both on the client and the server. In today's world most servers throttle in one way or another.
Finally, it's pointless to expect stable bandwidth for overseas connections. There's just no such thing. It has to go through an infinite number of switches, fibers, datacenters to reach the final location. And all it takes is just one moving part to slow down.
ISPs often prioritize traffic to speedtest.net so that they can brag how fast their connections are, while in reality, they don't provide that much bandwidth. They're perfectly aware that most users will only check that site for confirmation.
You also have to keep in mind that transfer speed relies both on the client and the server. In today's world most servers throttle in one way or another.
Finally, it's pointless to expect stable bandwidth for overseas connections. There's just no such thing. It has to go through an infinite number of switches, fibers, datacenters to reach the final location. And all it takes is just one moving part to slow down.
answered Feb 8 at 14:56
bviktorbviktor
60859
60859
I understand your statements, except for throttling on the server side. It is my own server, and when the client is in a different data center (about 1200km away) the speed is consistently 95 Mbps. Even if the client is on a 100 Mb consumer connection it is 65 Mbps.
– Hans Linkels
Feb 8 at 14:59
9
Can you document you claim ? "ISPs often prioritize traffic to speedtest.net"
– Soleil
Feb 8 at 15:03
1
@Soleil Didn't take too much Googling: myce.com/news/…
– MonkeyZeus
Feb 8 at 18:39
6
An ISP prioritizing speedtest traffic is as likely as a major car maker faking emissions tests.
– Barmar
Feb 9 at 6:50
3
Anecdotally, I was once able to 'fix' a stuttering Super Bowl stream by sending traffic to speedtest.net repeatedly from a Raspberry Pi. Seemed like they prioritized my whole connection as long as there was speedtest traffic present - night and day difference. It's not much evidence that ISPs do shady stuff, but it's something.
– Undo
Feb 9 at 21:58
|
show 6 more comments
I understand your statements, except for throttling on the server side. It is my own server, and when the client is in a different data center (about 1200km away) the speed is consistently 95 Mbps. Even if the client is on a 100 Mb consumer connection it is 65 Mbps.
– Hans Linkels
Feb 8 at 14:59
9
Can you document you claim ? "ISPs often prioritize traffic to speedtest.net"
– Soleil
Feb 8 at 15:03
1
@Soleil Didn't take too much Googling: myce.com/news/…
– MonkeyZeus
Feb 8 at 18:39
6
An ISP prioritizing speedtest traffic is as likely as a major car maker faking emissions tests.
– Barmar
Feb 9 at 6:50
3
Anecdotally, I was once able to 'fix' a stuttering Super Bowl stream by sending traffic to speedtest.net repeatedly from a Raspberry Pi. Seemed like they prioritized my whole connection as long as there was speedtest traffic present - night and day difference. It's not much evidence that ISPs do shady stuff, but it's something.
– Undo
Feb 9 at 21:58
I understand your statements, except for throttling on the server side. It is my own server, and when the client is in a different data center (about 1200km away) the speed is consistently 95 Mbps. Even if the client is on a 100 Mb consumer connection it is 65 Mbps.
– Hans Linkels
Feb 8 at 14:59
I understand your statements, except for throttling on the server side. It is my own server, and when the client is in a different data center (about 1200km away) the speed is consistently 95 Mbps. Even if the client is on a 100 Mb consumer connection it is 65 Mbps.
– Hans Linkels
Feb 8 at 14:59
9
9
Can you document you claim ? "ISPs often prioritize traffic to speedtest.net"
– Soleil
Feb 8 at 15:03
Can you document you claim ? "ISPs often prioritize traffic to speedtest.net"
– Soleil
Feb 8 at 15:03
1
1
@Soleil Didn't take too much Googling: myce.com/news/…
– MonkeyZeus
Feb 8 at 18:39
@Soleil Didn't take too much Googling: myce.com/news/…
– MonkeyZeus
Feb 8 at 18:39
6
6
An ISP prioritizing speedtest traffic is as likely as a major car maker faking emissions tests.
– Barmar
Feb 9 at 6:50
An ISP prioritizing speedtest traffic is as likely as a major car maker faking emissions tests.
– Barmar
Feb 9 at 6:50
3
3
Anecdotally, I was once able to 'fix' a stuttering Super Bowl stream by sending traffic to speedtest.net repeatedly from a Raspberry Pi. Seemed like they prioritized my whole connection as long as there was speedtest traffic present - night and day difference. It's not much evidence that ISPs do shady stuff, but it's something.
– Undo
Feb 9 at 21:58
Anecdotally, I was once able to 'fix' a stuttering Super Bowl stream by sending traffic to speedtest.net repeatedly from a Raspberry Pi. Seemed like they prioritized my whole connection as long as there was speedtest traffic present - night and day difference. It's not much evidence that ISPs do shady stuff, but it's something.
– Undo
Feb 9 at 21:58
|
show 6 more comments
wget
give good practical measure of the speed. The tests of Speedtest probably include kind of parallelism which can explain higher numbers.
For good average speed test I think the time for download should be at least 90-120 seconds (to get good average)
I am working on installing a more powerful logging computer and to increase the file size.
– Hans Linkels
Feb 8 at 15:00
Can you develop "kind of parallelism" ? I don't see any way/reason since there is a priori 1 connection.
– Soleil
Feb 8 at 15:04
1
@Soleil, IMHO they download few files, not only one. You can test it by run fewwget
and sum the speed
– Romeo Ninov
Feb 8 at 15:05
1
I could parallelize my measurement, but what is the benefit? I already demonstrated that other clients reach full speed. The difference is that the problematic connection has a 180 ms latency. The fast connections < 10 ms. Would parallel diminish latency effects? Just asking.
– Hans Linkels
Feb 8 at 15:08
1
@RomeoNinov I checked, there is no such parallelism (speedtest.net). One file per upload and one per download ([1-2]MB each).
– Soleil
Feb 8 at 15:11
|
show 3 more comments
wget
give good practical measure of the speed. The tests of Speedtest probably include kind of parallelism which can explain higher numbers.
For good average speed test I think the time for download should be at least 90-120 seconds (to get good average)
I am working on installing a more powerful logging computer and to increase the file size.
– Hans Linkels
Feb 8 at 15:00
Can you develop "kind of parallelism" ? I don't see any way/reason since there is a priori 1 connection.
– Soleil
Feb 8 at 15:04
1
@Soleil, IMHO they download few files, not only one. You can test it by run fewwget
and sum the speed
– Romeo Ninov
Feb 8 at 15:05
1
I could parallelize my measurement, but what is the benefit? I already demonstrated that other clients reach full speed. The difference is that the problematic connection has a 180 ms latency. The fast connections < 10 ms. Would parallel diminish latency effects? Just asking.
– Hans Linkels
Feb 8 at 15:08
1
@RomeoNinov I checked, there is no such parallelism (speedtest.net). One file per upload and one per download ([1-2]MB each).
– Soleil
Feb 8 at 15:11
|
show 3 more comments
wget
give good practical measure of the speed. The tests of Speedtest probably include kind of parallelism which can explain higher numbers.
For good average speed test I think the time for download should be at least 90-120 seconds (to get good average)
wget
give good practical measure of the speed. The tests of Speedtest probably include kind of parallelism which can explain higher numbers.
For good average speed test I think the time for download should be at least 90-120 seconds (to get good average)
answered Feb 8 at 14:54
Romeo NinovRomeo Ninov
549210
549210
I am working on installing a more powerful logging computer and to increase the file size.
– Hans Linkels
Feb 8 at 15:00
Can you develop "kind of parallelism" ? I don't see any way/reason since there is a priori 1 connection.
– Soleil
Feb 8 at 15:04
1
@Soleil, IMHO they download few files, not only one. You can test it by run fewwget
and sum the speed
– Romeo Ninov
Feb 8 at 15:05
1
I could parallelize my measurement, but what is the benefit? I already demonstrated that other clients reach full speed. The difference is that the problematic connection has a 180 ms latency. The fast connections < 10 ms. Would parallel diminish latency effects? Just asking.
– Hans Linkels
Feb 8 at 15:08
1
@RomeoNinov I checked, there is no such parallelism (speedtest.net). One file per upload and one per download ([1-2]MB each).
– Soleil
Feb 8 at 15:11
|
show 3 more comments
I am working on installing a more powerful logging computer and to increase the file size.
– Hans Linkels
Feb 8 at 15:00
Can you develop "kind of parallelism" ? I don't see any way/reason since there is a priori 1 connection.
– Soleil
Feb 8 at 15:04
1
@Soleil, IMHO they download few files, not only one. You can test it by run fewwget
and sum the speed
– Romeo Ninov
Feb 8 at 15:05
1
I could parallelize my measurement, but what is the benefit? I already demonstrated that other clients reach full speed. The difference is that the problematic connection has a 180 ms latency. The fast connections < 10 ms. Would parallel diminish latency effects? Just asking.
– Hans Linkels
Feb 8 at 15:08
1
@RomeoNinov I checked, there is no such parallelism (speedtest.net). One file per upload and one per download ([1-2]MB each).
– Soleil
Feb 8 at 15:11
I am working on installing a more powerful logging computer and to increase the file size.
– Hans Linkels
Feb 8 at 15:00
I am working on installing a more powerful logging computer and to increase the file size.
– Hans Linkels
Feb 8 at 15:00
Can you develop "kind of parallelism" ? I don't see any way/reason since there is a priori 1 connection.
– Soleil
Feb 8 at 15:04
Can you develop "kind of parallelism" ? I don't see any way/reason since there is a priori 1 connection.
– Soleil
Feb 8 at 15:04
1
1
@Soleil, IMHO they download few files, not only one. You can test it by run few
wget
and sum the speed– Romeo Ninov
Feb 8 at 15:05
@Soleil, IMHO they download few files, not only one. You can test it by run few
wget
and sum the speed– Romeo Ninov
Feb 8 at 15:05
1
1
I could parallelize my measurement, but what is the benefit? I already demonstrated that other clients reach full speed. The difference is that the problematic connection has a 180 ms latency. The fast connections < 10 ms. Would parallel diminish latency effects? Just asking.
– Hans Linkels
Feb 8 at 15:08
I could parallelize my measurement, but what is the benefit? I already demonstrated that other clients reach full speed. The difference is that the problematic connection has a 180 ms latency. The fast connections < 10 ms. Would parallel diminish latency effects? Just asking.
– Hans Linkels
Feb 8 at 15:08
1
1
@RomeoNinov I checked, there is no such parallelism (speedtest.net). One file per upload and one per download ([1-2]MB each).
– Soleil
Feb 8 at 15:11
@RomeoNinov I checked, there is no such parallelism (speedtest.net). One file per upload and one per download ([1-2]MB each).
– Soleil
Feb 8 at 15:11
|
show 3 more comments
One reason could be that often the maximum speed cannot be reached by just a single TCP connection.
Speedtest.net recently introduced a single connection mode. Try this and see if it makes a difference.
Then, for the download use for example aria2 with parameters to use multiple conections and compare.
e.g. aria2c -d /dev -o null --allow-overwrite=true --file-allocation=none --max-connection-per-server=8 --min-split-size=1M http://aserv.example.net/~myuser/links/M77232917.txt
add a comment |
One reason could be that often the maximum speed cannot be reached by just a single TCP connection.
Speedtest.net recently introduced a single connection mode. Try this and see if it makes a difference.
Then, for the download use for example aria2 with parameters to use multiple conections and compare.
e.g. aria2c -d /dev -o null --allow-overwrite=true --file-allocation=none --max-connection-per-server=8 --min-split-size=1M http://aserv.example.net/~myuser/links/M77232917.txt
add a comment |
One reason could be that often the maximum speed cannot be reached by just a single TCP connection.
Speedtest.net recently introduced a single connection mode. Try this and see if it makes a difference.
Then, for the download use for example aria2 with parameters to use multiple conections and compare.
e.g. aria2c -d /dev -o null --allow-overwrite=true --file-allocation=none --max-connection-per-server=8 --min-split-size=1M http://aserv.example.net/~myuser/links/M77232917.txt
One reason could be that often the maximum speed cannot be reached by just a single TCP connection.
Speedtest.net recently introduced a single connection mode. Try this and see if it makes a difference.
Then, for the download use for example aria2 with parameters to use multiple conections and compare.
e.g. aria2c -d /dev -o null --allow-overwrite=true --file-allocation=none --max-connection-per-server=8 --min-split-size=1M http://aserv.example.net/~myuser/links/M77232917.txt
answered Feb 8 at 20:44
JosefJosef
32629
32629
add a comment |
add a comment |
Use https://fast.com/ , this is a Netflix based speed test meaning it cannot be differentiated by ISP's from Netflix itself.
This is a more accurate test than any other test generally. People won't be worried about how fast a webpage loads, but rather how quickly the videos buffer due to the increased bandwith necessary to display a video.
ISP's often boost speeds based on the domain someone is connecting to if it's a speed test or using port 8080. Whereas Netflix uses port 80, a slower port when it is being prioritized.
https://www.ispreview.co.uk/index.php/2016/01/ookla-accuses-uk-broadband-isp-manipulating-internet-speedtests.html
https://www.myce.com/review/internet-providers-caught-inflating-speed-test-results-78458/introduction-1/
1
"meaning it cannot be differentiated by ISP's from Netflix itself" - That is untrue, the ISP can definitely see both the DNS request and the SNI on the HTTPS connection.
– Kevin
Feb 9 at 9:29
@Kevin fast.com contacts netflix servers to download from, meaning it emulates videos from netflix itself. Although I will grant you ISPs may catch onto the fact that connecting to that specific site which subsequently contacts Netflix based servers requires prioritization similar to speedtest.net
– Jonathan
Feb 9 at 20:11
It's not exactly rocket science. All they have to do is unthrottle Netflix for a few minutes or hours after they see a fast.com connection. The upside, of course, is that you can go to fast.com to get yourself unthrottled, then close the tab and watch Netflix for real.
– Kevin
Feb 9 at 21:34
Personally I suspect it is computer science or at least related to it rather than rocket science. It seems some of the bigger ISPs (e.g. Bell) haven't caught onto fast.com over the past few years. Either way running a script on your computer that connects to fast.com in order to up your download speed every little while if the throttling is bad enough would be viable.
– Jonathan
Feb 10 at 1:32
add a comment |
Use https://fast.com/ , this is a Netflix based speed test meaning it cannot be differentiated by ISP's from Netflix itself.
This is a more accurate test than any other test generally. People won't be worried about how fast a webpage loads, but rather how quickly the videos buffer due to the increased bandwith necessary to display a video.
ISP's often boost speeds based on the domain someone is connecting to if it's a speed test or using port 8080. Whereas Netflix uses port 80, a slower port when it is being prioritized.
https://www.ispreview.co.uk/index.php/2016/01/ookla-accuses-uk-broadband-isp-manipulating-internet-speedtests.html
https://www.myce.com/review/internet-providers-caught-inflating-speed-test-results-78458/introduction-1/
1
"meaning it cannot be differentiated by ISP's from Netflix itself" - That is untrue, the ISP can definitely see both the DNS request and the SNI on the HTTPS connection.
– Kevin
Feb 9 at 9:29
@Kevin fast.com contacts netflix servers to download from, meaning it emulates videos from netflix itself. Although I will grant you ISPs may catch onto the fact that connecting to that specific site which subsequently contacts Netflix based servers requires prioritization similar to speedtest.net
– Jonathan
Feb 9 at 20:11
It's not exactly rocket science. All they have to do is unthrottle Netflix for a few minutes or hours after they see a fast.com connection. The upside, of course, is that you can go to fast.com to get yourself unthrottled, then close the tab and watch Netflix for real.
– Kevin
Feb 9 at 21:34
Personally I suspect it is computer science or at least related to it rather than rocket science. It seems some of the bigger ISPs (e.g. Bell) haven't caught onto fast.com over the past few years. Either way running a script on your computer that connects to fast.com in order to up your download speed every little while if the throttling is bad enough would be viable.
– Jonathan
Feb 10 at 1:32
add a comment |
Use https://fast.com/ , this is a Netflix based speed test meaning it cannot be differentiated by ISP's from Netflix itself.
This is a more accurate test than any other test generally. People won't be worried about how fast a webpage loads, but rather how quickly the videos buffer due to the increased bandwith necessary to display a video.
ISP's often boost speeds based on the domain someone is connecting to if it's a speed test or using port 8080. Whereas Netflix uses port 80, a slower port when it is being prioritized.
https://www.ispreview.co.uk/index.php/2016/01/ookla-accuses-uk-broadband-isp-manipulating-internet-speedtests.html
https://www.myce.com/review/internet-providers-caught-inflating-speed-test-results-78458/introduction-1/
Use https://fast.com/ , this is a Netflix based speed test meaning it cannot be differentiated by ISP's from Netflix itself.
This is a more accurate test than any other test generally. People won't be worried about how fast a webpage loads, but rather how quickly the videos buffer due to the increased bandwith necessary to display a video.
ISP's often boost speeds based on the domain someone is connecting to if it's a speed test or using port 8080. Whereas Netflix uses port 80, a slower port when it is being prioritized.
https://www.ispreview.co.uk/index.php/2016/01/ookla-accuses-uk-broadband-isp-manipulating-internet-speedtests.html
https://www.myce.com/review/internet-providers-caught-inflating-speed-test-results-78458/introduction-1/
answered Feb 9 at 1:49
JonathanJonathan
111
111
1
"meaning it cannot be differentiated by ISP's from Netflix itself" - That is untrue, the ISP can definitely see both the DNS request and the SNI on the HTTPS connection.
– Kevin
Feb 9 at 9:29
@Kevin fast.com contacts netflix servers to download from, meaning it emulates videos from netflix itself. Although I will grant you ISPs may catch onto the fact that connecting to that specific site which subsequently contacts Netflix based servers requires prioritization similar to speedtest.net
– Jonathan
Feb 9 at 20:11
It's not exactly rocket science. All they have to do is unthrottle Netflix for a few minutes or hours after they see a fast.com connection. The upside, of course, is that you can go to fast.com to get yourself unthrottled, then close the tab and watch Netflix for real.
– Kevin
Feb 9 at 21:34
Personally I suspect it is computer science or at least related to it rather than rocket science. It seems some of the bigger ISPs (e.g. Bell) haven't caught onto fast.com over the past few years. Either way running a script on your computer that connects to fast.com in order to up your download speed every little while if the throttling is bad enough would be viable.
– Jonathan
Feb 10 at 1:32
add a comment |
1
"meaning it cannot be differentiated by ISP's from Netflix itself" - That is untrue, the ISP can definitely see both the DNS request and the SNI on the HTTPS connection.
– Kevin
Feb 9 at 9:29
@Kevin fast.com contacts netflix servers to download from, meaning it emulates videos from netflix itself. Although I will grant you ISPs may catch onto the fact that connecting to that specific site which subsequently contacts Netflix based servers requires prioritization similar to speedtest.net
– Jonathan
Feb 9 at 20:11
It's not exactly rocket science. All they have to do is unthrottle Netflix for a few minutes or hours after they see a fast.com connection. The upside, of course, is that you can go to fast.com to get yourself unthrottled, then close the tab and watch Netflix for real.
– Kevin
Feb 9 at 21:34
Personally I suspect it is computer science or at least related to it rather than rocket science. It seems some of the bigger ISPs (e.g. Bell) haven't caught onto fast.com over the past few years. Either way running a script on your computer that connects to fast.com in order to up your download speed every little while if the throttling is bad enough would be viable.
– Jonathan
Feb 10 at 1:32
1
1
"meaning it cannot be differentiated by ISP's from Netflix itself" - That is untrue, the ISP can definitely see both the DNS request and the SNI on the HTTPS connection.
– Kevin
Feb 9 at 9:29
"meaning it cannot be differentiated by ISP's from Netflix itself" - That is untrue, the ISP can definitely see both the DNS request and the SNI on the HTTPS connection.
– Kevin
Feb 9 at 9:29
@Kevin fast.com contacts netflix servers to download from, meaning it emulates videos from netflix itself. Although I will grant you ISPs may catch onto the fact that connecting to that specific site which subsequently contacts Netflix based servers requires prioritization similar to speedtest.net
– Jonathan
Feb 9 at 20:11
@Kevin fast.com contacts netflix servers to download from, meaning it emulates videos from netflix itself. Although I will grant you ISPs may catch onto the fact that connecting to that specific site which subsequently contacts Netflix based servers requires prioritization similar to speedtest.net
– Jonathan
Feb 9 at 20:11
It's not exactly rocket science. All they have to do is unthrottle Netflix for a few minutes or hours after they see a fast.com connection. The upside, of course, is that you can go to fast.com to get yourself unthrottled, then close the tab and watch Netflix for real.
– Kevin
Feb 9 at 21:34
It's not exactly rocket science. All they have to do is unthrottle Netflix for a few minutes or hours after they see a fast.com connection. The upside, of course, is that you can go to fast.com to get yourself unthrottled, then close the tab and watch Netflix for real.
– Kevin
Feb 9 at 21:34
Personally I suspect it is computer science or at least related to it rather than rocket science. It seems some of the bigger ISPs (e.g. Bell) haven't caught onto fast.com over the past few years. Either way running a script on your computer that connects to fast.com in order to up your download speed every little while if the throttling is bad enough would be viable.
– Jonathan
Feb 10 at 1:32
Personally I suspect it is computer science or at least related to it rather than rocket science. It seems some of the bigger ISPs (e.g. Bell) haven't caught onto fast.com over the past few years. Either way running a script on your computer that connects to fast.com in order to up your download speed every little while if the throttling is bad enough would be viable.
– Jonathan
Feb 10 at 1:32
add a comment |
Is it just me or did no one notice he said Mbps and the wget command list "MB/s".
60mbp/s and actually getting 11.2Mb's is normal.
Mbps and MB/s are two different speeds.
"a Megabit is 1/8 as big as a Megabyte, meaning that to download a 1 MB file in 1 second you would need a connection of 8 Mbps. " So 11mbx8=88mbps...11.2Mb is actually good for a connection reporting 60-70mbps.
Are people having memory lose awnering this. You'll never get 70mb/s with a speedtest speed of 70Mbps
The output ofwget
is Mb/s which translates to Megabits/s. MB/s would translate to MegaBytes/s. Just run your ownwget
command and verify the result.
– Thomas
Feb 9 at 11:33
@james: Yes by default, but in OP thewget
command includes--report-speed=bits
which results inMb/s
which isMbit/s
. Running without--report-speed=bits
givesMB/s
which translates toMByte/s
. Note theb
andB
.
– Thomas
Feb 9 at 16:30
add a comment |
Is it just me or did no one notice he said Mbps and the wget command list "MB/s".
60mbp/s and actually getting 11.2Mb's is normal.
Mbps and MB/s are two different speeds.
"a Megabit is 1/8 as big as a Megabyte, meaning that to download a 1 MB file in 1 second you would need a connection of 8 Mbps. " So 11mbx8=88mbps...11.2Mb is actually good for a connection reporting 60-70mbps.
Are people having memory lose awnering this. You'll never get 70mb/s with a speedtest speed of 70Mbps
The output ofwget
is Mb/s which translates to Megabits/s. MB/s would translate to MegaBytes/s. Just run your ownwget
command and verify the result.
– Thomas
Feb 9 at 11:33
@james: Yes by default, but in OP thewget
command includes--report-speed=bits
which results inMb/s
which isMbit/s
. Running without--report-speed=bits
givesMB/s
which translates toMByte/s
. Note theb
andB
.
– Thomas
Feb 9 at 16:30
add a comment |
Is it just me or did no one notice he said Mbps and the wget command list "MB/s".
60mbp/s and actually getting 11.2Mb's is normal.
Mbps and MB/s are two different speeds.
"a Megabit is 1/8 as big as a Megabyte, meaning that to download a 1 MB file in 1 second you would need a connection of 8 Mbps. " So 11mbx8=88mbps...11.2Mb is actually good for a connection reporting 60-70mbps.
Are people having memory lose awnering this. You'll never get 70mb/s with a speedtest speed of 70Mbps
Is it just me or did no one notice he said Mbps and the wget command list "MB/s".
60mbp/s and actually getting 11.2Mb's is normal.
Mbps and MB/s are two different speeds.
"a Megabit is 1/8 as big as a Megabyte, meaning that to download a 1 MB file in 1 second you would need a connection of 8 Mbps. " So 11mbx8=88mbps...11.2Mb is actually good for a connection reporting 60-70mbps.
Are people having memory lose awnering this. You'll never get 70mb/s with a speedtest speed of 70Mbps
edited Feb 9 at 10:44
answered Feb 9 at 10:39
blah Chesleyblah Chesley
92
92
The output ofwget
is Mb/s which translates to Megabits/s. MB/s would translate to MegaBytes/s. Just run your ownwget
command and verify the result.
– Thomas
Feb 9 at 11:33
@james: Yes by default, but in OP thewget
command includes--report-speed=bits
which results inMb/s
which isMbit/s
. Running without--report-speed=bits
givesMB/s
which translates toMByte/s
. Note theb
andB
.
– Thomas
Feb 9 at 16:30
add a comment |
The output ofwget
is Mb/s which translates to Megabits/s. MB/s would translate to MegaBytes/s. Just run your ownwget
command and verify the result.
– Thomas
Feb 9 at 11:33
@james: Yes by default, but in OP thewget
command includes--report-speed=bits
which results inMb/s
which isMbit/s
. Running without--report-speed=bits
givesMB/s
which translates toMByte/s
. Note theb
andB
.
– Thomas
Feb 9 at 16:30
The output of
wget
is Mb/s which translates to Megabits/s. MB/s would translate to MegaBytes/s. Just run your own wget
command and verify the result.– Thomas
Feb 9 at 11:33
The output of
wget
is Mb/s which translates to Megabits/s. MB/s would translate to MegaBytes/s. Just run your own wget
command and verify the result.– Thomas
Feb 9 at 11:33
@james: Yes by default, but in OP the
wget
command includes --report-speed=bits
which results in Mb/s
which is Mbit/s
. Running without --report-speed=bits
gives MB/s
which translates to MByte/s
. Note the b
and B
.– Thomas
Feb 9 at 16:30
@james: Yes by default, but in OP the
wget
command includes --report-speed=bits
which results in Mb/s
which is Mbit/s
. Running without --report-speed=bits
gives MB/s
which translates to MByte/s
. Note the b
and B
.– Thomas
Feb 9 at 16:30
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f952978%2fwhy-the-discrepancy-between-speedtest-and-wget%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Another way to check speed is to do
ssh personal-server cat /dev/zero | pv > /dev/null
, on a personal server that you know is not rate limited to be slower than the speed you're expecting.– JoL
Feb 8 at 20:23
I skimmed your question. And it sounds like you have a large bandwidth and maybe significant round trip delay scenario also known as a "long fat network". I've experienced this sort of thing personally and solved it by opening up many connections (I used rsync). Can you try opening many wget instances (try 5, 10, 20)? Wikipedia page is: bandwidth delay product.
– Trevor Boyd Smith
Feb 9 at 13:05
Wget reports in bytes by default: [james@lamia root]$ wget -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 112MB/s in 0.9s [james@lamia root]$ wget --report-speed=bits -O /dev/null 10.32.48.1/t1 /dev/null 100%[=====================>] 100.00M 932Mb/s in 0.9s
– james
Feb 9 at 14:46
Consider running an iperf server for tcp and a second for udp on your DC-hosted machine. Then as part of the cron job call a test from your client and see how the speeds compare with the http get.
– Criggie
Feb 10 at 1:03
What kind of file is it anyway? Is it compressible and the server supports http compression? While you cannot fix bandwidth issues you might be able to make the file smaller.
– Salman A
Feb 10 at 12:11