article propagation delay

Wed Mar 13 01:54:56 UTC 2002


>Sounds like this "slow-but-fast" peer has been tweaked to enhance its freenix
>rating :-)  I'd suspected some sites of having been modified to convey checks
>with high priority to peers and defer the actual transmission of the article.

Another possibility would be use of a feed program that attempts to do a 
"large" number of checks. For example, note that Cyclone has the "MaxChecks"
parameter. They describe it as:

    "Upper limit on the number of NNTP "check" messages that can be sent 
    before waiting for a response from this outgoing feed. This value can 
    be set as high as 125. Cyclone will automatically regulate the actual 
    number of "check" messages sent to maximize article transfer rates. 
    The "DefaultMaxChecks" directive in the cyclone.conf file provides a 
    default value for this directive."

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

>I'd suspected some ware of even conveying checks without having actually
>received the article in question which is bad imho.  

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...

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...

>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. 

>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". 



More information about the inn-workers mailing list