Date: Wed, 19 Apr 1995 14:56:08 +0300 From: Heikki Suonsivu <hsu@cs.hut.fi> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: hsu@cs.hut.fi (Heikki Suonsivu), joerg_wunsch@uriah.heep.sax.de, gpalmer@freefall.cdrom.com, freebsd-current@FreeBSD.org Subject: Re: mmap bugs gone yet? Message-ID: <199504191156.AA20596@cardhu.cs.hut.fi> In-Reply-To: <9504180423.AA05862@brasil.moneng.mei.com> References: <199504180323.AA16519@cardhu.cs.hut.fi> <9504180423.AA05862@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Joe Greco writes:
> > 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
> Does ACT_READ actually affect the history file mechanism? My memory
No, sorry, I was intending to say active file.
> 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.
Bandwidth isn't really a problem for anyone else but people who wish to
transfer full newsfeed on modems.
> 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?)
> 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.
--
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504191156.AA20596>