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