INN FAQ How do I use nntplink with INN?

INN FAQ Part 4

NOTE: The maintainers of the INN FAQ stopped publishing in December 1997.
An important update to this topic is provided by Mib Software in the Usenet RKT for Subscribers.

Subject: (4.20) How do I use nntplink with INN?
First of all, I don't personally recommend using this program. I feel that it is a gimmick. However, if you decide to join the INN Instant Party, I suggest that you first run the feed using nntpsend (included with INN) FOR AT LEAST A WEEK. Once you are confident that functioning properly, consider to switching to nntplink ONLY IF: 0. You have read all documentation about innd and nntplink 1. You have more than 3 outgoing feeds. 2. You have gobs and gobs of real memory. 3. Your OS has a superior mmap() & disk IO system (like SunOS) If you decide to switch, here's a cookbook example of an newsfeeds entry using nntplink: PLEASE make sure traditional "nntpsend"-style feeds work reliably before you switch to nntplink. netcomsv.netcom.com\ :,!junk/!ParcPlace\ :Tc,Wnm,S1024:/usr/local/news/bin/nntplink -i stdin netcomsv.netcom.com INN 1.2 users should have an explicit S value (i.e. S1024 or S16384). Without it innd 1.2 can choke and lose data if the receiver is jammed. (fixed in INN 1.3). The latest version of nntplink is available from ftp://ftp.math.ohio-state.edu/pub/nntplink/3.3pl2.tar.gz (3.3 is still in beta testing) Ian Phillipps <ian@dial.pipex.com> notes some criteria for using nntplink rather than nnptsend: > (1) If you have more than one backbone feed, you can save a lot of > bandwidth, without risk, if you use nntplink (less duplication of > articles over nearly-parallel paths). > (2) More important, if you have a large number of feeds, nntplink > permits them to be fed simultaneously with the same articles. No big > deal, until you think of the what's going on in the pagedaemon and the > disk cache. > A "ps uaxr" rarely catches nntplink in the act ("D"), despite my having > 17 of them last time I counted. Our biggest outgoing newsfeed delivered > 16398 articles yesterday, using a total of 380 seconds CPU on a Sun > IPC, and no disk time :-) An additional note: when using nntplink in stdin mode it is fastest and can make use of the fact that the article might still be in disk buffers when it is to be transferred. But when the remote isn't able to keep up than innd buffers the information and gets bigger and bigger. If this happens - try using nntplink in logfile mode. ------------------------------ [Source:* INN FAQ Part 4 Archive-name: usenet/software/inn-faq/part4] [Last Changed: $Date: 1997/08/26 01:26:21 $ $Revision: 2.19 $] [Copyright: 1997 Heiko Rupp, portions by Tom Limoncelli, Rich Salz, et al.]

Subject: (4.20) How do I use nntplink with INN?

First of all, I don't personally recommend using this program. I feel
that it is a gimmick. However, if you decide to join the INN Instant
Party, I suggest that you first run the feed using nntpsend (included
with INN) FOR AT LEAST A WEEK. Once you are confident that functioning
properly, consider to switching to nntplink ONLY IF:

0. You have read all documentation about innd and nntplink
1. You have more than 3 outgoing feeds.
2. You have gobs and gobs of real memory.
3. Your OS has a superior mmap() & disk IO system (like SunOS)

If you decide to switch, here's a cookbook example of an newsfeeds
entry using nntplink:

PLEASE make sure traditional "nntpsend"-style feeds work reliably
before you switch to nntplink.

netcomsv.netcom.com\
	:*,!junk/!ParcPlace\
	:Tc,Wnm,S1024:/usr/local/news/bin/nntplink -i stdin netcomsv.netcom.com

INN 1.2 users should have an explicit S value (i.e. S1024 or S16384).
Without it innd 1.2 can choke and lose data if the receiver is jammed.
(fixed in INN 1.3).

The latest version of nntplink is available from
ftp://ftp.math.ohio-state.edu/pub/nntplink/3.3pl2.tar.gz (3.3 is still
in beta testing)

Ian Phillipps <ian@dial.pipex.com> notes some criteria for using
nntplink rather than nnptsend:

> (1) If you have more than one backbone feed, you can save a lot of
> bandwidth, without risk, if you use nntplink (less duplication of
> articles over nearly-parallel paths).

> (2) More important, if you have a large number of feeds, nntplink
> permits them to be fed simultaneously with the same articles.  No big
> deal, until you think of the what's going on in the pagedaemon and the
> disk cache.

> A "ps uaxr" rarely catches nntplink in the act ("D"), despite my having
> 17 of them last time I counted. Our biggest outgoing newsfeed delivered
> 16398 articles yesterday, using a total of 380 seconds CPU on a Sun
> IPC, and no disk time :-)

An additional note: when using nntplink in stdin mode it is fastest and
can make use of the fact that the article might still be in disk buffers
when it is to be transferred. But when the remote isn't able to keep up
than innd buffers the information and gets bigger and bigger. If this
happens - try using nntplink in logfile mode.

------------------------------

[Source: INN FAQ Part 4 Archive-name: usenet/software/inn-faq/part4]
[Last Changed: $Date: 1997/08/26 01:26:21 $ $Revision: 2.19 $]
[Copyright: 1997 Heiko Rupp, portions by Tom Limoncelli, Rich Salz, et al.]