Need help: Where to debug "Server closed connection" opening Gmane NNTP groups with many unread articles on Windows?

[Steinar Bang]

Since May last year, or thereabouts, I have seen a problem with git Gnus
on Win32, when opening Gmane NNTP groups with large number of unread
articles.

I plan to debug this now to find out where it actually breaks, but need
some pointers:
Where should I set a breakpoint?
What values should I look for?

What happens, is that I see the text "Server closed connection" in the
minibuffer, and Gnus gives up entering the group.

The Messages buffer displays the following two lines:
gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated. [2 times]
apply: Server closed connection

I am running emacs 24.3.1 with gnutls and other DLLs from ezwinports
http://sourceforge.net/projects/ezwinports/files/
(the DLLs were dropped into the emacs bin directory)

I see this behaviour both on Windows 7 Enterprise, and on Windows 8.1
with identical setups (git Gnus, emacs 24.3 and ezwinports DLLs).

I do not see this behaviour on debian testing/unstable on an old P4
machine.

All of the groups that fail are on news.gmane.org.

I have no problems opening news.eclipse.org groups with large number of
articles from Gnus on Windows.

I don't know what the difference are with the two servers, but I can
guess at stuff line:
- Gmane does TLS upgrade of the connection
- Required auth on news.eclipse.org
- Network distance:
- gmane: 11 hops according to traceroute
- 4 hops inside my ISP, 4 hops inside netfonds
- news.eclipse.org: 15 hops according to traceroute
- 4 hops inside my ISP, possibly 2 hops inside eclipse.org
- Different timeout on connections on the servers?

[Lars Ingebrigtsen]

Post by Steinar Bang
Since May last year, or thereabouts, I have seen a problem with git Gnus
on Win32, when opening Gmane NNTP groups with large number of unread
articles.
I plan to debug this now to find out where it actually breaks, but need
Where should I set a breakpoint?

You could perhaps try `debug-on-message'...

[Steinar Bang]

Post by Lars Ingebrigtsen

Post by Steinar Bang
Since May last year, or thereabouts, I have seen a problem with git Gnus
on Win32, when opening Gmane NNTP groups with large number of unread
articles.
I plan to debug this now to find out where it actually breaks, but need
Where should I set a breakpoint?

You could perhaps try `debug-on-message'...

It seems to be fixed now, with a new emacs 24 (24.4 vs. 24.3) and a new
gnutls.dll from ezwinports.
http://thread.gmane.org/gmane.emacs.help/101746/focus=101786

I reported something related to this as bug#16784
http://comments.gmane.org/gmane.emacs.bugs/85764
that you reported as fixed with some new security stuff that will be a
part of emacs 25 (I think...?).
http://permalink.gmane.org/gmane.emacs.bugs/97030

[Steinar Bang]

Post by Steinar Bang

Post by Lars Ingebrigtsen

Post by Steinar Bang
Since May last year, or thereabouts, I have seen a problem with git
Gnus on Win32, when opening Gmane NNTP groups with large number of
unread articles.
I plan to debug this now to find out where it actually breaks, but need
Where should I set a breakpoint?

You could perhaps try `debug-on-message'...

It seems to be fixed now, with a new emacs 24 (24.4 vs. 24.3) and a new
gnutls.dll from ezwinports.

It wasn't fixed at all. The issue is still present, and as annoying as
always.

The problem only occurs on news.gmane.org, I'm guessing because its TLS
upgrade fails in some mysterious way.

This was done on:
Windows 8.1
GNU Emacs 24.4.1 (i686-pc-mingw32) of 2014-10-24 on LEG570
gnutls-3.3.11-w32-bin from ezwinports

In scratch I evaluated:
(setq debug-on-message ".*fatal error: The TLS connection was non-properly terminated.*")


Then I tried entering a gmane group and hit the following stack trace:

Debugger entered--Lisp error: "gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated."
accept-process-output(#<process nntpd<1>> 1 0)
nnheader-accept-process-output(#<process nntpd<1>>)
nntp-accept-process-output(#<process nntpd<1>>)
nntp-accept-response()
nntp-send-command-nodelete(nil "XOVER" "189572-189572")
nntp-send-xover-command(189572 189572)
nntp-retrieve-headers-with-xover((189569 189570 189571 189572 189573 189574 189575 189576 189577 189578 189579 189580 189581 189582 189583 189584 189585 189586 189587 189588 189589 189590 189591 189592 189593 189594 189595 189596 189597 189598 189599 189600 189601 189602 189603 189604 189605 189606 189607 189608 189609 189610 189611 189612 189613 189614 189615 189616 189617 189618 ...) nil)
#[nil "r\306!q\210\307 \210 \204\n\204\310\f\"\203\311\202\243G\312\211e\306!\313\31489:;<=\211A\242\211\203h\314\315\247\203L\316!\202MD>?@\204`A\204`\317!\210\320\321>\322#BCDC;\203z\323C!\202|C\314\211EFCGG\203\261G\211AG\242\211E\203\261CE\211A@\262=\203\206***@F\314\211G\204\213F\205\324\324F!\325>\203\304F\202\324\326\327F!!\210\330ED\"D\314-\211F\205\337\327F!\211C\205\354rCq\210`)HF\203\334BIJ?@\314KL?CMNBCCDC;\203 \323C!\202\"C\314\211EFCGG\203WG\211AG\242\211E\203WCE\211A@\262=\203,***@F\314\211G\2041F\205z\324F!\325>\203jF\202z\326\327F!!\210\330ED\"D\314-\206\202\331C!\211F\203\2408\204\231@\204\231\317\327F!!\210\332\333\334\217\202\246\335\336\337N#.?\204\342O\204\342PQ>\204\342\340 \210rCq\210Hb\210\341\342B!!\203\330H\343y\210\344 |\210)\202\342\335\336\345I#.\210<T<\203\370\346<R\246!\2035\340 \2109q\210:b\210\314f\347=\203\350\351\314\313#\2037\341\352!\203,\343y\210\202\341\353!\2037\354\355\314\313#\2037`:;T;\202;<W\2035S\247\203b=SV\203b\346;\356\246!\203b\357\360\361;\362_=\245#\210\340 \210\202\373S\247\203{=SV\203{\357\360\363\"\210\364 \210\365 \210ed{Trq\210\307 \210U\203\231\366T!\202\233Tc\210eb\210.\n\367)\207" [nntp-server-buffer gnus-nov-is-evil nntp-nov-is-evil articles fetch-old article nntp-find-connection-buffer erase-buffer nntp-retrieve-headers-with-xover nov 0 t nil "HEAD" int-to-string nntp-erase-buffer mapconcat identity " " get-buffer process-status (open run) nntp-kill-buffer process-buffer delq nntp-open-connection err (byte-code "\203* \306 \n\203\307\n!\210\310 \n1P\"\210\311 !\312>\206(\313\314!*\2102\315=\2033\316\2072\203K3\203K\317 3452%\210\316\2073\203Q 345\3206543r\321 !q\210eb\210`f\322>\203w\323\324!\203\271\311 !\325>\203\271\323\326!\203\214\327 !\210\202\257\323\330!\203\242\331\332\333\334\335N#\210\336\334\320\"\210\202\257\323\337!\203\257`\340y\210`|\210\341 !\210eb\210\202j\323\342!\203\306\343 \210\320\202F\311 !\344>\204\324\313\314!\202Fdb\210e\32078\34538\316#\204\370\341 !\210d\346Ze]8db\210\202\335\347\350!7r9q\2107:+\3515?!\2106\204Er4q\210db\210;\203/r\321 !q\210\352\353 !)c\210\2027\354\321 !\320\211#\210<\203D\320<\355\356\357\"\210)\3166\204N\360 \210.\207\316\207" [command process string nntp-last-command-time nntp-last-command nntp-record-commands current-time nntp-record-command process-send-string process-status (open run) nntp-report "Server closed connection" ignore t nntp-async-wait nil process-buffer (50 51 52 53) looking-at "48[02]" (open run) "480" nntp-handle-authinfo "482" nnheader-report nntp "%s" nntp-authinfo-rejected error-message signal "^.*\n" 1 nntp-accept-process-output "[45]" nntp-snarf-error-message (open run) re-search-backward 1000 match-string 0 nntp-decode-text mm-string-to-multibyte buffer-string insert-buffer-substring nnheader-message 5 "" erase-buffer nntp-end-of-line ...] 6) ((nntp-authinfo-rejected (byte-code "\301\302A\"\207" [err signal nntp-authinfo-rejected] 3)) (error (byte-code "\302\303\304 $\207" [address err nnheader-report nntp "Couldn't open connection to %s: %s"] 5)) (quit (byte-code "\300\301!\210\302\303\304\"\210\304\207" [message "Quit retrieving data from nntp" signal quit nil] 3))) nnheader-report nntp "Couldn't open connection to %s" nntp-accept-response looking-at regexp-quote 1 point-at-bol "Couldn't open connection to %s." zerop 50 re-search-forward "\n\\.?\n" "^\\.?\n" "[34]" search-forward "\n" 20 nnheader-message 6 "NNTP: Receiving headers... %d%%" ...] 8]()
funcall(#[nil "r\306!q\210\307 \210 \204\n\204\310\f\"\203\311\202\243G\312\211e\306!\313\31489:;<=\211A\242\211\203h\314\315\247\203L\316!\202MD>?@\204`A\204`\317!\210\320\321>\322#BCDC;\203z\323C!\202|C\314\211EFCGG\203\261G\211AG\242\211E\203\261CE\211A@\262=\203\206***@F\314\211G\204\213F\205\324\324F!\325>\203\304F\202\324\326\327F!!\210\330ED\"D\314-\211F\205\337\327F!\211C\205\354rCq\210`)HF\203\334BIJ?@\314KL?CMNBCCDC;\203 \323C!\202\"C\314\211EFCGG\203WG\211AG\242\211E\203WCE\211A@\262=\203,***@F\314\211G\2041F\205z\324F!\325>\203jF\202z\326\327F!!\210\330ED\"D\314-\206\202\331C!\211F\203\2408\204\231@\204\231\317\327F!!\210\332\333\334\217\202\246\335\336\337N#.?\204\342O\204\342PQ>\204\342\340 \210rCq\210Hb\210\341\342B!!\203\330H\343y\210\344 |\210)\202\342\335\336\345I#.\210<T<\203\370\346<R\246!\2035\340 \2109q\210:b\210\314f\347=\203\350\351\314\313#\2037\341\352!\203,\343y\210\202\341\353!\2037\354\355\314\313#\2037`:;T;\202;<W\2035S\247\203b=SV\203b\346;\356\246!\203b\357\360\361;\362_=\245#\210\340 \210\202\373S\247\203{=SV\203{\357\360\363\"\210\364 \210\365 \210ed{Trq\210\307 \210U\203\231\366T!\202\233Tc\210eb\210.\n\367)\207" [nntp-server-buffer gnus-nov-is-evil nntp-nov-is-evil articles fetch-old article nntp-find-connection-buffer erase-buffer nntp-retrieve-headers-with-xover nov 0 t nil "HEAD" int-to-string nntp-erase-buffer mapconcat identity " " get-buffer process-status (open run) nntp-kill-buffer process-buffer delq nntp-open-connection err (byte-code "\203* \306 \n\203\307\n!\210\310 \n1P\"\210\311 !\312>\206(\313\314!*\2102\315=\2033\316\2072\203K3\203K\317 3452%\210\316\2073\203Q 345\3206543r\321 !q\210eb\210`f\322>\203w\323\324!\203\271\311 !\325>\203\271\323\326!\203\214\327 !\210\202\257\323\330!\203\242\331\332\333\334\335N#\210\336\334\320\"\210\202\257\323\337!\203\257`\340y\210`|\210\341 !\210eb\210\202j\323\342!\203\306\343 \210\320\202F\311 !\344>\204\324\313\314!\202Fdb\210e\32078\34538\316#\204\370\341 !\210d\346Ze]8db\210\202\335\347\350!7r9q\2107:+\3515?!\2106\204Er4q\210db\210;\203/r\321 !q\210\352\353 !)c\210\2027\354\321 !\320\211#\210<\203D\320<\355\356\357\"\210)\3166\204N\360 \210.\207\316\207" [command process string nntp-last-command-time nntp-last-command nntp-record-commands current-time nntp-record-command process-send-string process-status (open run) nntp-report "Server closed connection" ignore t nntp-async-wait nil process-buffer (50 51 52 53) looking-at "48[02]" (open run) "480" nntp-handle-authinfo "482" nnheader-report nntp "%s" nntp-authinfo-rejected error-message signal "^.*\n" 1 nntp-accept-process-output "[45]" nntp-snarf-error-message (open run) re-search-backward 1000 match-string 0 nntp-decode-text mm-string-to-multibyte buffer-string insert-buffer-substring nnheader-message 5 "" erase-buffer nntp-end-of-line ...] 6) ((nntp-authinfo-rejected (byte-code "\301\302A\"\207" [err signal nntp-authinfo-rejected] 3)) (error (byte-code "\302\303\304 $\207" [address err nnheader-report nntp "Couldn't open connection to %s: %s"] 5)) (quit (byte-code "\300\301!\210\302\303\304\"\210\304\207" [message "Quit retrieving data from nntp" signal quit nil] 3))) nnheader-report nntp "Couldn't open connection to %s" nntp-accept-response looking-at regexp-quote 1 point-at-bol "Couldn't open connection to %s." zerop 50 re-search-forward "\n\\.?\n" "^\\.?\n" "[34]" search-forward "\n" 20 nnheader-message 6 "NNTP: Receiving headers... %d%%" ...] 8])
byte-code("\306 \n#\210\205\307\310\311#\312\216\310\313\314\217*\310\207" [-group -server -connectionless nntp-connection-timeout -timer nntp-with-open-group-internal nntp-possibly-change-group run-at-time nil #[nil "\n ;\203\306 !\202 \307\211\2037\211A\242\211\2037 \211A@\262=\203@\307\211\204\f\205S\310\f!\311>\203G\f\202S\312\313\f!!\210\314\n\"\307-\211\205^\313!\211\205q\315!\316=\205q\312!*\207" [nntp-server-buffer buffer nntp-connection-alist entry process alist get-buffer nil process-status (open run) nntp-kill-buffer process-buffer delq buffer-size 0 -process -buffer] 5] ((byte-code "\203\301!\210\301\207" [-timer nnheader-cancel-timer] 2)) (funcall -bodyfun) ((quit (byte-code "\204\301 \210\302\303\304\"\207" [debug-on-quit nntp-close-server signal quit nil] 3)))] 4)
nntp-with-open-group-function("gmane.emacs.devel" "news.gmane.org" nil #[nil "r\306!q\210\307 \210 \204\n\204\310\f\"\203\311\202\243G\312\211e\306!\313\31489:;<=\211A\242\211\203h\314\315\247\203L\316!\202MD>?@\204`A\204`\317!\210\320\321>\322#BCDC;\203z\323C!\202|C\314\211EFCGG\203\261G\211AG\242\211E\203\261CE\211A@\262=\203\206***@F\314\211G\204\213F\205\324\324F!\325>\203\304F\202\324\326\327F!!\210\330ED\"D\314-\211F\205\337\327F!\211C\205\354rCq\210`)HF\203\334BIJ?@\314KL?CMNBCCDC;\203 \323C!\202\"C\314\211EFCGG\203WG\211AG\242\211E\203WCE\211A@\262=\203,***@F\314\211G\2041F\205z\324F!\325>\203jF\202z\326\327F!!\210\330ED\"D\314-\206\202\331C!\211F\203\2408\204\231@\204\231\317\327F!!\210\332\333\334\217\202\246\335\336\337N#.?\204\342O\204\342PQ>\204\342\340 \210rCq\210Hb\210\341\342B!!\203\330H\343y\210\344 |\210)\202\342\335\336\345I#.\210<T<\203\370\346<R\246!\2035\340 \2109q\210:b\210\314f\347=\203\350\351\314\313#\2037\341\352!\203,\343y\210\202\341\353!\2037\354\355\314\313#\2037`:;T;\202;<W\2035S\247\203b=SV\203b\346;\356\246!\203b\357\360\361;\362_=\245#\210\340 \210\202\373S\247\203{=SV\203{\357\360\363\"\210\364 \210\365 \210ed{Trq\210\307 \210U\203\231\366T!\202\233Tc\210eb\210.\n\367)\207" [nntp-server-buffer gnus-nov-is-evil nntp-nov-is-evil articles fetch-old article nntp-find-connection-buffer erase-buffer nntp-retrieve-headers-with-xover nov 0 t nil "HEAD" int-to-string nntp-erase-buffer mapconcat identity " " get-buffer process-status (open run) nntp-kill-buffer process-buffer delq nntp-open-connection err (byte-code "\203* \306 \n\203\307\n!\210\310 \n1P\"\210\311 !\312>\206(\313\314!*\2102\315=\2033\316\2072\203K3\203K\317 3452%\210\316\2073\203Q 345\3206543r\321 !q\210eb\210`f\322>\203w\323\324!\203\271\311 !\325>\203\271\323\326!\203\214\327 !\210\202\257\323\330!\203\242\331\332\333\334\335N#\210\336\334\320\"\210\202\257\323\337!\203\257`\340y\210`|\210\341 !\210eb\210\202j\323\342!\203\306\343 \210\320\202F\311 !\344>\204\324\313\314!\202Fdb\210e\32078\34538\316#\204\370\341 !\210d\346Ze]8db\210\202\335\347\350!7r9q\2107:+\3515?!\2106\204Er4q\210db\210;\203/r\321 !q\210\352\353 !)c\210\2027\354\321 !\320\211#\210<\203D\320<\355\356\357\"\210)\3166\204N\360 \210.\207\316\207" [command process string nntp-last-command-time nntp-last-command nntp-record-commands current-time nntp-record-command process-send-string process-status (open run) nntp-report "Server closed connection" ignore t nntp-async-wait nil process-buffer (50 51 52 53) looking-at "48[02]" (open run) "480" nntp-handle-authinfo "482" nnheader-report nntp "%s" nntp-authinfo-rejected error-message signal "^.*\n" 1 nntp-accept-process-output "[45]" nntp-snarf-error-message (open run) re-search-backward 1000 match-string 0 nntp-decode-text mm-string-to-multibyte buffer-string insert-buffer-substring nnheader-message 5 "" erase-buffer nntp-end-of-line ...] 6) ((nntp-authinfo-rejected (byte-code "\301\302A\"\207" [err signal nntp-authinfo-rejected] 3)) (error (byte-code "\302\303\304 $\207" [address err nnheader-report nntp "Couldn't open connection to %s: %s"] 5)) (quit (byte-code "\300\301!\210\302\303\304\"\210\304\207" [message "Quit retrieving data from nntp" signal quit nil] 3))) nnheader-report nntp "Couldn't open connection to %s" nntp-accept-response looking-at regexp-quote 1 point-at-bol "Couldn't open connection to %s." zerop 50 re-search-forward "\n\\.?\n" "^\\.?\n" "[34]" search-forward "\n" 20 nnheader-message 6 "NNTP: Receiving headers... %d%%" ...] 8])
nntp-retrieve-headers((189569 189570 189571 189572 189573 189574 189575 189576 189577 189578 189579 189580 189581 189582 189583 189584 189585 189586 189587 189588 189589 189590 189591 189592 189593 189594 189595 189596 189597 189598 189599 189600 189601 189602 189603 189604 189605 189606 189607 189608 189609 189610 189611 189612 189613 189614 189615 189616 189617 189618 ...) "gmane.emacs.devel" "news.gmane.org" nil)
gnus-retrieve-headers((189569 189570 189571 189572 189573 189574 189575 189576 189577 189578 189579 189580 189581 189582 189583 189584 189585 189586 189587 189588 189589 189590 189591 189592 189593 189594 189595 189596 189597 189598 189599 189600 189601 189602 189603 189604 189605 189606 189607 189608 189609 189610 189611 189612 189613 189614 189615 189616 189617 189618 ...) "nntp+news.gmane.org:gmane.emacs.devel")
gnus-agent-retrieve-headers((132743 132791 132797 132799 132802 132804 132805 132818 132822 132843 132854 132857 132858 132859 132927 133024 133067 133068 138659 138668 138682 138684 138685 138686 138687 138688 138693 138694 138697 138728 138729 138741 138743 138746 138747 138751 138752 138756 138760 138764 138780 138786 138945 138946 138947 138948 138952 138954 138962 138977 ...) "nntp+news.gmane.org:gmane.emacs.devel" nil)
gnus-retrieve-headers((132743 132791 132797 132799 132802 132804 132805 132818 132822 132843 132854 132857 132858 132859 132927 133024 133067 133068 138659 138668 138682 138684 138685 138686 138687 138688 138693 138694 138697 138728 138729 138741 138743 138746 138747 138751 138752 138756 138760 138764 138780 138786 138945 138946 138947 138948 138952 138954 138962 138977 ...) "nntp+news.gmane.org:gmane.emacs.devel" nil)
gnus-cache-retrieve-headers((132743 132791 132797 132799 132802 132804 132805 132818 132822 132843 132854 132857 132858 132859 132927 133024 133067 133068 138659 138668 138682 138684 138685 138686 138687 138688 138693 138694 138697 138728 138729 138741 138743 138746 138747 138751 138752 138756 138760 138764 138780 138786 138945 138946 138947 138948 138952 138954 138962 138977 ...) "nntp+news.gmane.org:gmane.emacs.devel" nil)
gnus-retrieve-headers((132743 132791 132797 132799 132802 132804 132805 132818 132822 132843 132854 132857 132858 132859 132927 133024 133067 133068 138659 138668 138682 138684 138685 138686 138687 138688 138693 138694 138697 138728 138729 138741 138743 138746 138747 138751 138752 138756 138760 138764 138780 138786 138945 138946 138947 138948 138952 138954 138962 138977 ...) "nntp+news.gmane.org:gmane.emacs.devel" nil)
gnus-fetch-headers((132743 132791 132797 132799 132802 132804 132805 132818 132822 132843 132854 132857 132858 132859 132927 133024 133067 133068 138659 138668 138682 138684 138685 138686 138687 138688 138693 138694 138697 138728 138729 138741 138743 138746 138747 138751 138752 138756 138760 138764 138780 138786 138945 138946 138947 138948 138952 138954 138962 138977 ...))
gnus-select-newsgroup("nntp+news.gmane.org:gmane.emacs.devel" nil nil)
gnus-summary-read-group-1("nntp+news.gmane.org:gmane.emacs.devel" nil t nil nil nil)
gnus-summary-read-group("nntp+news.gmane.org:gmane.emacs.devel" nil t nil nil nil nil)
gnus-group-read-group(nil t)
gnus-group-select-group(nil)
gnus-topic-select-group(nil)
call-interactively(gnus-topic-select-group nil nil)
command-execute(gnus-topic-select-group)

[Andreas Schwab]

Post by Steinar Bang
It wasn't fixed at all. The issue is still present, and as annoying as
always.
The problem only occurs on news.gmane.org, I'm guessing because its TLS
upgrade fails in some mysterious way.

I don't think so. Try requesting less headers.

Andreas.

[Steinar Bang]

Post by Andreas Schwab
I don't think so.

The link of this issue to the use of TLS has been established a long time ago.

Post by Andreas Schwab
Try requesting less headers.

If I do `C-u 10' I can successfully read the last 10 articles most of
the time (sometimes this also fails with the same error).

But reading articles 10 at a time from the end, is a cumbersome way to
read a newsgroup.

[Andreas Schwab]

Post by Steinar Bang

Post by Andreas Schwab
I don't think so.

The link of this issue to the use of TLS has been established a long time ago.

The backtrace proves that the connection has already been sucessfully
established.

Why does gnus send separate XOVER commands for each article? Did you
set nntp-nov-gap to 0?

Andreas.

[Steinar Bang]

Post by Andreas Schwab
Why does gnus send separate XOVER commands for each article? Did you
set nntp-nov-gap to 0?

nntp-nov-gap is 1.

[Andreas Schwab]

Post by Steinar Bang
nntp-nov-gap is 1.

And why did you change it?

Andreas.

[Steinar Bang]

Post by Andreas Schwab

Post by Steinar Bang
nntp-nov-gap is 1.

And why did you change it?

My comment from 2002 says "faster on sparse groups":
a030466a home/sb/.gnus.el (sb 2002-03-12 11:10:54 +0000 242) (setq nntp-nov-gap 1) ; faster on sparse groups

But I can't remember what I meant by that.

(actually, the line is older than 2002. That's just the oldest date I
have on everything, after config file conversion to RCS, and then to
CVS, and then to subversion, and finally to git)

[Andreas Schwab]

Post by Steinar Bang
a030466a home/sb/.gnus.el (sb 2002-03-12 11:10:54 +0000 242) (setq nntp-nov-gap 1) ; faster on sparse groups

I think that can only be faster on a very slow (but low-latency)
connection, where the additional round trips are compensated by the
fewer data to receive. The default value is 5, which means that there
isn't much potential for savings.

Andreas.

[Steinar Bang]

Post by Andreas Schwab

Post by Steinar Bang
a030466a home/sb/.gnus.el (sb 2002-03-12 11:10:54 +0000 242) (setq nntp-nov-gap 1) ; faster on sparse groups

I think that can only be faster on a very slow (but low-latency)
connection, where the additional round trips are compensated by the
fewer data to receive. The default value is 5, which means that there
isn't much potential for savings.

Looks like I was the reason/cause for the default to end up as 5, back
in 1997...
http://thread.gmane.org/gmane.emacs.gnus.general/9546/focus=9567
http://thread.gmane.org/gmane.emacs.gnus.general/9546/focus=9567
(and the articles in between)

Alternatively, to see them directly in Gnus:
nntp://news.gmane.org/gmane.emacs.gnus.general/11789
(I wonder if `A T' on that article will bring up the whole thread...?)

[Eric Abrahamsen]

Post by Steinar Bang

Post by Andreas Schwab

Post by Steinar Bang
a030466a home/sb/.gnus.el (sb 2002-03-12 11:10:54 +0000 242) (setq nntp-nov-gap 1) ; faster on sparse groups

I think that can only be faster on a very slow (but low-latency)
connection, where the additional round trips are compensated by the
fewer data to receive. The default value is 5, which means that there
isn't much potential for savings.

Looks like I was the reason/cause for the default to end up as 5, back
in 1997...
http://thread.gmane.org/gmane.emacs.gnus.general/9546/focus=9567
http://thread.gmane.org/gmane.emacs.gnus.general/9546/focus=9567
(and the articles in between)
nntp://news.gmane.org/gmane.emacs.gnus.general/11789
(I wonder if `A T' on that article will bring up the whole thread...?)

Much respect for our elders!

:)

[Steinar Bang]

Post by Steinar Bang
nntp://news.gmane.org/gmane.emacs.gnus.general/11789
(I wonder if `A T' on that article will bring up the whole thread...?)

Hm... `A T' only gets the immediate ancestor in the thread, and that
article can't find its ancestor, even though they thread fine in the web
version...?

What does it look like, if I add an article earlier in the thread...?
nntp://news.gmane.org/gmane.emacs.gnus.general/9567

(the start of the thread was posted in January 1997, while the final
postings were in July 1997, maybe that has something to do with it...?)

[Steinar Bang]

Post by Steinar Bang

Post by Andreas Schwab

Post by Steinar Bang
a030466a home/sb/.gnus.el (sb 2002-03-12 11:10:54 +0000 242) (setq nntp-nov-gap 1) ; faster on sparse groups

I think that can only be faster on a very slow (but low-latency)
connection, where the additional round trips are compensated by the
fewer data to receive. The default value is 5, which means that there
isn't much potential for savings.

Looks like I was the reason/cause for the default to end up as 5, back
in 1997...
http://thread.gmane.org/gmane.emacs.gnus.general/9546/focus=9567
http://thread.gmane.org/gmane.emacs.gnus.general/9546/focus=9567
(and the articles in between)

Anyway, I have now removed my nntp-nov-gap setting and Gnus on Windows
now has no problems opening groups with 6-7000 unread articles.

Thank you for figuring this out, Andreas!


- Steinar