[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apt and multiple connections



On Fri, 22 Sep 2000, Jason Gunthorpe wrote:

> > for whatever reason that the server being used could only supply 3 KB/s,
> > then the client still has 2KB/s of available bandwidth that isnt being
> > used. This 2KB/s could be supplied by a different mirror to download the
> > same file.

Yick.  The current method is much cleaner, if not quite as efficent.
I don't like the idea of getting _parts_ of a file from different places,
thank you.

> Or the user could just pick a good mirror to start with - we do have 140
> of them.

Or multiple of them.

If you make multiple apt lines and mix up the order of the sections, it
works well so long as the mirrors update evenly (else it'll always use the
most uptodate one)

For instance:

deb http://source1 woody main
deb ftp://source2 woody main
deb http://source3 woody main
deb ftp://source2 woody contrib
deb http://source3 woody contrib
deb http://source1 woody contrib
deb http://source3 woody non-free
deb http://source1 woody non-free
deb ftp://source2 woody non-free

will allow apt to fetch up to 3 packages at once, from 3 mirrors, because
it will favor different mirrors for each section.

This is sub-optimal, since it would be nice to have it fetch from the same
section (main for instance) from _each_ mirror at once, 3 different
packages.  I'd like to see that happen.

> Using 1 server the clients bandwidth tends to be throttled by latency and
> other network conditions. With a modem this is not an issue, with DSL and
> Cable users it really, really is. A typical DSL/Cable user may only get
> 30% utilization of their very wide pipe, if they start using multiple
> connections to get around that then we may start seeing upwards of a 3x
> increase in bandwidth demands on our mirrors!

Actually, I'm not sure that's true.  I'll be fetching the same amount of
data, but spreading it among various mirrors. I'm trading my bandwidth for
time, not your bandwidth.  Your mirror will still be throttled from my
perspective. If 3 people used the same 3 mirrors instead of each 1 one
mirror, it's the same amount of data, and the bandwidth should look the
same as 3 users off a single mirror.  Since we transfer less from any one
mirror, that mirror is available 2/3 more of the time.  This should cancel
out over the long run...

If any given server will only serve me data at 3K or even 30K a sec, but I
can get 3 different servers to each serve me 3-30K, I've taken less time
and spread out the load on any one server.  If a mirror is concerned about
bandwidth, they can set a limit, and it will still make that mirror useful
to everyone as opposed to being considered 'slow' and avoided.  I wouldn't
mind if some of my packages were grabbed at 3K, _if_ I could say "get
anything bigger than 1 meg from MirrorX_fast, and anything smaller than
25K from MirrorY_slow, and use Mirrors Z,Q, & D for the rest..."








Reply to: