State of X4200 M2 (ok)
Adriaan de Groot
groot at kde.org
Thu Jan 25 13:06:57 UTC 2007
On Thursday 25 January 2007 04:43, Thomas Hurst wrote:
> > 1000baseSX-FDX, 1000baseT, 1000baseT-FDX, auto
> > nve0: Ethernet address: 04:4b:80:80:80:03
> >
> > The machine hangs at boot for several seconds after nve0 before miibus0;
> > I do not see this in other nForce4 based machines I've got.
>
> Urgh, so 2 of the 4 NIC's on the M2's are nVidia crap? That's quite a
> step back from the 4 e1000's in earlier models :(
The nve seem to work pretty well, but I have not loaded them that heavily. I
have 40G of data to schlep later today, we'll see how it likes that.
> > I don't get any /dev/mpt* either (but I
> > guess that's more a comment for freebsd-hardware). The device isn't
> > recognized by any of the LSI management tools (megamgr, megacli, megarc)
> > either -- but then I'm not sure there's anything to manage there yet.
>
> There's some basic hardware RAID:
> mpt0: Capabilities: ( RAID-0 RAID-1 )
> I doubt it's really worth using.
With that kind of capabilities, I can see where GEOM has an adge (the hotswap
doesn't work either, inserting a disk just gets cam events 0x16 and 0x12
again and no /dev/da* is created for the disk).
> > The machine hasn't had much of a stress test yet. It gets through
> > buildworlds and can shuffle data around and will write on standard
> > SATA laptop drives too, if you can be bothered to stick them in the
> > drive bays.
>
> Really? I wasn't aware these LSI's, nor mpt(4) supported SATA (despite
> what the names say). Not very useful anyway, SAS drives are a far
> better match for server workloads (i.e. they actually perform well and
> are designed to run 24/7).
>
> Do they get exposed via ata(4) or appear as SCSI devices over CAM?
Yes, really. They show up as SCSI over cam and are reasonable for sequential
read (at about 30MB/s) and awful for random read; I wouldn't vouch for their
longevity, though. The laptop drive *does* seem to go to sleep when not in
use automatically, as I notice a second or two of lag when accessing it after
an idle period. Here's one:
da1: <ATA TOSHIBA MK8032GS 1G> Fixed Direct Access SCSI-5 device
da1: 300.000MB/s transfers, Tagged Queueing Enabled
da1: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C)
Dollar a gigabyte if your data is cheap :) Getting a *tray* for the disk is
another issue. Anyway, that experiment is done; I'll be playing with various
eSATA solutions next. That's off-topic on this list.
--
Adriaan de Groot
KDE Quality Team http://www.englishbreakfastnetwork.org/
SQO-OSS Researcher http://www.sqo-oss.eu/
More information about the freebsd-amd64
mailing list