From owner-freebsd-stable Sat Aug 10 9: 7:50 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D100637B400 for ; Sat, 10 Aug 2002 09:07:47 -0700 (PDT) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00E3C43E42 for ; Sat, 10 Aug 2002 09:07:47 -0700 (PDT) (envelope-from chuck@codefab.com) Received: from prime ([12.88.89.182]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020810160745.ZXVU11089.mtiwmhc22.worldnet.att.net@prime> for ; Sat, 10 Aug 2002 16:07:45 +0000 Message-ID: <000001c24088$0044bd30$0301a8c0@prime> From: "Charles Swiger" To: References: <20020810115843.B6225-100000@phoenix.vh.laserfence.net> Subject: Re: dummynet and Fastrack/Kazaa? Date: Sat, 10 Aug 2002 10:52:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Willie Viljoen wrote: > I've recently been facing the problem that people with these P2P > clients are eating up major bandwidth. For this reason I've > implemented dummynet to try and curb them abit. > > The problem now is that I keep getting complaints that "my kazaa > doesn't work at all" First, they're probably used to being able to suck 128+ Kbit streams in realtime (which is why they're "eating major bandwidth" :-). Tell 'em to reconfigure their clients for 56K connectivity speeds rather than broadband speeds, and tell 'em to get used having to wait for the song or whatever to buffer, first. A potentially better solution would be to implement QoS with different priority packet queue groups (using dummynet pipes), rather than using fixed bandwidth limits. Or combine the two approaches, but give a larger bandwidth cap. That way, other traffic gets the nod when that other traffic exists, but the P2P guys can use spare bandwidth when nothing else is going on. -Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message