Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-admin
Navigation:
Lists: gentoo-admin: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: admin@g.o
From: Damon Conway <kabau@g.o>
Subject: Re: Rsync minimum connection limits
Date: Mon, 26 Aug 2002 11:10:43 -0500
So does you guys have any thoughts or opinions on this subject?

kabau

On Sun, Aug 18, 2002 at 08:08:44PM -0500, Damon Conway wrote:
> On Mon, Aug 19, 2002 at 12:22:38AM +0100, Colin Morey wrote:
> > Do we have a defined number of minimum connections a server should
> > allow? or are we basing on an had hoc basis, based upon transit and
> > availability as well?
> 
> That is an excellent question, and one I've yet to find a good answer
> for.  It is my opinion that we cannot afford to be too picky when
> someone offers their services to us, but it also doesn't help to have
> servers out there that can't perform.  Unfortunatly, I've been too busy
> with life to give this matter much thought.
> 
> The way I see it, we have three basic requirements for rsync mirrors.
> 
> 1.  Enough available bandwidth to serve a substantial amount of data.
> 
> 2.  Accurate and timely data.  
> 
> 3.  Sufficient number of simultaneous logins to allow enough people to
>     actually use the mirror.
> 
> I would suggest that the mirror have at least a T1 of available
> bandwidth.  It doesn't have to dedicate the entire T1 to rsync
> mirroring, but if all they have is ISDN, DSL, or cable, then they aren't
> going to be pleased with rsync using all of their bandwidth.  I would
> suggest a minimum 128kb/s of available bandwidth for rsync bandwidth on
> a mirror.  This number would be better at 256kb/s, but 128kb/s should be
> usable.
> 
> Some method needs to be developed for making sure that mirrors are updated 
> in a timely fashion, and have accurate copies of the master.  There have
> been several reports of out-of-date and bad data on mirrors.  Right now,
> we have people updating their mirror every 30 minutes on the 0 and 30.
> This will quickly become inadequate if we continue to grow our number of
> mirrors.  Keeping an infrastructure like this healthy as it grows will
> probably be the biggest task this admin team will face.  I have lots of
> ideas on this, but they can wait until we get some basic parameters down
> for mirrors.  Right now, it should be sufficient to develop an automated
> system that checks for inaccurate and out of sync mirrors.
> 
> The third item seems to be the big point everyone is interested in, and
> in my opinion the least of our worries.  However, I'm tired of hearing
> people whine about it so I've given it some thought.  This ties into
> item one since the more people you have using a server, the more
> bandwidth you need.  I think we should have ratios of bandwidth to
> max concurrent users.  Maybe 5 users for every 128kb/s of available
> bandwidth.  Basically, to determine these numbers we need to determine
> the average user's rsync transfer, and come up with an average sustained
> data rate for an rsync transfer.
> 
> Now, these are just my opinions.  What do y'all think?
> 
> Damon/kabau
> 
> 
> _______________________________________________
> Gentoo-admin mailing list
> Gentoo-admin@g.o
> http://lists.gentoo.org/mailman/listinfo/gentoo-admin

Replies:
Re: Rsync minimum connection limits
-- Colin Morey
References:
Rsync minimum connection limits
-- Colin Morey
Re: Rsync minimum connection limits
-- Damon Conway
Navigation:
Lists: gentoo-admin: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Rsync minimum connection limits
Next by thread:
Re: Rsync minimum connection limits
Previous by date:
rsync site in tw (taiwan)
Next by date:
Re: Rsync minimum connection limits


Updated Jun 17, 2009

Summary: Archive of the gentoo-admin mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.