Date: Mon, 10 Nov 2008 20:25:23 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Boris Samorodov <bsam@ipt.ru> Cc: freebsd-current@FreeBSD.org Subject: Re: Call for testers: Atheros AR8121(L1E)/AR8113/AR8114(L2E) ethernet Message-ID: <20081110112522.GN22162@cdnetworks.co.kr> In-Reply-To: <39598641@bb.ipt.ru> References: <20081030040637.GA78796@cdnetworks.co.kr> <20081030114845.GE78796@cdnetworks.co.kr> <20081031034443.GF82781@cdnetworks.co.kr> <20081107064724.GA11486@cdnetworks.co.kr> <20081108052324.GD14970@cdnetworks.co.kr> <84265871@bb.ipt.ru> <20081110041229.GE22162@cdnetworks.co.kr> <39598641@bb.ipt.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 10, 2008 at 01:58:54PM +0300, Boris Samorodov wrote: > Pyun YongHyeon <pyunyh@gmail.com> writes: > > On Sat, Nov 08, 2008 at 12:27:12PM +0300, Boris Samorodov wrote: > > > Pyun YongHyeon <pyunyh@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081110112522.GN22162>