[CentOS-mirror] Very Slow Mirror

Wed Aug 25 02:57:33 EDT 2010

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 at DW-NOC-ACCESS-RTR1 ~]# wget
http://mirrors.bluehost.com/centos/5.5/os/i386/CentOS/Deployment_Guide-fr-FR-5.2-11.el5.centos.noarch.rpm
--12:50:21--  http://mirrors.bluehost.com/centos/5.5/os/i386/CentOS/Deployment_Guide-fr-FR-5.2-11.el5.centos.noarch.rpm
           => `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 at 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 at DW-NOC-ACCESS-RTR1 ~]#
Wed Aug 25 12:54:44 BDT 2010
[root at 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 at 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 Olsen<Nick at 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 at centos.org
>> http://lists.centos.org/mailman/listinfo/centos-mirror
>>
>
> _______________________________________________
> CentOS-mirror mailing list
> CentOS-mirror at centos.org
> http://lists.centos.org/mailman/listinfo/centos-mirror
>

-- 
Regards
Noor Ahamed Bauani
Technology Advisor
Dhaka Wireless
http://www.dhaka-wireless.net/
HP: +880-1818-BAUANI (SMS Only, No Direct Call Please)