Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet

[Pyun YongHyeon]

On Mon, Nov 10, 2008 at 01:58:54PM +0300, Boris Samorodov wrote:
 > Pyun YongHyeon <pyunyh at gmail.com> writes:
 > > On Sat, Nov 08, 2008 at 12:27:12PM +0300, Boris Samorodov wrote:
 > >  > Pyun YongHyeon <pyunyh at gmail.com> writes:
 > >
 > > [...]
 > >  > > One user reported non-working NFS over UDP and I disabled Rx
 > >  > > checksum offload as AR81xx hardware is not able to handle
 > >  > > fragmented IP datagrams correctly. So it's highly recommended to
 > >  > > disable Rx checksum offload or use the following updated files.
 > >  > >
 > >  > > http://people.freebsd.org/~yongari/ale/ale.20081108.tar.gz
 > >  > 
 > >  > Tested at EeePC-1000. The perfomance dropped (seems to be expected)
 > >  > twice -- to 5.5 MB/s (fetching a big file to tmpfs). Other than that
 > >  > works fine. This is for:
 > >  > -----
 > >  > ale0 at pci0:4:0:0:        class=0x020000 card=0x83241043 chip=0x10261969 rev=0xb0 hdr=0x00
 > >  >     vendor     = 'Attansic (Now owned by Atheros)'
 > >  >     class      = network
 > >  >     subclass   = ethernet
 > >  > -----
 > >
 > > Fortunately, I've managed to add work-around for Rx checksum
 > > offload issue. Would you try latest ale(4) at the fowllowing URL?
 > > http://people.freebsd.org/~yongari/ale/ale.20081110.tar.gz
 > 
 > Great, thanks! The perfomance is returning back. ;-) It shows
 > approx. 10.5 MB/s while ftp'ing a big file to tmpfs. I'd like to show

I didn't even expect such a quantum improvement! :-)

 > you some additional info:
 > -----
 > uname -a ftp://ftp.bsam.ru/pub/tmp/EeePC/uname.2
 > netstat -w 1 ftp://ftp.bsam.ru/pub/tmp/EeePC/netstat.ale.2
 > sysctl dev.ale.0.stats ftp://ftp.bsam.ru/pub/tmp/EeePC/sysctl.ale.stats.2
 > iostat -w 1 ftp://ftp.bsam.ru/pub/tmp/EeePC/iostat.ale.2
 > -----
 > 
 > The interesting one is a netstat one. I'm not sure what zeroes for
 > packets mean while trafic exists.
 > 

Hmm, I also have no idea why netstat(1) shows such a non-sense
value while transfer is in progress. I guess you can easily write a
script that extracts interesting MAC statistics of ale(4).
For example,
sysctl dev.ale.0.stats.rx.good_frames
sysctl dev.ale.0.stats.tx.good_frames

Use 'sysctl -d dev.ale.0.stats' to get complete descriptoin of each
node.

 > BTW, a flood ping created a 233 packets per second trafic.
 > 

Since ale(4) requires a lot of CPU cycles to saturate link, it may
completely depend on your CPU power.
-- 
Regards,
Pyun YongHyeon