Hi there,
I've checked from a few datacenters to make sure it wasn't any particular location, but mirrors.bluehost.com appears to be limited to 10KB/s. Yum's "fastest-mirrors" keeps selecting this for a handful of servers making yum very slow. The issue has been present for at last the past several days. I imagine I'm not the only one with this issue?
They don't show up in the main mirror list, but they show up in 'ok' status on the mirror status page.
--Graham
hi,
On 08/23/2010 10:53 PM, Graham Frank wrote:
I've checked from a few datacenters to make sure it wasn't any particular location, but mirrors.bluehost.com appears to be limited to 10KB/s. Yum's "fastest-mirrors" keeps selecting this for a handful of servers making yum very slow. The issue has been present for at last the past several days. I imagine I'm not the only one with this issue?
Can you do some tests from your network to theirs and see if there is a bottleneck somewhere enroute ?
They don't show up in the main mirror list, but they show up in 'ok' status on the mirror status page.
I can fairly easily plumb in a scheduled regular tests that would check b/w rates from various places. However, the question then would be : what is a reasonable acceptable[1] performance test.
If we can come up with a test that is considered acceptable, we can then move to adding a metric from there into the mirrorlist generation to make sure that slower mirrors are used more infrequently.
The caveat here being that even through a machine might only be 10mbps, because its used more infrequently - it might give its 2 simultaneous users a better / faster experience than the 100mbps machine can to its 500 simultaneous users.
Thoughts ?
- KB
[1]: acceptable to the mirror admins. I dont think they would like it much if we were to pull a 600M iso every 6 hours as a speed test.
From: Karanbir Singh mail-lists@karan.org Reply-To: "Mailing list for CentOS mirrors." centos-mirror@centos.org Date: Tue, 24 Aug 2010 20:59:37 +1000 To: "Mailing list for CentOS mirrors." centos-mirror@centos.org Subject: Re: [CentOS-mirror] Very Slow Mirror
Can you do some tests from your network to theirs and see if there is a bottleneck somewhere enroute ?
Hi KB,
I am also getting exactly 10KB/s from that mirror to here in Australia when downloading an ISO (at the office, at home and on a server in our DC).
I am also getting the same result when downloading the same ISO from a personal server I have with Rackspace in Dallas, TX.
It does look suspiciously like a bandwidth cap.
-Shaun
Hi Robert,
Is this something that you are able to comment on ?
On 08/24/2010 02:29 PM, Shaun Ewing wrote:
Can you do some tests from your network to theirs and see if there is a bottleneck somewhere enroute ?
I am also getting exactly 10KB/s from that mirror to here in Australia when downloading an ISO (at the office, at home and on a server in our DC).
I am also getting the same result when downloading the same ISO from a personal server I have with Rackspace in Dallas, TX.
It does look suspiciously like a bandwidth cap.
Thanks,
- KB
Weird, not sure what happened there as we were not intentionally limiting it to 10K, but I agree that nothing could download from us any faster then that. Everything should be good again.
- Spencer
On 08/24/2010 07:39 AM, Karanbir Singh wrote:
Hi Robert,
Is this something that you are able to comment on ?
On 08/24/2010 02:29 PM, Shaun Ewing wrote:
Can you do some tests from your network to theirs and see if there is a bottleneck somewhere enroute ?
I am also getting exactly 10KB/s from that mirror to here in Australia when downloading an ISO (at the office, at home and on a server in our DC).
I am also getting the same result when downloading the same ISO from a personal server I have with Rackspace in Dallas, TX.
It does look suspiciously like a bandwidth cap.
Thanks,
- KB
CentOS-mirror mailing list CentOS-mirror@centos.org http://lists.centos.org/mailman/listinfo/centos-mirror
KB -- In general, CentOS mirrors have been fine enough in my experience. A simple test for something like this could be just a few samples of download rates periodically and then make note of it in the mirror status page.
Suppose an average response from a server of 80Kbps gets it a bad mark. 8Mbps or higher is good enough for most yum needs I would think. 32Mbps on up is excellent. Incorporating something similar into the status page and fastest-mirror could help get around issues such as this one.
We are not looking to come up with an index of how fast each mirror is. Rather, we are simply trying to identify problems with mirrors to preemptively handle issues and offer a baseline of a mirror's speed.
The options for this are numerous. Your thoughts?
[1]: acceptable to the mirror admins. I dont think they would like it much if we were to pull a 600M iso every 6 hours as a speed test.
So why not pull a small 1MB test file? That's only a few megs a day, and less than a half gig a month. I dare say only testing once or twice daily would be necessary. You don't need much to see if any mirror is running at a crawl.
Hopefully my thoughts lead to something. Have a good evening!
--Graham
On Tue, Aug 24, 2010 at 5:59 AM, Karanbir Singh mail-lists@karan.org wrote:
I can fairly easily plumb in a scheduled regular tests that would check b/w rates from various places. However, the question then would be : what is a reasonable acceptable[1] performance test.
If we can come up with a test that is considered acceptable, we can then move to adding a metric from there into the mirrorlist generation to make sure that slower mirrors are used more infrequently.
The caveat here being that even through a machine might only be 10mbps, because its used more infrequently - it might give its 2 simultaneous users a better / faster experience than the 100mbps machine can to its 500 simultaneous users.
On 8/24/2010 5:13 PM, Graham Frank wrote:
KB -- In general, CentOS mirrors have been fine enough in my experience. A simple test for something like this could be just a few samples of download rates periodically and then make note of it in the mirror status page.
Suppose an average response from a server of 80Kbps gets it a bad mark. 8Mbps or higher is good enough for most yum needs I would think. 32Mbps on up is excellent. Incorporating something similar into the status page and fastest-mirror could help get around issues such as this one.
We are not looking to come up with an index of how fast each mirror is. Rather, we are simply trying to identify problems with mirrors to preemptively handle issues and offer a baseline of a mirror's speed.
The options for this are numerous. Your thoughts?
Only problem I see with this is it would be dependent on what the mirror could pull from the other mirrors. Lets say the "checking" server is in the US, and the server being checked is in Australia. It might hand out 10Gb/s to local users, But it doesn't get used because its marked bad, All because the checking server is far away(network wise). Or lets say the "checking" server has some sort of bandwidth issue, Then they all get marked poor... Lots of things to consider on this one.
[1]: acceptable to the mirror admins. I dont think they would like it much if we were to pull a 600M iso every 6 hours as a speed test.
So why not pull a small 1MB test file? That's only a few megs a day, and less than a half gig a month. I dare say only testing once or twice daily would be necessary. You don't need much to see if any mirror is running at a crawl.
Hopefully my thoughts lead to something. Have a good evening!
--Graham
On Tue, Aug 24, 2010 at 5:59 AM, Karanbir Singhmail-lists@karan.org wrote:
I can fairly easily plumb in a scheduled regular tests that would check b/w rates from various places. However, the question then would be : what is a reasonable acceptable[1] performance test.
If we can come up with a test that is considered acceptable, we can then move to adding a metric from there into the mirrorlist generation to make sure that slower mirrors are used more infrequently.
The caveat here being that even through a machine might only be 10mbps, because its used more infrequently - it might give its 2 simultaneous users a better / faster experience than the 100mbps machine can to its 500 simultaneous users.
CentOS-mirror mailing list CentOS-mirror@centos.org http://lists.centos.org/mailman/listinfo/centos-mirror
Nick -- Oh most definitely. One thought I had previously was an opt-in where users who update with yum can opt to have transfer rates sent back to centos.org. But that's treading into deep waters...
When I say "test the server" I mean in a distributed sense. I.e. multiple servers are checking from many geographically diverse regions. Any one faulty checking server can easily be identified in a sea of working ones. That idea pushes up the bandwidth usage for checking, however. But even if checking uses a gigabyte of bandwidth per month, that's nothing compared to the overall bandwidth they will see in the same time period. Some acceptable ground should be there somewhere.
--Graham
On Tue, Aug 24, 2010 at 4:20 PM, Nick Olsen Nick@141networks.com wrote:
Only problem I see with this is it would be dependent on what the mirror could pull from the other mirrors. Lets say the "checking" server is in the US, and the server being checked is in Australia. It might hand out 10Gb/s to local users, But it doesn't get used because its marked bad, All because the checking server is far away(network wise). Or lets say the "checking" server has some sort of bandwidth issue, Then they all get marked poor... Lots of things to consider on this one.
Now that sounds like a plan. Since were treading here. I would also propose this service be run on the msync machines, As I figure they are already geographically diverse.
I would also go further to say that in this process of checking, You get results back, 5 machines say bad, 2 say 30Mb/s+ then it would be marked as good for its region. If the mirror could push out a good amount of bandwidth to even one of the testing machines, it is doing fine. And the others could be lined up as bad peering/connection to the server. You know, Atleast have a bit of intelligence in the method. And Yes, if the "monitoring" load was as low as 1gb a month, most mirrors wouldn't even notice.
On 8/24/2010 5:30 PM, Graham Frank wrote:
Nick -- Oh most definitely. One thought I had previously was an opt-in where users who update with yum can opt to have transfer rates sent back to centos.org. But that's treading into deep waters...
When I say "test the server" I mean in a distributed sense. I.e. multiple servers are checking from many geographically diverse regions. Any one faulty checking server can easily be identified in a sea of working ones. That idea pushes up the bandwidth usage for checking, however. But even if checking uses a gigabyte of bandwidth per month, that's nothing compared to the overall bandwidth they will see in the same time period. Some acceptable ground should be there somewhere.
--Graham
On Tue, Aug 24, 2010 at 4:20 PM, Nick OlsenNick@141networks.com wrote:
Only problem I see with this is it would be dependent on what the mirror could pull from the other mirrors. Lets say the "checking" server is in the US, and the server being checked is in Australia. It might hand out 10Gb/s to local users, But it doesn't get used because its marked bad, All because the checking server is far away(network wise). Or lets say the "checking" server has some sort of bandwidth issue, Then they all get marked poor... Lots of things to consider on this one.
CentOS-mirror mailing list CentOS-mirror@centos.org http://lists.centos.org/mailman/listinfo/centos-mirror
Dear List, we like freedom & we like to investigate all issue, That's why we are all here:
From my network, I just done a test with wget, traceroute and date,
see the Result please:
[root@DW-NOC-ACCESS-RTR1 ~]# wget http://mirrors.bluehost.com/centos/5.5/os/i386/CentOS/Deployment_Guide-fr-FR... --12:50:21-- http://mirrors.bluehost.com/centos/5.5/os/i386/CentOS/Deployment_Guide-fr-FR... => `Deployment_Guide-fr-FR-5.2-11.el5.centos.noarch.rpm' Resolving mirrors.bluehost.com... 67.20.126.75 Connecting to mirrors.bluehost.com|67.20.126.75|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3,413,889 (3.3M) [application/x-rpm]
100%[=================================================================================>] 3,413,889 303.41K/s ETA 00:00
12:51:34 (57.53 KB/s) - `Deployment_Guide-fr-FR-5.2-11.el5.centos.noarch.rpm' saved [3413889/3413889]
[root@DW-NOC-ACCESS-RTR1 ~]# traceroute 67.20.126.75 traceroute to 67.20.126.75 (67.20.126.75), 30 hops max, 38 byte packets 1 gw-out-noc.dhaka-wireless.net (175.158.99.250) 0.466 ms 0.840 ms 0.506 ms 2 123.49.51.41 (123.49.51.41) 7.868 ms 8.081 ms 9.141 ms 3 123.49.13.90 (123.49.13.90) 5.525 ms 6.678 ms 7.907 ms 4 pos4-2-0.palermo7.pal.seabone.net (195.22.197.89) 148.326 ms 147.982 ms 149.399 ms 5 ge15-0.newark4.new.seabone.net (195.22.216.235) 268.381 ms 267.615 ms 267.877 ms 6 te-4-2.car3.Newark1.Level3.net (4.71.148.9) 295.591 ms 299.682 ms 298.314 ms 7 ae-32-52.ebr2.Newark1.Level3.net (4.68.99.62) 299.780 ms 315.573 ms 297.960 ms 8 ae-4-4.ebr2.Washington1.Level3.net (4.69.132.101) 298.554 ms 299.107 ms 309.391 ms 9 ae-62-62.csw1.Washington1.Level3.net (4.69.134.146) 300.695 ms 302.792 ms ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) 296.040 ms 10 ae-64-64.ebr4.Washington1.Level3.net (4.69.134.177) 308.027 ms 311.492 ms 296.944 ms 11 ae-4-4.ebr3.LosAngeles1.Level3.net (4.69.132.81) 299.212 ms 321.303 ms 310.172 ms 12 ae-12-60.car2.LosAngeles1.Level3.net (4.69.144.4) 288.631 ms ae-22-70.car2.LosAngeles1.Level3.net (4.69.144.68) 316.002 ms 315.636 ms 13 BLUEHOST-IN.car2.LosAngeles1.Level3.net (4.71.143.106) 290.553 ms 289.261 ms 289.636 ms 14 tg2-3.ar01.prov.bluehost.com (69.195.64.37) 343.550 ms 303.331 ms 324.243 ms 15 * * * 16 * [root@DW-NOC-ACCESS-RTR1 ~]# Wed Aug 25 12:54:44 BDT 2010 [root@DW-NOC-ACCESS-RTR1 ~]#
I almost get this type of speed when I download from any EU or US mirror. Hope to see the final result of this bottleneck. Is it something that some of ISP control b/w due to SPAM/Abuse report of bluehost.com hosting provider. On Wed, Aug 25, 2010 at 4:17 AM, Nick Olsen Nick@141networks.com wrote:
Now that sounds like a plan. Since were treading here. I would also propose this service be run on the msync machines, As I figure they are already geographically diverse.
I would also go further to say that in this process of checking, You get results back, 5 machines say bad, 2 say 30Mb/s+ then it would be marked as good for its region. If the mirror could push out a good amount of bandwidth to even one of the testing machines, it is doing fine. And the others could be lined up as bad peering/connection to the server. You know, Atleast have a bit of intelligence in the method. And Yes, if the "monitoring" load was as low as 1gb a month, most mirrors wouldn't even notice.
On 8/24/2010 5:30 PM, Graham Frank wrote:
Nick -- Oh most definitely. One thought I had previously was an opt-in where users who update with yum can opt to have transfer rates sent back to centos.org. But that's treading into deep waters...
When I say "test the server" I mean in a distributed sense. I.e. multiple servers are checking from many geographically diverse regions. Any one faulty checking server can easily be identified in a sea of working ones. That idea pushes up the bandwidth usage for checking, however. But even if checking uses a gigabyte of bandwidth per month, that's nothing compared to the overall bandwidth they will see in the same time period. Some acceptable ground should be there somewhere.
--Graham
On Tue, Aug 24, 2010 at 4:20 PM, Nick OlsenNick@141networks.com wrote:
Only problem I see with this is it would be dependent on what the mirror could pull from the other mirrors. Lets say the "checking" server is in the US, and the server being checked is in Australia. It might hand out 10Gb/s to local users, But it doesn't get used because its marked bad, All because the checking server is far away(network wise). Or lets say the "checking" server has some sort of bandwidth issue, Then they all get marked poor... Lots of things to consider on this one.
CentOS-mirror mailing list CentOS-mirror@centos.org http://lists.centos.org/mailman/listinfo/centos-mirror
CentOS-mirror mailing list CentOS-mirror@centos.org http://lists.centos.org/mailman/listinfo/centos-mirror
-
Bangladeshi CentOS Mirror Maintainer [BD-SERVERS.NET] -
Graham Frank -
Karanbir Singh -
Nick Olsen -
Shaun Ewing -
Spencer Candland