Date: Wed, 27 Sep 2006 18:51:55 -0400 From: Miles Nordin <carton@Ivy.NET> To: freebsd-sparc64@freebsd.org Subject: Re: Terrible hme throughput Message-ID: <oqr6xwgbxw.fsf@castrovalva.Ivy.NET> In-Reply-To: <1159396027.5199.18.camel@pinot.fmjassoc.com> (Frank Jahnke's message of "Wed, 27 Sep 2006 15:27:07 -0700") References: <1159396027.5199.18.camel@pinot.fmjassoc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
>>>>> "fj" == Frank Jahnke <jahnke@sonatabio.com> writes:
fj> There's one or two factors of two left to be found. Maybe it
fj> is the Sparc disadvantage for these sorts of calculations
no, I don't think there are any more factors of two to find.
300MHz Pentium, Linux with gcc: 1.5MByte/s
440MHz UltraSPARC II, Solaris with Sun C compiler: 2.3MByte/s
500MHz UltraSPARC II, FreeBSD with gcc: 1.0MByte/s
try a slow PeeCee and see if you get similar results. I think it's
about right: divide performance in half as penalty for trying to use
gcc on anything but i386.
My friend who makes big ftp servers with dm_crypt encrypted disks
reports results roughly in the same ballpark: 40MByte/s throughput
IDE-RAID<->GigEthernet with encryption, 90MByte/s without, on modern
2 - 3GHz PeeCees. In that case it's just decryption rather than
ssh+sshd running on the same CPU, so divide that throughput in half,
and you are in the same MB per MHz ballpark as the other results. I
think it is probably working properly.
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)
iQCVAwUARRsAi4nCBbTaW/4dAQIyvQP/XnsEDlBoHNuhZxmx+P+W1tRWOfndjNX8
u0a1Qm+3jHmcTkN0ERR7YQG/V88kLtlHdJDB+Lo8njJKf1WXFoSj+Oq9djWY3pRJ
HaJQQgeZZtM0przSjbS3owUDXTeiEwOIA5vmue9NxdKPaR6GYZR2HR5wOB2dvz06
x5v/3RbIkh4=
=5k2+
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?oqr6xwgbxw.fsf>