article propagation delay

[Pavel V. Knyazev]

Hi.

> If you figure typical article reception rates of ~15 articles/second,
> 125 outstanding checks could be an order of 10 second check window...

What time it usually tooks to the small article to be offered and
transmitted to another site? Consider the sites are working on a
fat fast line with ~50 ms RTT.

> Another possibility might be the scenario whereby a site checks, but
> while it is waiting for the response, the article gets "cancelled out from
> under it" (so to speak). I don't think articles with pending checks are
> locked to prevent cancellation...

We may refuse all cancels as a workaround.
Howver, they may not ask if we want to receive this cancel :-)

> Likewise, consider a situation where a backlogging peer consistently
fills/
> overflow their permitted backlog... If a feeder has a small buffer for a
> downstream feed, I could also see that resulting in scenarios where
offered
> articles aren't available following a successful check...

As my point of view, a good site won't even offer an article
if backlogging occurs. Otherwise it will send a lot of duplicates.

> >It might be nice to have an option in incoming.conf to disallow a
particular
> >incoming peer from being able to put an entry in the precommit cache.
>
> That would be cool, indeed. Likewise, something to limit the number of
> outstanding checks per particular incoming peer.

How could we ask INN developers to realize all these new features?

> >might also be nice to have some statistic collection on the precommit
cache
> >to see the percentage of precommit wins per peer and the average delay
between
> >the check and the complete reception of the article (per peer).
>
> And to add to the wish list, I'd love instrumentation on incoming peer
> treatment of "defers" (for example, innfeed has the option to
drop-deferred
> articles) -- I'd love to know which sites appear to be doing that (e.g.,
> which incoming sites *never* retry after getting a defer).
>
> Flip side of that would be the ability for the receiving peer to control
> which incoming peers are handed defers rather than refusals -- there may
be
> some sites that you want to tell "don't bother retrying".

That's very easy to check if a site does retransmit retries.
First, you need to turn-on deferral responces.

surnet-out.news.clara.net
    seconds: 59956          duplicates: 8553        ip address: 195.8.68.195
    offered: 192644      uw newsgroups: 55         active cxns: 5
   accepted: 2885     uw distributions: 548      sleeping cxns: 0
    refused: 277690         unapproved: 0       want streaming: Yes
   rejected: 13898            filtered: 0         is streaming: Yes
       size: 6.2Mb           bad sites: 0       duplicate size: 14.4Mb
  Protocol:
      Ihave: 0      SendIt[335]: 0         Got[435]: 0      Deferred[436]: 0
      Check: 294519 SendIt[238]: 16783     Got[438]: 157356 Deferred[431]:
101828
   Takethis: 16783      Ok[239]: 2885    Error[439]: 0
   Cancelrejects:    Ihave[435]: 0       Check[438]: 18506

(consider clara does not resend deferred messgaes)

We see that inn reports that there were 192644 articles offered,
however there 294519 checks were made (and 101828 articles
were deferred). Just calculate 192644 plus 101828 ...

When a particular site DOES retransmit articles you'll see
that the difference between "checks" and "offered" will be
much less that the number of deferred articles as inn reports.

--
Pavel

ps. this is a real run-time statistic ...