Date: Mon, 17 Apr 1995 23:23:47 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: hsu@cs.hut.fi (Heikki Suonsivu) Cc: joerg_wunsch@uriah.heep.sax.de, gpalmer@freefall.cdrom.com, hsu@cs.hut.fi, freebsd-current@FreeBSD.org Subject: Re: mmap bugs gone yet? Message-ID: <9504180423.AA05862@brasil.moneng.mei.com> In-Reply-To: <199504180323.AA16519@cardhu.cs.hut.fi> from "Heikki Suonsivu" at Apr 18, 95 06:23:25 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Joe Greco writes: > > > With the merged VM/buffer cache, i doubt it will buy too much to mmap > > > the files at all. > > > > This was not true on my Sun 3/60. I never investigated to find out why, > > however. > > It would seem to be writing the history file every 10 articles if you use > ACT_READ option. I don't know if it writes all of it or just the modified > parts. You can tune innd to write less often, but it doesn't seem to help > much. We are in big trouble soon if the NNTP protocol isn't quickly Does ACT_READ actually affect the history file mechanism? My memory suggests that the history code is always handled with a write, and the only thing that you can affect is the dbzincore()... I could go look at the code, I suppose.... not fun at 1200 baud, though, so I won't. > revised, and we probably need a fully rewritten news system in less than a > year... And here I thought that's what INN was. :-) 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. 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. 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. Of course, this doesn't buy as much under FreeBSD as it would under Solaris. That's not saying anything bad about FreeBSD, by the way, but I do believe that there is something inherently threadable about news. Providing NNTP extensions to do NNTP command stacking and/or simple batch/compression on the fly (for slow links) would be the next step. ... 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?9504180423.AA05862>