From: mrowczok <mrowczok@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] rconnect via aan reliability patch
Date: Mon, 6 Sep 2021 16:58:52 +0200 [thread overview]
Message-ID: <CAGdRm9KScTc2Sn0P2hhKGcwX+mbH12CaP=PHRrQVF249NwQ0+g@mail.gmail.com> (raw)
In-Reply-To: <E566465FC164B9DBE44CF90B27995DE9@felloff.net>
hey,
some days ago i tested ftp server to see what speeds capable is 9front
virtual machine,
i'm using old installment - i wanted to test it on fresh system before
posting on net/irc but maybe it is related
somehow downloading file from ftp client on another pc manages to
broke all connectivity on guest system,
drawterm is unable to connect, 9p disk service is down.
strange thing is that displaying netstat output on guest/cpu lags on
certain moment.
testing was done with 650mb file and can be reproduced.
Stuff:
guest:
cwfs from 2016
kernel recompiled in august 2019.
host:
vmware workstation 15.5.5 build-16285975
Qualcomm/Atheros e2200 PCI-E Gigabit Ethernet Controller
(with jumbo frames 9KB MTU)
śr., 1 wrz 2021 o 11:24 <cinap_lenrek@felloff.net> napisał(a):
>
> > Write does not block. Read does.
>
> i know.
>
> > In the case with read errors, the aanserver end did everything
> > before aanclient starts to read the address, and somehow the channel
> > has hung up before the read.
>
> yeah, but we really need to figure out why. we might have a bug
> in the tcp stack here, or you might just have some mtu issues
> in your network.
>
> i'm not going to blindly change protocols to tamper over mysterious
> tcp connection problems.
>
> > The extra read in aanserver blocks the aanserver at that point and
> > wait for the OK signal from aanclient before continuing.
>
> yes, i understand that.
>
> > The thing I don't understand is that what actually makes the channel
> > hang up. Do you have any suggestions as to how to debug this issue?
>
> i never had these issues. is it reproducable for you?
>
> we can start by making packet captures with snoopy or wireshark.
>
> if it is sporadic, we could also try to provoke it by doing the
> exact opposite to your patch and delaying the client with a sleep
> maybe? it could also be possible that it is closed my ourselfs
> somehow by accident.
>
> --
> cinap
next prev parent reply other threads:[~2021-09-06 15:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-30 22:24 Xiao-Yong Jin
2021-08-31 7:55 ` cinap_lenrek
2021-08-31 18:38 ` Xiao-Yong Jin
2021-09-01 1:20 ` cinap_lenrek
2021-09-06 14:58 ` mrowczok [this message]
2021-09-06 16:23 ` cinap_lenrek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGdRm9KScTc2Sn0P2hhKGcwX+mbH12CaP=PHRrQVF249NwQ0+g@mail.gmail.com' \
--to=mrowczok@gmail.com \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).