Date: Wed, 19 Apr 1995 08:11:17 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: hsu@cs.hut.fi (Heikki Suonsivu) Cc: hsu@cs.hut.fi, joerg_wunsch@uriah.heep.sax.de, gpalmer@freefall.cdrom.com, freebsd-current@FreeBSD.org Subject: Re: mmap bugs gone yet? Message-ID: <9504191311.AA08515@brasil.moneng.mei.com> In-Reply-To: <199504191156.AA20596@cardhu.cs.hut.fi> from "Heikki Suonsivu" at Apr 19, 95 02:56:08 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Joe Greco writes: > > What NNTP failing in particular are we discussing, anyways? NNTP throughput > > rates due to turnaround times? Bandwidth requirements to send complete > > uncompressed text chunks? I am not yet aware of any inherent limits to the > > technology. > > All of these. inn is completely single-threaded system and NNTP is > completely synchronous protocol (IHAVE-REPLY-Article-REPLY-...). As it is > running on top of TCP, it takes at least 4 turnarounds for each article, > and innd is not receiving anything else when it is doing a history check, > for example. Yes, perhaps this aspect could be threaded, but you are not helping the transaction turnaround time any (i.e. if it takes .2 seconds to complete one whole IHAVE-REPLY-Art-REPLY cycle, you haven't increased that). > Bandwidth isn't really a problem for anyone else but people who wish to > transfer full newsfeed on modems. You haven't tried running a full feed over 56K lately? It does not work unless you are running parallel nntplinks. And there, it just *barely* works (i.e. sucks up 94% of the bandwidth currently, 100% by summer). > > Sure, those of us running major backbone sites are using things > > such as parallel nntplink processes to help circumvent problems inherent > > when you're trying to push gigabytes of news daily, but I don't see this as > > a deficiency in the protocol per se. > > It doesn't help, as innd is single-threaded, it won't serve multiple > requests concurrently. We tried double feeding, and as one might guess, it > degraded the performance. Mmapping the active file would help for a couple > of months, but probably not longer than that. I'll try it (as the mmap > bugs seem to be fixed now?) I don't think mmap'ing the active file will have much of anything to do with that problem. You're not dealing with the active file. What you would *like* to do is to have your history in memory. :-) What sort of target machine are we discussing, anyways? I run one system with a 90%++ rejection rate and I do not notice anything that I would consider "performance degradation" associated with it. > > What I _would_ like to see is a new generation of threaded news tools - > > perhaps (most ideally) rolling the functionality of nntplink into INN, and > > providing a mechanism that allows INN to open several concurrent NNTP > > connections to a peer, multiplexed such that it appears to INN as a single > > feed. > > Would seem a complicated solution to me, when one connection with an > efficient protocol and multithreaded news server would solve the problem? > multithreading innd probably is the biggest job, just making NNTP do > windowing would be simple. If you want to push Son-of-RFC-whatever, go for it. I do not think that the changes you are proposing to innd are feasible. INN enforces coherency within the news system by virtue of its singlethreadedness. You can multithread it, perhaps, by maintaining the singlethreadedness on a per-resource basis (i.e. thread for history access, thread for active file access) but I do not know how much it'll buy you. And I simply hate to reinvent the whole news system, when I can simply write a single utility that would deal quite effectively with the one problem that I do see. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504191311.AA08515>