ath(4) HAL in -current vs 5.0

[Stephen Borrill]

I've been running NetBSD 5.0 with Jared's ath patch on an EeePC 900A.
Today I tried using wi-fi in anger and saw I was getting average ping
times of 1600ms (stddev 1416) and 3% packet loss (some ping times over
12000ms!). I then tried -current (the open-source HAL) which was much
better. So I backported the current HAL to 5.0 and tried again. This gave
a fantastic performance improvement (1.2ms with 1.6ms stddev and 0%
packet). I tried the test a few times to check it was consistent.

I understand the reasons for not pulling this up to netbsd-5 especially
that we are at RC3 (I think: lack of testing on all platforms and
problems with TKIP), but hopefully this will be a useful datapoint.

[David Brownlee]

I've been running NetBSD 5.0 with Jared's ath patch on an EeePC 900A. Today I
tried using wi-fi in anger and saw I was getting average ping times of 1600ms
(stddev 1416) and 3% packet loss (some ping times over 12000ms!). I then
tried -current (the open-source HAL) which was much better. So I backported
the current HAL to 5.0 and tried again. This gave a fantastic performance
improvement (1.2ms with 1.6ms stddev and 0% packet). I tried the test a few
times to check it was consistent.
I understand the reasons for not pulling this up to netbsd-5 especially that
we are at RC3 (I think: lack of testing on all platforms and problems with
TKIP), but hopefully this will be a useful datapoint.

How much pain would it be to include it in 5.0 as a compiletime
option? It would require people to compile a custom kernel, but
it at least opens that option

[Stephen Borrill]

Post by David Brownlee

I've been running NetBSD 5.0 with Jared's ath patch on an EeePC 900A. Today
I tried using wi-fi in anger and saw I was getting average ping times of
1600ms (stddev 1416) and 3% packet loss (some ping times over 12000ms!). I
then tried -current (the open-source HAL) which was much better. So I
backported the current HAL to 5.0 and tried again. This gave a fantastic
performance improvement (1.2ms with 1.6ms stddev and 0% packet). I tried
the test a few times to check it was consistent.
I understand the reasons for not pulling this up to netbsd-5 especially
that we are at RC3 (I think: lack of testing on all platforms and problems
with TKIP), but hopefully this will be a useful datapoint.

How much pain would it be to include it in 5.0 as a compiletime
option? It would require people to compile a custom kernel, but
it at least opens that option

Switching between HALs is/was pretty painful. I did this for 4.0 with the
old HAL and ending up duplicating most things and renaming ath to atheee.
However the structure is much cleaner with the new layout, so it might be
much easier now. However, you'll probably still end up battling paths in
conf/files and such like.

[Greg Oster]

Post by Stephen Borrill
I've been running NetBSD 5.0 with Jared's ath patch on an EeePC 900A.
Today I tried using wi-fi in anger and saw I was getting average ping
times of 1600ms (stddev 1416) and 3% packet loss (some ping times over
12000ms!). I then tried -current (the open-source HAL) which was much
better. So I backported the current HAL to 5.0 and tried again. This gave
a fantastic performance improvement (1.2ms with 1.6ms stddev and 0%
packet). I tried the test a few times to check it was consistent.
I understand the reasons for not pulling this up to netbsd-5 especially
that we are at RC3 (I think: lack of testing on all platforms and
problems with TKIP), but hopefully this will be a useful datapoint.

Speaking of ath/HAL/EeePCs, has anyone looked at merging in the
AR9280 driver changes from FreeBSD into -current? I'm certainly
happy to help provide testing for said driver :)

Later...

Greg Oster



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de