Excessive nntp reads since today

Excessive nntp reads since today

[Tassilo Horn]

Hi all,

since I've updated Ma Gnus today, when I want to enter some nntp group
with, say, 3 unread articles, it'll start downloading the whole
internet.  Well, seriously, it'll frequently download twenty or more MB.

My `gnus-fetch-old-headers' is 'some, so it might want to fetch some
older messages to connect new articles in a thread, but not so many.  I
just entered the gmane xetex group which had 4 new articles.  The
summary showed those 4 articles + 2 old articles from yesterday (the 4
new were replies of the 2 old ones).  But when entering the group, the
"nntp read: <x> kb" message counted to more than 12.000.

I suspect this change is the culprit, so I added Wolfgang to the Cc.

,----
| commit 44f603535c63aab124e139b145fce20fff488f38
| Author: Wolfgang Jenkner <wjenkner@inode.at>
| Date:   Mon Jun 11 23:49:17 2012 +0200
| 
|     Make `A T' work when agentized
|     
|     * gnus-agent.el (gnus-agent-retrieve-headers): Recalculate the range of
|     articles when fetch-old is non-nil (bug#11370).
`----

Bye,
Tassilo

Re: Excessive nntp reads since today

[Wolfgang Jenkner]

On Tue, Jun 12 2012, Tassilo Horn wrote:

> My `gnus-fetch-old-headers' is 'some, so it might want to fetch some
> older messages to connect new articles in a thread, but not so many.  I
> just entered the gmane xetex group which had 4 new articles.  The
> summary showed those 4 articles + 2 old articles from yesterday (the 4
> new were replies of the 2 old ones).  But when entering the group, the
> "nntp read: <x> kb" message counted to more than 12.000.
>
> I suspect this change is the culprit, so I added Wolfgang to the Cc.
>
> ,----
> | commit 44f603535c63aab124e139b145fce20fff488f38
> | Author: Wolfgang Jenkner <wjenkner@inode.at>
> | Date:   Mon Jun 11 23:49:17 2012 +0200
> | 
> |     Make `A T' work when agentized
> |     
> |     * gnus-agent.el (gnus-agent-retrieve-headers): Recalculate the range of
> |     articles when fetch-old is non-nil (bug#11370).
> `----

I admit that it hadn't occurred to me to test this patch with
non-default values of gnus-fetch-old-headers, but the docstring of this
variable actually seems to match the behaviour you describe...

Wolfgang

Re: Excessive nntp reads since today

[Tassilo Horn]

Wolfgang Jenkner <wjenkner@inode.at> writes:

>> My `gnus-fetch-old-headers' is 'some, so it might want to fetch some
>> older messages to connect new articles in a thread, but not so many.
>> I just entered the gmane xetex group which had 4 new articles.  The
>> summary showed those 4 articles + 2 old articles from yesterday (the
>> 4 new were replies of the 2 old ones).  But when entering the group,
>> the "nntp read: <x> kb" message counted to more than 12.000.
>>
>> I suspect this change is the culprit, so I added Wolfgang to the Cc.
>>
>> ,----
>> | commit 44f603535c63aab124e139b145fce20fff488f38
>> | Author: Wolfgang Jenkner <wjenkner@inode.at>
>> | Date:   Mon Jun 11 23:49:17 2012 +0200
>> | 
>> |     Make `A T' work when agentized
>> |     
>> |     * gnus-agent.el (gnus-agent-retrieve-headers): Recalculate the range of
>> |     articles when fetch-old is non-nil (bug#11370).
>> `----
>
> I admit that it hadn't occurred to me to test this patch with
> non-default values of gnus-fetch-old-headers, but the docstring of this
> variable actually seems to match the behaviour you describe...

It matches the behavior in that it had to fetch 2 additional messages to
fill in gaps in lose thread branches.  But the two old messages were
from yesterday, and that's a low-traffic group with about 20 messages in
the last week.  There's no chance that this required fetching 12 MB of
header data, right?

Bye,
Tassilo

Re: Excessive nntp reads since today

[Wolfgang Jenkner]

On Tue, Jun 12 2012, Tassilo Horn wrote:

> Wolfgang Jenkner <wjenkner@inode.at> writes:
>
>>> My `gnus-fetch-old-headers' is 'some, so it might want to fetch some
>>> older messages to connect new articles in a thread, but not so many.
>>> I just entered the gmane xetex group which had 4 new articles.  The
>>> summary showed those 4 articles + 2 old articles from yesterday (the
>>> 4 new were replies of the 2 old ones).  But when entering the group,
>>> the "nntp read: <x> kb" message counted to more than 12.000.
>>>
>>> I suspect this change is the culprit, so I added Wolfgang to the Cc.
>>>
>>> ,----
>>> | commit 44f603535c63aab124e139b145fce20fff488f38
>>> | Author: Wolfgang Jenkner <wjenkner@inode.at>
>>> | Date:   Mon Jun 11 23:49:17 2012 +0200
>>> | 
>>> |     Make `A T' work when agentized
>>> |     
>>> |     * gnus-agent.el (gnus-agent-retrieve-headers): Recalculate the range of
>>> |     articles when fetch-old is non-nil (bug#11370).
>>> `----
>>
>> I admit that it hadn't occurred to me to test this patch with
>> non-default values of gnus-fetch-old-headers, but the docstring of this
>> variable actually seems to match the behaviour you describe...
>
> It matches the behavior in that it had to fetch 2 additional messages to
> fill in gaps in lose thread branches.

The docstring states that it fetches all old headers (though only some
subset of them is displayed).

> But the two old messages were from yesterday, and that's a low-traffic
> group with about 20 messages in the last week.  There's no chance that
> this required fetching 12 MB of header data, right?

Perhaps tracing (or stepping through) gnus-agent-retrieve-headers could
give a clue?

Wolfgang

Re: Excessive nntp reads since today

[Wolfgang Jenkner]

> The docstring states that it fetches all old headers (though only some
> subset of them is displayed).

> On Tue, Jun 12 2012, Tassilo Horn wrote:
>> But the two old messages were from yesterday, and that's a low-traffic
>> group with about 20 messages in the last week.  There's no chance that
>> this required fetching 12 MB of header data, right?

Actually, that's the right order of magnitude for fetching all old
headers.  Just for the record: In a clean environment, as a user with no
Gnus related files at $HOME, and with an emacs without the patch,
subscribe to, and enter gmane.comp.tex.xetex like this

env NNTPSERVER=news.gmane.org emacs -Q -nw

ESC x g n u s RET
S s g m a n e . c o m p . t e x . x e t e x RET g RET RET

Gnus retrieves about 8M header data (look at the size of the " *nntpd*"
buffer).

Wolfgang

Re: Excessive nntp reads since today

[Tassilo Horn]

Wolfgang Jenkner <wjenkner@inode.at> writes:

>> It matches the behavior in that it had to fetch 2 additional messages
>> to fill in gaps in lose thread branches.
>
> The docstring states that it fetches all old headers (though only some
> subset of them is displayed).

You are right.  But speaking from experience it didn't do so, yet the
effect of connecting loose threads with old read articles somehow seemed
to work.

Ok, now I've edebugged the function as you suggested and checked what's
going on.  The difference between now and then is that now all headers
of a group are fetched once and put into the .overview (NOV) files.
Then they are cached and entering a group (even with 'some) is fast
again.

So basically, before uncached-articles was always the list of unread
articles, now it is (set-difference all-articles articles-in-overview).

      (if (setq uncached-articles (gnus-agent-uncached-articles articles group
                                                                t))
          (progn
            ;; Populate nntp-server-buffer with uncached headers
            (set-buffer nntp-server-buffer)
            (erase-buffer)

The reason that I get those excessive nntp reads (only once for each
group) is that my overview files didn't start with article 1, because
when subscribing to a new group, I restricted fetching by entering it
with, say, C-u 1000 RET and then catching up.

So to conclude:

  - Your patch is correct with respect to the docs

  - Your patch is bad, because now you can't use 'some for
    `gnus-fetch-old-headers' unless you have a super-fast internet
    connection.  (Several gmane groups have millions of messages which
    on first entering will all be downloaded.  No way to restrict that
    with a prefix arg as I always did.  Also, you end up with huge
    .overview files, which slow down Gnus' operations quite a bit.)

  - The old and buggy 'some semantics of `gnus-fetch-old-headers' were
    exactly what I want.  I.e., I want Gnus to *fetch* only new
    messages, but it should also *display* summary lines of old messages
    to fill loose threads in case those can be determined from the
    overview.

Now what?  Possibly `gnus-fetch-old-headers' should be split into two
variables to entangle fetching from displaying?  That'd be pretty bad
with respect to backwards compatibility...

Or how about allowing values like '(some . 100) meaning fetch at most
100 old headers and display old articles where needed to fill loose
threads?

Bye,
Tassilo

Re: Excessive nntp reads since today

[Wolfgang Jenkner]

On Tue, Jun 12 2012, Tassilo Horn wrote:

>   - The old and buggy 'some semantics of `gnus-fetch-old-headers' were
>     exactly what I want.  I.e., I want Gnus to *fetch* only new
>     messages, but it should also *display* summary lines of old messages
>     to fill loose threads in case those can be determined from the
>     overview.

IIUC, the summary would consist of new headers and some subset of the
headers cached by the agent.  I think this is a problem because the
agent cache seems to be designed to be transparently used, so that you
have always the illusion of talking directly to the server.  When the
agent is plugged, that is.  However, when the agent is unplugged, the
agent is your server, in some sense.  So I think you can have what you
want in the following clean way:

Get new articles, fetch them with the agent, unplug, enter a group.

g J s J j . RET

For this to work, it seems necessary to set gnus-fetch-old-headers to
t instead of some (but I might have wrong expectations or misunderstand
something here, and, obviously, I haven't tested this very extensively).

Wolfgang

Re: Excessive nntp reads since today

[Tassilo Horn]

Wolfgang Jenkner <wjenkner@inode.at> writes:

Hi Wolfgang,

>>   - The old and buggy 'some semantics of `gnus-fetch-old-headers'
>>     were exactly what I want.  I.e., I want Gnus to *fetch* only new
>>     messages, but it should also *display* summary lines of old
>>     messages to fill loose threads in case those can be determined from
>>     the overview.
>
> IIUC, the summary would consist of new headers and some subset of the
> headers cached by the agent.

Yes, exactly.

> I think this is a problem because the agent cache seems to be designed
> to be transparently used, so that you have always the illusion of
> talking directly to the server.  When the agent is plugged, that is.
> However, when the agent is unplugged, the agent is your server, in
> some sense.  So I think you can have what you want in the following
> clean way:
>
> Get new articles, fetch them with the agent, unplug, enter a group.
>
> g J s J j . RET

Yes, that would probably work.  However, that would be extremely
inconvenient.  And as soon as I forget to unplug the agent when entering
a group, the agent would see that my .overview files start with article
382832 instead of 1 and start downloading the headers of the old 382831
ones.  That's simply not feasible for large groups, e.g., all the emacs
and gnus groups on gmane which are never expired and thus contain
millions of articles.

> For this to work, it seems necessary to set gnus-fetch-old-headers to
> t instead of some (but I might have wrong expectations or
> misunderstand something here, and, obviously, I haven't tested this
> very extensively).

I think t and 'some are the same with respect to the agent.  And it gets
the value only as parameter but never accesses the variable directly.

Lars, what do you think?

IMHO, the best cure is to remove `gnus-fetch-old-headers' altogether and
add a `gnus-summary-show-old-articles' variable that only deals with the
summary display stuff.  Values would be t (show all), nil (only unread),
or 'some (some old to connect lose threads), or a number (show unread +
N old).

How many old articles are fetched at most in the `A T' case is handled
by `gnus-refer-thread-limit' anyway.  I'm not sure if C-u 1000 RET on a
group would still fetch (- 1000 |cached| |unread|) old articles,
though...

The only difference to the current state of affairs would be that t or
'some for `gnus-summary-show-old-articles' would only show already
fetched articles.  Thus, when subscribing to some new group, catching
up, getting new news again, entering the group, you'd possibly have
unconnected articles initially, but that would go away over time when
the overview files get filled unless very old messages are referenced.
Of course, all of this requires a nil `gnus-nov-is-evil', but that has
always been the case, right?

And I think it would be equivalent to the old behavior before your
commit, except that the documentation and the name of the variable would
actually match the behavior. :-)

Bye,
Tassilo

Re: Excessive nntp reads since today

[Wolfgang Jenkner]

On Wed, Jun 13 2012, Tassilo Horn wrote:

> The only difference to the current state of affairs would be that t or
> 'some for `gnus-summary-show-old-articles' would only show already
> fetched articles.

Well, as I said, when plugged the agent cache is, IMHO, designed to be
transparent with respect to the server.

This implies that the summary should be the same as if the agent were
non used at all.

Only when the agent is unplugged it effectively is the server and you
may expose its internal state in the summary.

Of course, these points may be less important than I think them to
be :-)

Wolfgang

Re: Excessive nntp reads since today

[Tassilo Horn]

Wolfgang Jenkner <wjenkner@inode.at> writes:

Hi Wolfgang,

>> The only difference to the current state of affairs would be that t
>> or 'some for `gnus-summary-show-old-articles' would only show already
>> fetched articles.
>
> Well, as I said, when plugged the agent cache is, IMHO, designed to be
> transparent with respect to the server.
>
> This implies that the summary should be the same as if the agent were
> non used at all.
>
> Only when the agent is unplugged it effectively is the server and you
> may expose its internal state in the summary.
>
> Of course, these points may be less important than I think them to
> be :-)

Yes, I think you have a bit too high expectations here.  I mean, the
real server is some reasonably well equipped machine, but Gnus possibly
runs on some small netbook with few RAM and disk space.  Thus there
shouldn't be a need to have subscribed groups to be complete (header)
mirrors of all available messages on the server.

For example, gmane.emacs.help currently has an 26MB .overview here, and
gmane.emacs.devel has nearly twice as many messages thus probably it
would have a 50MB overview.  And that's only for parts of the message
headers.

And finally, nobody has ever complained about the agent not fetching all
old message headers.

Bye,
Tassilo

Re: Excessive nntp reads since today

[Wolfgang Jenkner]

On Wed, Jun 13 2012, Tassilo Horn wrote:

> Wolfgang Jenkner <wjenkner@inode.at> writes:
>
>> Well, as I said, when plugged the agent cache is, IMHO, designed to be
>> transparent with respect to the server.
>>
>> This implies that the summary should be the same as if the agent were
>> non used at all.
>>
>> Only when the agent is unplugged it effectively is the server and you
>> may expose its internal state in the summary.

> Thus there shouldn't be a need to have subscribed groups to be
> complete (header) mirrors of all available messages on the server.

Of course not.  Nobody said that the agent should cache all headers.

Quite the contrary, actually :-)

Wolfgang

Re: Excessive nntp reads since today

[Tassilo Horn]

Wolfgang Jenkner <wjenkner@inode.at> writes:

>>> Well, as I said, when plugged the agent cache is, IMHO, designed to
>>> be transparent with respect to the server.
>>>
>>> This implies that the summary should be the same as if the agent
>>> were non used at all.
>>>
>>> Only when the agent is unplugged it effectively is the server and
>>> you may expose its internal state in the summary.
>
>> Thus there shouldn't be a need to have subscribed groups to be
>> complete (header) mirrors of all available messages on the server.
>
> Of course not.  Nobody said that the agent should cache all headers.
>
> Quite the contrary, actually :-)

But that's actually the effect of your patch.  If the fetch-old argument
is something not numerical, it'll fetch all headers starting with
article number 1 and cache them in the .overview.

Bye,
Tassilo

Re: Excessive nntp reads since today

[Wolfgang Jenkner]

On Sat, Jun 16 2012, Tassilo Horn wrote:

> Wolfgang Jenkner <wjenkner@inode.at> writes:
>
>>>> Well, as I said, when plugged the agent cache is, IMHO, designed to
>>>> be transparent with respect to the server.
>>>>
>>>> This implies that the summary should be the same as if the agent
>>>> were non used at all.
>>>>
>>>> Only when the agent is unplugged it effectively is the server and
>>>> you may expose its internal state in the summary.
>>
>>> Thus there shouldn't be a need to have subscribed groups to be
>>> complete (header) mirrors of all available messages on the server.
>>
>> Of course not.  Nobody said that the agent should cache all headers.
>>
>> Quite the contrary, actually :-)
>
> But that's actually the effect of your patch.  If the fetch-old argument
> is something not numerical, it'll fetch all headers starting with
> article number 1 and cache them in the .overview.

And that's consistent with the principles I humbly think the agent is
based upon and which I stated above.  Now, it's quite possible that
these principles exist only in my imagination or that the convenience of
making an exception and handling the case fetch-old=some specially would
outweigh the resulting conceptual inconsistency.

Please note, however, that not only the "bad new" behaviour has been
documented since at least 2005 but also that Kevin Greiner, who rewrote
a lot of the agent stuff, actually significantly clarified the meaning
of `some' as value of gnus-fetch-old-headers on 2005-11-20 [*].

Wolfgang

[*] Here's the diff:

diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index dfc3c09..9df8131 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -63,17 +63,21 @@ it will be killed sometime later."
 
 (defcustom gnus-fetch-old-headers nil
   "*Non-nil means that Gnus will try to build threads by grabbing old headers.
-If an unread article in the group refers to an older, already read (or
-just marked as read) article, the old article will not normally be
-displayed in the Summary buffer.  If this variable is t, Gnus
-will attempt to grab the headers to the old articles, and thereby
-build complete threads.  If it has the value `some', only enough
-headers to connect otherwise loose threads will be displayed.  This
-variable can also be a number.  In that case, no more than that number
-of old headers will be fetched.  If it has the value `invisible', all
+If an unread article in the group refers to an older, already
+read (or just marked as read) article, the old article will not
+normally be displayed in the Summary buffer.  If this variable is
+t, Gnus will attempt to grab the headers to the old articles, and
+thereby build complete threads.  If it has the value `some', all
+old headers will be fetched but only enough headers to connect
+otherwise loose threads will be displayed.  This variable can
+also be a number.  In that case, no more than that number of old
+headers will be fetched.  If it has the value `invisible', all
 old headers will be fetched, but none will be displayed.
 
-The server has to support NOV for any of this to work."
+The server has to support NOV for any of this to work.
+
+This feature can seriously impact performance it ignores all
+locally cached header entries."
   :group 'gnus-thread
   :type '(choice (const :tag "off" nil)
 		 (const :tag "on" t)

Re: Excessive nntp reads since today

[Lars Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

>   - Your patch is correct with respect to the docs
>
>   - Your patch is bad, because now you can't use 'some for
>     `gnus-fetch-old-headers' unless you have a super-fast internet
>     connection. 

`some' was never meant to fetch everything -- that was what t was for.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Emacs

Re: Excessive nntp reads since today

[Tassilo Horn]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>>   - Your patch is correct with respect to the docs
>>
>>   - Your patch is bad, because now you can't use 'some for
>>     `gnus-fetch-old-headers' unless you have a super-fast internet
>>     connection. 
>
> `some' was never meant to fetch everything -- that was what t was for.

Then the docs were wrong:

,----[ C-h v gnus-fetch-old-headers RET ]
| gnus-fetch-old-headers is a variable defined in `gnus-sum.el'.
| 
| Documentation:
| [...] If it has the value `some', all old headers will be fetched but
| only enough headers to connect otherwise loose threads will be
| displayed. [...]
`----

Wolfgang fixed the implementation to reflect exactly what the docs say.
IMHO, we'd better have fixed the docs and let the implementation as it
has been.

Bye,
Tassilo

Re: Excessive nntp reads since today

[Lars Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

> Then the docs were wrong:
>
> ,----[ C-h v gnus-fetch-old-headers RET ]
> | gnus-fetch-old-headers is a variable defined in `gnus-sum.el'.
> | 
> | Documentation:
> | [...] If it has the value `some', all old headers will be fetched but
> | only enough headers to connect otherwise loose threads will be
> | displayed. [...]
> `----
>
> Wolfgang fixed the implementation to reflect exactly what the docs say.
> IMHO, we'd better have fixed the docs and let the implementation as it
> has been.

Yeah, but that's after the clarification.  :-)  They used to say:

-displayed in the Summary buffer.  If this variable is t, Gnus
-will attempt to grab the headers to the old articles, and thereby
-build complete threads.  If it has the value `some', only enough
-headers to connect otherwise loose threads will be displayed.  This
-variable can also be a number.  In that case, no more than that number
-of old headers will be fetched.  If it has the value `invisible', all

i.e., it didn't say that all headers would be fetched...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Lars Magne Ingebrigtsen

Re: Excessive nntp reads since today

[Tassilo Horn]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Then the docs were wrong:
>>
>> ,----[ C-h v gnus-fetch-old-headers RET ]
>> | gnus-fetch-old-headers is a variable defined in `gnus-sum.el'.
>> | 
>> | Documentation:
>> | [...] If it has the value `some', all old headers will be fetched but
>> | only enough headers to connect otherwise loose threads will be
>> | displayed. [...]
>> `----
>>
>> Wolfgang fixed the implementation to reflect exactly what the docs say.
>> IMHO, we'd better have fixed the docs and let the implementation as it
>> has been.
>
> Yeah, but that's after the clarification.  :-)  They used to say:
>
> -displayed in the Summary buffer.  If this variable is t, Gnus
> -will attempt to grab the headers to the old articles, and thereby
> -build complete threads.  If it has the value `some', only enough
> -headers to connect otherwise loose threads will be displayed.  This
> -variable can also be a number.  In that case, no more than that number
> -of old headers will be fetched.  If it has the value `invisible', all
>
> i.e., it didn't say that all headers would be fetched...

Oh, Wolfgang, you prankster. ;-)

So what now?  For what it's worth, I'm for reverting that commit and
clarifying the docs that 'some won't be able to fill loose threads in
case it references articles for which no headers have been fetched.  But
that's not much on an issue: over time, you'll have all headers for the
active threads, just not for very old ones.

Bye,
Tassilo

Re: Excessive nntp reads since today

[Wolfgang Jenkner]

On Wed, Sep 05 2012, Tassilo Horn wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>>> Then the docs were wrong:
>>>
>>> ,----[ C-h v gnus-fetch-old-headers RET ]
>>> | gnus-fetch-old-headers is a variable defined in `gnus-sum.el'.
>>> | 
>>> | Documentation:
>>> | [...] If it has the value `some', all old headers will be fetched but
>>> | only enough headers to connect otherwise loose threads will be
>>> | displayed. [...]
>>> `----
>>>
>>> Wolfgang fixed the implementation to reflect exactly what the docs say.
>>> IMHO, we'd better have fixed the docs and let the implementation as it
>>> has been.
>>
>> Yeah, but that's after the clarification.  :-)  They used to say:
>>
>> -displayed in the Summary buffer.  If this variable is t, Gnus
>> -will attempt to grab the headers to the old articles, and thereby
>> -build complete threads.  If it has the value `some', only enough
>> -headers to connect otherwise loose threads will be displayed.  This
>> -variable can also be a number.  In that case, no more than that number
>> -of old headers will be fetched.  If it has the value `invisible', all
>>
>> i.e., it didn't say that all headers would be fetched...
>
> Oh, Wolfgang, you prankster. ;-)

???  I think you are misunderstanding.  As I said, that clarification
was made in 2005-11-20 by Kevin Greiner.

Wolfgang

Re: Excessive nntp reads since today

[Tassilo Horn]

Wolfgang Jenkner <wjenkner@inode.at> writes:

>>>> Then the docs were wrong:
>>>>
>>>> ,----[ C-h v gnus-fetch-old-headers RET ]
>>>> | gnus-fetch-old-headers is a variable defined in `gnus-sum.el'.
>>>> | 
>>>> | Documentation:
>>>> | [...] If it has the value `some', all old headers will be fetched but
>>>> | only enough headers to connect otherwise loose threads will be
>>>> | displayed. [...]
>>>> `----
>>>>
>>>> Wolfgang fixed the implementation to reflect exactly what the docs
>>>> say.  IMHO, we'd better have fixed the docs and let the
>>>> implementation as it has been.
>>>
>>> Yeah, but that's after the clarification.  :-)  They used to say:
>>>
>>> -displayed in the Summary buffer.  If this variable is t, Gnus
>>> -will attempt to grab the headers to the old articles, and thereby
>>> -build complete threads.  If it has the value `some', only enough
>>> -headers to connect otherwise loose threads will be displayed.  This
>>> -variable can also be a number.  In that case, no more than that number
>>> -of old headers will be fetched.  If it has the value `invisible', all
>>>
>>> i.e., it didn't say that all headers would be fetched...
>>
>> Oh, Wolfgang, you prankster. ;-)
>
> ???  I think you are misunderstanding.

Indeed.

> As I said, that clarification was made in 2005-11-20 by Kevin Greiner.

Ok, ok.  My suggestion stands as-is anyway.

Bye,
Tassilo