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)