From owner-freebsd-hubs@FreeBSD.ORG Sun Nov 5 18:58:13 2006 Return-Path: X-Original-To: freebsd-hubs@freebsd.org Delivered-To: freebsd-hubs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E95EC16A40F for ; Sun, 5 Nov 2006 18:58:13 +0000 (UTC) (envelope-from albryan@comcast.net) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.77.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B7E43D90 for ; Sun, 5 Nov 2006 18:57:44 +0000 (GMT) (envelope-from albryan@comcast.net) Received: from blip (c-66-176-118-121.hsd1.fl.comcast.net[66.176.118.121]) by comcast.net (sccrmhc13) with SMTP id <20061105185743013008tca8e>; Sun, 5 Nov 2006 18:57:43 +0000 From: "Anthony L. Bryan" To: "'Francois Petillon'" , Date: Sun, 5 Nov 2006 13:57:42 -0500 Message-ID: <000301c7010c$4675d070$0201a8c0@blip> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4549C49F.4090109@proxad.net> Thread-Index: Acb+Z3JWaKOa59ZJQYCM/7GJ33FlmACo3scg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Cc: Subject: RE: ISO downloads with multiple mirrors for higher reliabilty, automatic checksum verification X-BeenThere: freebsd-hubs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "FreeBSD Distributions Hubs: mail sup ftp" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2006 18:58:14 -0000 > Anthony L. Bryan wrote: > > I've made Metalinks for a few FreeBSD ISOs: > >=20 > http://www.metalinker.org/samples/FreeBSD_6_2-BETA3-amd64-boot only_iso.metal > > ink >=20 > As these Metalinks are not officials, would it be possible to remove=20 > ftp.fr.freebsd.org from these files ? I do not want to support nor=20 > promote an "open standard" that encourage software to do parallel=20 > segmented downloads. Of course, Fran=E7ois! =20 > I have several problems with segmented downloads. As software open=20 > several connections (it may be several connections on a=20 > single server or=20 > single connections on several servers, the result is the=20 > same), servers=20 > will serve more connections and will have less memory usable per=20 > connection. As one of the biggest problem on servers is=20 > related to disks=20 > IO optimizations, less memory may lead to smaller block reads=20 > (and thus=20 > higher disk load). Even if the server has enough memory, as=20 > the file are=20 > requested by segments, you are disabling on the server the ability to=20 > fully optimize its disk requests. Last but not the least (and it does=20 > not concern bittorent downloads, only servers), if you do not=20 > download=20 > at max speed, it means there is a _real_ bottleneck. It may be on the=20 > server, it may be on the network but speeding up download by using=20 > segmented downloads will not create bandwidth, you will just steal=20 > bandwidth to other people. While some people are using metalinks for segmented downloads, others = are not. Some people use them for the enhanced reliability of having extra = links to fall back on. I can not force download managers or metalink clients = to change how they have been behaving for years, but I can encourage them = to be respectful of server resources. Which is why I have been asking for suggestions on how to improve things. Can you think of some per transfer and per server options that would = help the situation? Maybe something like for each transfer max connections and max servers = and for servers something like max connections and segment size? (( Anthony Bryan )) Metalink [ http://www.metalinker.org ]