From owner-freebsd-current Tue Apr 18 12:30:39 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA15362 for current-outgoing; Tue, 18 Apr 1995 12:30:39 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA15356 for ; Tue, 18 Apr 1995 12:30:37 -0700 Received: from silver.sms.fi (silver.sms.fi [193.64.137.1]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id MAA09201 for ; Tue, 18 Apr 1995 12:27:58 -0700 Received: (from pete@localhost) by silver.sms.fi (8.6.11/8.6.9) id WAA00592; Tue, 18 Apr 1995 22:27:59 +0300 Date: Tue, 18 Apr 1995 22:27:59 +0300 Message-Id: <199504181927.WAA00592@silver.sms.fi> From: Petri Helenius To: Joe Greco Cc: freebsd-current@FreeBSD.org Subject: Re: mmap bugs gone yet? In-Reply-To: <9504181532.AA06693@brasil.moneng.mei.com> References: <199504181024.NAA15219@silver.sms.fi> <9504181532.AA06693@brasil.moneng.mei.com> Sender: current-owner@FreeBSD.org Precedence: bulk Joe Greco writes: > > Hi Pete, > > What precisely ARE these shortcomings that you see? I'm sorta curious. :-) > INN is a 1000% improvement over C-news for complex environments, and while I > would definitely consider INN to be a work in progress, the fundamental > design philosophy seems to work. > I can agree that INN is _huge_ improvement over C-news but it still does not solve the problem that most likely an article comes in, gets stored to the disk and then when we're running a hub it's read from the disk about 20 times if the fanout is 50 feeds. (the rest comes from the buffer) If INN would be able to integrate nntplink functionality and be multithreading, this could be (in normal circumstances) be reduced to around 5 times. Inn also goes to non-responsive mode when it processes a newgroup or a rmgroup and does not accept new connections during the processing of those. This is a quite hard issue to resolve but annoys quite a lot on a busy server. > (now we just have to devise the tools... sigh!) > ;-) > I guess that depends on the system, and the number of feeds, etc... It is > my (current) general policy to try to scale news servers such that there are > plenty of free cycles - and since many feeds are UUCP, they're already > being compressed by the CPU. :-) > That's not true around here. Very few of the feeds are UUCP and most likely the UUCP feeds are quite to very small. The article load is so huge that you don't want to spend the money on transmitting them over dialups. (because around here you pay for local calls) Pete