On Tue, Mar 23, 2021 at 07:47:08PM +0000, Mikolaj Kucharski wrote:
> On Tue, Mar 23, 2021 at 07:06:33PM +0000, Mikolaj Kucharski wrote:
> > On Tue, Mar 23, 2021 at 06:01:27PM +0100, Stefan Sperling wrote:
> > > This switches athn(4) to the new RA Tx rate adaptation module.
> > > Tests on athn(4) PCI devices are welcome.
> > > USB devices don't need to be tested in this case Tx rate adaptation
> > > is taken care of by firmware.
> > > 
> > > I could only test on AR9285 so far, but the result looks promising.
> > > 
> > > diff c6a6a64b49f2287751632205d64f594eb6c1ee42 
> > > 636e9964c6e5313bb1c75823249d483597a0e93a
> > ...
> > 
> > 
> > Tested on athn(4) in `mediaopt hostap` mode. Uptime 1hr, so not a lot of
> > testing yet. So far no issues. I have two systems like that (in hostap)
> > and in `dmesg | grep athn` only difference is mac address between them.
> > I can send full dmesg from second system as well if you want.
> > 
> 
> I also have third system, with the same athn(4) card (only mac address
> is different in `dmesg | grep athn` output), but it acts as a Wi-Fi
> client and is connected to OpenBSD athn(4)-based access point from
> my previous email (full dmesg output in an earlier email).
> 

After week of running this I have similar observations like Scott
Bennett.

I will focus on one location, as I have 2 access points running on
athn(4) with the diff from this thread, but I'm only present at one of
those locations. All athn(4) machines have the diff applied.

OpenBSD, athn(4), hostap
OpenBSD, athn(4), wi-fi client to above access point
OpenBSD, iwm(4), wi-fi client to above access point

I do see some packets dropped with RA patch:

# mtr -rwb -c 1000 192.168.220.76
Start: 2021-03-31T08:17:57+0000
HOST: pce-0041.home.lan Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.220.76     9.2%  1000    2.2   2.6   1.2  82.9   3.4

Above is from hostap machine to athn(4) client. Below is the other way
around. Client to hostap. Measurments with mtr on both ends were not
executed at the same time, but one after the other, with couple of
mintues gap.

# mtr -rwb -c 1000 192.168.220.1
Start: 2021-03-31T10:38:07+0000
HOST: pce-0067.home.local Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.220.1       10.5%  1000    3.1   2.5   1.5  43.7   2.2

The loss is big, but I didn't notice this too much over short
interactive ssh sessions. However I do notice problem havily when I'm on
a laptop with iwm(4) ssh'ing to athn(4) client. Then ssh stalls are
sigificant that I need to wait until TCP recovers and I can type again.
I'm often using scp(1) between athn(4) client and iwm(4) laptop and that
amplifies the problem during simultaneous interactive ssh session.
SSH stalls are more prominient, longer.

I need to say it's still better than I think without this RA diff, as
communitcating with athn(4) client from iwm(4) laptop before was worse
as that very often triggered those famous athn device timeouts and
recovering from them took way longer than from the packet loss and RA.
Packet loss revovery with RA is in tens of seconds, recovery from athn
device timeout was in minutes, because usually timeouts occured one
after another, like 3 or 4 in a row. With RA I don't see this happening
any more.

So, all in all I prefer RA, but I do see packet losses.

-- 
Regards,
 Mikolaj

Reply via email to