AW: [CentOS-mirror] Average Monthly Transfer used?

Wed Oct 8 13:19:15 UTC 2008
florian at <florian at>

Hi Lee


There seem to be many people on the list who are eager to show off that they
have "multiple mirrors" or have "multiple-gigabit" connections and other
superlatives. Nevertheless they do contribute and deserve merit for the
donation of something what at the end of the day rather turns out to be
based on a 99$ unlimited "shared" bandwith rented server offering. And those
are normally the same ones who ask in their second post to the list to be
added to the ACL to mirror DVDs directly from the master servers as if
binary data coming from one of the existing ones who made it in time to that
ACL had less value. 


What really counts for the project is a meshed content delivery network with
fast connections and I personally find as much as possible peered local
traffic instead of commercial transit traffic, however the peering situation
is not a technical but only a commercial inconvenience. The
"yum-fastesmirror" plugin now shipping as default has made the situation
more sane because local mirrors are now preferred while before, data traffic
was carried around the world by the questionable logic the CentOS team
matches server and host IP through DNS.



What is strongly disliked are mirrors shaping the total bandwith on the port
to a ridiculous amount of say 2-5 Mbit. This results in slow performance for
the leechers from that server since the mirror accepts all request but
delivers equally slow to all of them. Unfortunately yum only picks the next
mirror on failure but doesn't failover in case of slow performance and
cannot suck from multiple sources as bittorrent can. It is better not to
have a mirror than having an extremely slow one. If you are not a carrier
and you don't have to manage bandwith but purchase data volumes from someone
who does, it's perfectly acceptable to allow downloads at wirespeed "as long
as offer lasts" and completely stop the mirror when your volume is reached
since other mirrors will take over the job thanks to the failover mechanism
in yum. It's not a website where people look at and where your reputation
suffers if it's down. Don't be shy about denying download requests at will,
smarty yum, sitting on millions of machines to get fresh content for its
host will pick the next mirror without complaint. 

To make it short, if you want to contribute and you are serious about it,
budget for a certain throughput not less than 10 Mbit and not more than some
30 Mbit and be creative by having Apache denying requests if the bandwith
suddenly outreaches your budget.


My MRTGs are not public as of yet but realistic volumes for CentOS ONLY can
be seen here: (German mirror, with DVD iso) (Swiss mirror, without DVD iso)



Expect volumes to double or triple for a couple days when a new release
(5.1->5.2) comes out.


Regards, Florian



Von: centos-mirror-bounces at
[mailto:centos-mirror-bounces at] Im Auftrag von Lee Clements
Gesendet: Dienstag, 7. Oktober 2008 20:14
An: centos-mirror at
Betreff: [CentOS-mirror] Average Monthly Transfer used?


Hey Everyone,


I'm a newbie to the list, not sure if this topic has been covered before but
was about to establish a CentOS mirror to support what has helped me out
tremendously in the last few months.


On Average, how much does a standard mirror pull per month in transfer?


Any help would be appreciated!




Lee Clements

Network Architect


Direct: 312.376.8872

Main: 312.376.8870

Fax: 312.205.0153

lee at <> 






DISCLAIMER: This e-mail, and any attachments thereto, is intended only for
use by the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient of
this e-mail (or the person responsible for delivering this document to the
intended recipient), you are hereby notified that any dissemination,
distribution, printing or copying of this e-mail, and any attachment
thereto, is strictly prohibited. If you have received this e-mail in error,
please respond to the individual sending the message, and permanently delete
the original and any copy of any e-mail and printout thereof.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2536 bytes
Desc: not available
URL: <>