+The default is
+.B twice
+.IR per-conn-max .
+.TP
+.BI \-\-feedfile-flush-size= bytes
+Specifies that innduct should flush the feed and start a new feedfile
+when the existing feedfile size exceeds
+.IR bytes ;
+the effect is that the innduct will try to avoid the various
+batchfiles growing much beyond this size. The default is
+.BR 100000 .
+.TP
+.BI \-\-period-interval= PERIOD-INTERVAL
+Specifies wakup interval and period granularity.
+innduct wakes up every
+.I PERIOD-INTERVAL
+to do various housekeeping checks. Also, many of the timeout and
+rescan intervals (those specified in this manual as
+.IR PERIOD )
+are rounded up to the next multiple of
+.IR PERIOD-INTERVAL .
+The default is
+.BR 30s .
+.TP
+.BI \-\-connection-timeout= TIME
+How long to allow for a connection setup attempt before giving up.
+The default is
+.BR 200s .
+.TP
+.BI \-\-stuck-flush-timeout= TIME
+How long to wait for innd to respond to a flush request before giving
+up. The default is
+.BR 100s .
+.TP
+.BI \-\-feedfile-poll= TIME
+How often to poll the feedfile for new articles written by innd
+if file monitoring
+.RI ( inotify
+or equivalent) is not available. (When file monitoring is available,
+there is no need for periodic checks and we wake immediately up
+whenever the feedfile changes.)
+The default is
+.BR 5s .
+.TP
+.BI \-\-no-check-proportion= PERCENT
+If the moving average of the proportion of articles being accepted
+(rather than declined) by the peer exceeds this value, innduct uses
+"no check mode" - ie it just sends the peer the articles with TAKETHIS
+rather than checking first with CHECK whether the article is wanted.
+This only affects streaming connections. The default is
+.B 95
+(ie, 95%).
+.TP
+.BI \-\-no-check-response-time= ARTICLES
+The moving average mentioned above is an alpha-smoothed value with a
+half-life of
+.IR ARTICLES .
+The default is
+.BR 100 .
+.TP
+.BI \-\-reconnect-interval= RECONNECT-PERIOD
+Limits initiation of new connections to one each
+.IR RECONNECT-PERIOD .
+This applies to reconnections if the peer has been down, and also to
+ramping up the number of connections we are using after startup or in
+response to an article flood. The default is
+.BR 1000s .
+.TP
+.BI \-\-flush-retry-interval= PERIOD
+If our attempt to flush the feed failed (usually this will be because
+innd is not running), try again after
+.IR PERIOD .
+The default is
+.BR 1000s .
+.TP
+.BI \-\-earliest-deferred-retry= PERIOD
+When the peer responds to our offer of an article with a 431 or 436
+NNTP response code, indicating that the article has already been
+offered to it by another of its peers, and that we should try again,
+we wait at least
+.IR PERIOD .
+before offering the article again. The default is
+.BR 100s .
+.TP
+.BI \-\-backlog-rescan-interval= BACKLOG-SCAN-PERIOD
+We scan the directory containing
+.I feedfile
+for backlog files at least every
+.IR BACKLOG-SCAN-PERIOD ,
+in case the administrator has manually dropped in a file there for
+processing.
+The default is
+.BR 300s .
+.TP
+.BI \-\-max-flush-interval= PERIOD
+We flush the feed and start a new feedfile at least every
+.IR PERIOD
+even if the current instance of the feedfile has not reached the size
+threshold.
+The default is
+.BR 100000s .
+.TP
+.BI \-\-flush-finish-timeout= FLUSH-FINISH-PERIOD
+If we flushed
+.IR FLUSH-FINISH-PERIOD
+ago, and are still trying to finish processing articles that were
+written to the old feed file, we forcibly and violently make sure that
+we can finish the old feed file: we abandon and defer all the work,
+which includes unceremoniously dropping any connections on which
+we've sent some of those articles but not yet had replies, as they're
+probably stuck somehow. The default is
+.BR 2000s .
+.TP
+.BI \-\-idle-timeout= PERIOD
+Connections which have had no activity for
+.IR PERIOD
+will be closed. This includes connections where we have sent commands
+or articles but have not yet had the responses, so this same value
+doubles as the timeout after which we conclude that the peer is
+unresponsive or the connection has become broken.
+The default is
+.BR 1000s .
+.TP
+.BI \-\-low-volume-thresh= "WIN-THRESH " \-\-low-volume-window= "PERIOD "
+If innduct has only one connection to the peer, and has processed
+fewer than
+.I WIN-THRESH
+articles in the last
+.I PERIOD
+and also no articles in the last
+.IR PERIOD-INTERVAL
+it will close the connection quickly. That is, innduct switches to a
+mode where it opens a connection for each article (or, perhaps, each
+handful of articles arriving together).
+The default is to close if fewer than
+.BR 3
+articles in the last
+.BR 1000s .
+.TP
+.BI \-\-max-bad-input-data-ratio= PERCENT
+We tolerate up to this proportion of badly-formatted lines in the
+feedfile and other input files. Every badly-formatted line is logged,
+but if there are too many we conclude that the corruption to our
+on-disk data is too severe, and crash; to successfully restart,
+administrator intervention will be required. This avoids flooding the
+logs with warnings and also arranges to abort earlyish if an attempt
+is made to process a file in the wrong format. We need to tolerate a
+small proportion of broken lines, if for no other reason than that a
+crash might leave a half-blanked-out entry. The default is
+.BR 1
+(ie, 1%).
+.TP
+.BI \-\-max-bad-input-data-init= LINES
+Additionally, we tolerate this number of additional badly-formatted
+lines, so that if the badly-formatted lines are a few but at the start
+of the file, we don't crash immediately.
+The default is
+.BR 30
+(which would suffice to ignore one whole corrupt 4096-byte disk block
+filled with random data, or one corrupt 1024-byte disk block filled
+with an inappropriate text file with a mean line length of at least
+35).
+.SH INNDUCT VS INNFEED/NNTPSEND/INNXMIT
+.TP
+.B innfeed
+does roughly the same thing as innduct. However, the way it receives
+information from innd can result in articles being lost (not offered
+to peers) if innfeed crashes for any reason. This is an inherent
+defect in the innd channel feed protocol. innduct uses a file feed,
+constantly "tailing" the feed file, and where implemented uses
+.BR inotify (2)
+to reduce the latency which would come from having to constantly poll
+the feed file. innduct is much smaller and simpler, at <4kloc to
+innfeed's 25kloc. innfeed needs a separate helper script or similar
+infrastructure (of which there is an example in its manpage), whereas
+innduct can be run directly and doesn't need help from shell scripts.
+However, innfeed is capable of feeding multiple peers from a single
+innfeed instance, whereas each innduct process handles exactly one
+peer.
+.TP
+.B nntpsend
+processes feed files in batch mode. That is, you have to periodically
+invoke nntpsend, and when you do, the feed is flushed and articles
+which arrived before the flush are sent to the peer. This introduces
+a batching delay, and also means that the NNTP connection to the peer
+needs to be remade at each batch. nntpsend (which uses innxmit)
+cannot make use of multiple connections to a single peer site.
+However, nntpsend automatically find which sites need feeding by
+looking in
+.IR pathoutgoing ,
+whereas the administrator needs to arrange to invoke innduct
+separately for each peer.
+.TP
+.B innxmit
+is the actual NNTP feeder program used by nntpsend.