Contributed by johan on from the vr-vrrr-vroooom dept.
Thordur I. Björnsson has committed a major update to the vr(4) driver. This triggered Reyk Floeter (reyk@) to emphasize on the importance of this update.
Please read on for Reyk's comment...
Subject: Re: CVS: cvs.openbsd.org: src From: Reyk FloeterDate: 2008-07-19 12:36:16 On Fri, Jul 18, 2008 at 07:38:40AM -0600, Thordur I. Bjornsson wrote: > CVSROOT: /cvs > Module name: src > Changes by: thib@cvs.openbsd.org 2008/07/18 07:38:40 > > Modified files: > sys/dev/pci : if_vr.c if_vrreg.h > > Log message: > o Use mbufs, for the RX ring, instead of malloc()'ing an MCLBYTES sized buffer. > o On non-strict alignment archs, dont copy the mbuf, every time, unload it, and send > it up the stack and just get a new one for the rx ring. We still do the copy on > strict alignment archs though... > o create a function to handle mbuf allocation for the rx ring, vr_mbuf_alloc(), > use it to allocate the mbufs and shuffle the bus dma setup around. > > ideas/code from vic(4) and sis(4); > > ok reyk@, brad@, dlg@ > tested by many, been in snapshots for a while. > Yay! Heads up, this is an important diff for people using vr(4) and systems like the new-age Soekrises (eg. net5501). The driver was not working under high load without this diff because it was, erm, totally wrong. Testing the updated driver shows that it is much better now, even under load with many small packets. Thanks thib!
(Comments are closed)
By Kevin (207.229.181.246) on
I'm tempted to give them a new kernel incorporating these changes before I start shipping them out to the ends of the earth...
Comments
By Henrik Kramshoej (80.160.242.134) hlk@kramse.dk on www.kramse.dk
>
> I'm tempted to give them a new kernel incorporating these changes before I start shipping them out to the ends of the earth...
Hmmm, using this kernel:
OpenBSD 4.4-beta (GENERIC) #979: Wed Jul 16 09:40:32 MDT 2008
todd@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500 MHz
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
real mem = 536440832 (511MB)
avail mem = 510500864 (486MB)
and a Thinkpad X31 with em0 driver and straight cable to Soekris 5501
shows:
hlk@bianca:hlk$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 128 KByte (default)
------------------------------------------------------------
[ 6] local 10.0.47.1 port 5001 connected with 10.0.47.33 port 13101
[ 6] 0.0-10.0 sec 57.8 MBytes 48.4 Mbits/sec
way lower than I have previusly had with OpenBSD - seem to remember some ~90Mbits/sec - which was confirmed using a CF card from a friend with FreeBSD giving 94Mbits/sec on the same rig.
Comments
By Henrik Kramshoej (80.160.242.134) on
The same Soekris that couldn't "handle" more than 50 Mbits/sec with "iperf -s" can act as a router to the next hop, which is another 5501.
Using that I get about 85Mbits/sec throughput from the 5501 acting as router
[ 4] local 10.0.46.1 port 5001 connected with 10.0.47.33 port 27167
[ 4] 0.0-10.0 sec 101 MBytes 84.8 Mbits/sec
from
thinkpad running iperf -c --- 1st 5501 -- 2nd 5501 runing iperf -s
ohh well, I will try some other tools tomorrow instead.
By Anonymous Coward (81.83.46.216) on
By Anonymous Coward (82.161.172.147) on
By Venture37 (venture37) venture37<A>hotmail.com on www.geeklan.co.uk
By corey (208.191.177.19) on
http://marc.info/?t=120397961200001&r=1&w=2
It was pointed out that this was possibly a PHY problem, so maybe not.
Comments
By Brad (2001:470:8802:3:216:41ff:fe17:6933) brad at comstyle dot com on
No.
> It was pointed out that this was possibly a PHY problem, so maybe not.
It is not a PHY issue.
Comments
By Anonymous Coward (96.21.15.58) on
>
> No.
>
> > It was pointed out that this was possibly a PHY problem, so maybe not.
>
> It is not a PHY issue.
Is there a work around this known problem?
Comments
By sthen (2a01:348:108:100:20a:5eff:fe1a:a300) on
> >
> > No.
> >
> > > It was pointed out that this was possibly a PHY problem, so maybe not.
> >
> > It is not a PHY issue.
>
> Is there a work around this known problem?
It never seems to happen if the first thing it's plugged into is an X40/X32, and probably some others using em(4). It's reasonably unlikely to happen if it's plugged into a switch and left there. It's very likely to happen if it's plugged into some random PC which gets rebooted a lot so you probably want to try and avoid doing that for now.