Date: Mon, 5 Mar 2001 04:43:42 -0500 From: Coleman Kane <cokane@FreeBSD.ORG> To: Matt Dillon <dillon@earth.backplane.com> Cc: Coleman Kane <cokane@FreeBSD.ORG>, freebsd-hackers@FreeBSD.ORG Subject: Re: Machines are getting too damn fast Message-ID: <20010305044342.A23879@cokane.yi.org> In-Reply-To: <200103050512.f255CoB32923@earth.backplane.com>; from dillon@earth.backplane.com on Sun, Mar 04, 2001 at 09:12:50PM -0800 References: <200103040934.f249YHi27877@earth.backplane.com> <20010304230342.A3870@cokane.yi.org> <200103050512.f255CoB32923@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
I believe DDR still has it bead (PC2100 that is), Rambus serailizes all wri=
tes
to 32 bit or 16 bit (an even 8 bit) depending on the modules. I haven't see=
n any
64bit RIMMs. Also, DDR scales higher (up to 333Mhz I think). Just wait for
that. I've pretty much given up on RamBus, I saw back in '96 when they talk=
ed
about how great it would be. I thought it was crap back then. The idea is t=
hat
it can queue 28 mem ops, where SDRAM can only do like 4. Typical environmen=
ts
typically don't do the writes that it looks good on, jsut certain special c=
ases.
That's where you get into the fact that RamBus sucks for use in PCs. Too
specialized. Too proprietary.
Matt Dillon had the audacity to say:
>=20
>=20
> :You should see what speed RamBus they were using, 600 or 800 Mhz. It is
> :pretty fast for large memory writes and reads. It'd be cool to see how
> :the different speeds stack up against one another. DDR comparisons would
> :be cool too. Yeah, for the frequency, you have to take into account that
> :these are different chips than your PIII or Athlons and the performance
> :difference is not simply a linear relation to the frequency rating
> :(i.e.: 1.3Ghz is not really over one-billion instructions per second,
> :just clocks per second). We installed Linux at a UC Free OS User Group
> :installfest here in cincinnati, it was pretty sweet. The machine was a
> :Dell and the case was freakin' huge. It also came with a 21" monitor and
> :stuff. The performace was really good, but not really any better than I
> :hads gleaned from the newer 1Ghz Athlons or PIII's.
>=20
> It says 800 MHz (PC-800 RIMMs) on the side of the box.
>=20
> The technical reviews basically say that bulk transfer rates for
> RamBus blow DDR away, but DDR wins for random reads and writes
> due to RamBus's higher startup latency. I don't have any DDR
> systems to test but I can devise a test program.
>=20
> Celeron 650 MHz (HP desktop) (DIMM)
> 16.16 MBytes/sec (copy)
>=20
> Pentium III 550 MHz (Dell 2400) (DIMM)
> 25.90 MBytes/sec (copy)
>=20
> Pentium 4 1.3 GHz / PC-800 RIMMs (Sony VAIO)
> 32.38 MBytes/sec (copy)
>=20
>=20
> -Matt
>=20
> Compile -O2, changing the two occurances of '512' to '4' will reproduce
> the original bulk-transfer rates. By default this program tests=20
> single-transfer (always cache miss).
>=20
> #include <sys/types.h>
> #include <sys/time.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdarg.h>
> #include <unistd.h>
>=20
> #define NLOOP 100
>=20
> char Buf1[2 * 1024 * 1024];
> char Buf2[2 * 1024 * 1024];
>=20
> int deltausecs(struct timeval *tv1, struct timeval *tv2);
>=20
> int
> main(int ac, char **av)
> {
> int i;
> double dtime;
> struct timeval tv1;
> struct timeval tv2;
>=20
> memset(Buf1, 1, sizeof(Buf1));
> for (i =3D 0; i < 10; ++i)
> bcopy(Buf1, Buf2, sizeof(Buf1));
>=20
> gettimeofday(&tv1, NULL);
> for (i =3D 0; i < NLOOP; ++i) {
> int j;
> int k;
> for (k =3D sizeof(int); k <=3D 512; k +=3D sizeof(int)) {
> for (j =3D sizeof(Buf1) - k; j >=3D 0; j -=3D 512)
> *(int *)(Buf2 + j) =3D *(int *)(Buf1 + j);
> }
> }
> gettimeofday(&tv2, NULL);
>=20
> dtime =3D (double)deltausecs(&tv1, &tv2);
> printf("%6.2f MBytes/sec (copy)\n", (double)sizeof(Buf1) * NLOOP / dt=
ime);
> return(0);
> }
>=20
> int
> deltausecs(struct timeval *tv1, struct timeval *tv2)
> {
> int usec;
>=20
> usec =3D (tv2->tv_usec + 1000000 - tv1->tv_usec);
> usec +=3D (tv2->tv_sec - tv1->tv_sec - 1) * 1000000;
> return(usec);
> }
>=20
--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE6o1/OERViMObJ880RAb3oAKDAV97F1VIw5Ts0bohDoUqgFFxrRwCg51Vt
kbhtSIxE/Hlm7t1USZTpWjs=
=EAS4
-----END PGP SIGNATURE-----
--X1bOJ3K7DJ5YkBrT--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010305044342.A23879>