public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* Timeouts on slow connections
@ 2023-09-09 3:32 John Goerzen
2023-09-23 12:06 ` Sergey Matveev
0 siblings, 1 reply; 8+ messages in thread
From: John Goerzen @ 2023-09-09 3:32 UTC (permalink / raw)
To: nncp-devel
Hi,
I've recently been on some slow hotel wifi. I've been getting "i/o
timed out" on the client (nncp-call[er] side). On the nncp-daemon side,
I get everything from "ERROR SP with [hostname]: waiting for payload:
xdr:decodeArray: data exceeds max slice limit - read: '3155270245'" at
the time the client times out, to just EOF errors on the server.
The upload speed from the client appears to be about 250KiB/sec.
However, it blows through the first MB or two almost immediately,
suggesting that it is filling up a transfer buffer somewhere.
I have tried raising all the timeouts I can, to no avail. Is there
another timeout somewhere that could be raised?
I vaguely remember asking about this before, but unfortunately a search
isn't turning up the answer, so my apologies if I've forgotten.
Thanks again for NNCP!
- John
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timeouts on slow connections
2023-09-09 3:32 Timeouts on slow connections John Goerzen
@ 2023-09-23 12:06 ` Sergey Matveev
2023-09-28 4:14 ` John Goerzen
0 siblings, 1 reply; 8+ messages in thread
From: Sergey Matveev @ 2023-09-23 12:06 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
Greetings!
*** John Goerzen [2023-09-08 22:32]:
>timed out" on the client (nncp-call[er] side). On the nncp-daemon side,
>I get everything from "ERROR SP with [hostname]: waiting for payload:
>xdr:decodeArray: data exceeds max slice limit - read: '3155270245'" at
>the time the client times out, to just EOF errors on the server.
Yeah, sometimes I also got similar things on connections with dropped
packets/connections. Well, currently I did not bother dealing with it.
After a while connections will be workabled/resumed anyway.
>I have tried raising all the timeouts I can, to no avail. Is there
>another timeout somewhere that could be raised?
"Onlinedeadline" is generally the main one.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timeouts on slow connections
2023-09-23 12:06 ` Sergey Matveev
@ 2023-09-28 4:14 ` John Goerzen
2023-09-28 13:49 ` Sergey Matveev
0 siblings, 1 reply; 8+ messages in thread
From: John Goerzen @ 2023-09-28 4:14 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Sat, Sep 23 2023, Sergey Matveev wrote:
> [[PGP Signed Part:Undecided]]
> Greetings!
>
> *** John Goerzen [2023-09-08 22:32]:
>>timed out" on the client (nncp-call[er] side). On the nncp-daemon side,
>>I get everything from "ERROR SP with [hostname]: waiting for payload:
>>xdr:decodeArray: data exceeds max slice limit - read: '3155270245'" at
>>the time the client times out, to just EOF errors on the server.
>
> Yeah, sometimes I also got similar things on connections with dropped
> packets/connections. Well, currently I did not bother dealing with it.
> After a while connections will be workabled/resumed anyway.
Hi Sergey, and thanks for your reply!
I never really got it working in this scenario. I think the problem was
bufferbloat combined with very slow connection and low timeouts.
I actually worked around it by piping nncp-bundle -tx | ssh hostname
nncp-bundle -rx. Then, nncp-call worked well enough to delete the
packets that were sent (I use -seen).
>>I have tried raising all the timeouts I can, to no avail. Is there
>>another timeout somewhere that could be raised?
>
> "Onlinedeadline" is generally the main one.
I already have that one set very high (tens of thousands of seconds) so
I'm sure it's not that one :-)
- John
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timeouts on slow connections
2023-09-28 4:14 ` John Goerzen
@ 2023-09-28 13:49 ` Sergey Matveev
2023-09-28 15:04 ` John Goerzen
0 siblings, 1 reply; 8+ messages in thread
From: Sergey Matveev @ 2023-09-28 13:49 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 529 bytes --]
*** John Goerzen [2023-09-27 23:14]:
>I never really got it working in this scenario. I think the problem was
>bufferbloat combined with very slow connection and low timeouts.
"Slow" is a relative thing. Previously I check workability with
firewall's traffic shaper, that passed only 64Kbps of traffic in single
direction. And everything worked. But indeed bufferbloats and large
delays could be a problem.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timeouts on slow connections
2023-09-28 13:49 ` Sergey Matveev
@ 2023-09-28 15:04 ` John Goerzen
2023-09-28 15:18 ` Sergey Matveev
0 siblings, 1 reply; 8+ messages in thread
From: John Goerzen @ 2023-09-28 15:04 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Thu, Sep 28 2023, Sergey Matveev wrote:
> [[PGP Signed Part:Undecided]]
> *** John Goerzen [2023-09-27 23:14]:
>>I never really got it working in this scenario. I think the problem was
>>bufferbloat combined with very slow connection and low timeouts.
>
> "Slow" is a relative thing. Previously I check workability with
> firewall's traffic shaper, that passed only 64Kbps of traffic in single
> direction. And everything worked. But indeed bufferbloats and large
> delays could be a problem.
Yep, I saw several MB tick over almost immediately in the -progress
display. I can't remember if it was 2MB or 10MB, but in any case it was
quite a few, on a connection barely faster than the 64Kbps you tested
with. My guess on what happened is that it queued up all that stuff to
send, then timed out while the queue emptied.
I did a very brief search in the code for this timeout and didn't find
one. Is there a way we can dramatically increase or eliminate that
timeout? (onlinedeadline could, of course, still take effect for people
that need it)
Thanks,
John
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timeouts on slow connections
2023-09-28 15:04 ` John Goerzen
@ 2023-09-28 15:18 ` Sergey Matveev
2023-09-28 16:32 ` John Goerzen
2023-10-03 0:13 ` John Goerzen
0 siblings, 2 replies; 8+ messages in thread
From: Sergey Matveev @ 2023-09-28 15:18 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
*** John Goerzen [2023-09-28 10:04]:
>Yep, I saw several MB tick over almost immediately in the -progress
>display.
I am not completely sure, but I think that is solely OS-dependant stuff.
Personally I do not see so noticeable traffic bursts. However I think
that somewhere (on some GNU/Linux distro I believe) I saw that behaviour.
Unfortunately currently do not have enough time look deeper in that
issue, still did not replying one of your email about ACKs :-(
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timeouts on slow connections
2023-09-28 15:18 ` Sergey Matveev
@ 2023-09-28 16:32 ` John Goerzen
2023-10-03 0:13 ` John Goerzen
1 sibling, 0 replies; 8+ messages in thread
From: John Goerzen @ 2023-09-28 16:32 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Thu, Sep 28 2023, Sergey Matveev wrote:
> [[PGP Signed Part:Undecided]]
> *** John Goerzen [2023-09-28 10:04]:
>>Yep, I saw several MB tick over almost immediately in the -progress
>>display.
>
> I am not completely sure, but I think that is solely OS-dependant stuff.
> Personally I do not see so noticeable traffic bursts. However I think
> that somewhere (on some GNU/Linux distro I believe) I saw that behaviour.
>
> Unfortunately currently do not have enough time look deeper in that
> issue, still did not replying one of your email about ACKs :-(
No worries, I will see what I can do to duplicate both that and the addr
item and see if I can pin it down. Thanks for all your work on NNCP,
Sergey!
- John
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Timeouts on slow connections
2023-09-28 15:18 ` Sergey Matveev
2023-09-28 16:32 ` John Goerzen
@ 2023-10-03 0:13 ` John Goerzen
1 sibling, 0 replies; 8+ messages in thread
From: John Goerzen @ 2023-10-03 0:13 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Thu, Sep 28 2023, Sergey Matveev wrote:
> [[PGP Signed Part:Undecided]]
> *** John Goerzen [2023-09-28 10:04]:
>>Yep, I saw several MB tick over almost immediately in the -progress
>>display.
>
> I am not completely sure, but I think that is solely OS-dependant stuff.
> Personally I do not see so noticeable traffic bursts. However I think
> that somewhere (on some GNU/Linux distro I believe) I saw that behaviour.
>
> Unfortunately currently do not have enough time look deeper in that
> issue, still did not replying one of your email about ACKs :-(
OK, I've done some more testing and have some observations:
- When nncp-daemon is run in -ucspi mode, the problem does not occur.
- I have verified that onlinedeadline and maxonlinetime have been set
quite high and should not be the cause of the problem.
- The problem occurs even on TCP connections from localhost.
- The problem occurs even when the client connects with nodelay.
I am pretty convinced that the problem isn't at the OS (socket) layer.
This is not standard behavior for a socket-type program written in C, so
it has to be somewhere in the golang stack. But where? The golang tcp
stuff does have integrated support for timeouts (unlike its C-based
counterparts), but I can't find any info on the defaults, and I went to
search the source tree... and..
There is NNCPDEADLINE! I am going to test this out later. I think it
is what I need. I was puzzled at the beginning, thinking I could have
sworn we had talked about this before and that there was an environment
variable about this somewhere. But I couldn't find it on any of the
commands pages (where TMPDIR and NNCPNOSYNC are documented).
If indeed this solves things as I think it may, it might be nice to
have it documented on the command page (or allow this to be set
somewhere in nncp.hjson).
Thanks!
- John
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-10-03 0:45 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-09 3:32 Timeouts on slow connections John Goerzen
2023-09-23 12:06 ` Sergey Matveev
2023-09-28 4:14 ` John Goerzen
2023-09-28 13:49 ` Sergey Matveev
2023-09-28 15:04 ` John Goerzen
2023-09-28 15:18 ` Sergey Matveev
2023-09-28 16:32 ` John Goerzen
2023-10-03 0:13 ` John Goerzen