Skip site navigation (1)Skip section navigation (2)
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>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
I believe DDR still has it bead (PC2100 that is), Rambus serailizes all writes
to 32 bit or 16 bit (an even 8 bit) depending on the modules. I haven't seen 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 talked
about how great it would be. I thought it was crap back then. The idea is that
it can queue 28 mem ops, where SDRAM can only do like 4. Typical environments
typically don't do the writes that it looks good on, jsut certain special cases.
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:
> 
> 
> :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.
> 
>     It says 800 MHz (PC-800 RIMMs) on the side of the box.
> 
>     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.
> 
>     Celeron 650 MHz (HP desktop) (DIMM)
> 	16.16 MBytes/sec (copy)
> 
>     Pentium III 550 MHz (Dell 2400) (DIMM)
> 	25.90 MBytes/sec (copy)
> 
>     Pentium 4 1.3 GHz / PC-800 RIMMs (Sony VAIO)
> 	32.38 MBytes/sec (copy)
> 
> 
> 						-Matt
> 
> Compile -O2, changing the two occurances of '512' to '4' will reproduce
> the original bulk-transfer rates.  By default this program tests 
> single-transfer (always cache miss).
> 
> #include <sys/types.h>
> #include <sys/time.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdarg.h>
> #include <unistd.h>
> 
> #define NLOOP	100
> 
> char Buf1[2 * 1024 * 1024];
> char Buf2[2 * 1024 * 1024];
> 
> int deltausecs(struct timeval *tv1, struct timeval *tv2);
> 
> int
> main(int ac, char **av)
> {
>     int i;
>     double dtime;
>     struct timeval tv1;
>     struct timeval tv2;
> 
>     memset(Buf1, 1, sizeof(Buf1));
>     for (i = 0; i < 10; ++i)
> 	bcopy(Buf1, Buf2, sizeof(Buf1));
> 
>     gettimeofday(&tv1, NULL);
>     for (i = 0; i < NLOOP; ++i) {
> 	int j;
> 	int k;
> 	for (k = sizeof(int); k <= 512; k += sizeof(int)) {
> 	    for (j = sizeof(Buf1) - k; j >= 0; j -= 512)
> 		*(int *)(Buf2 + j) = *(int *)(Buf1 + j);
> 	}
>     }
>     gettimeofday(&tv2, NULL);
> 
>     dtime = (double)deltausecs(&tv1, &tv2);
>     printf("%6.2f MBytes/sec (copy)\n", (double)sizeof(Buf1) * NLOOP / dtime);
>     return(0);
> }
> 
> int
> deltausecs(struct timeval *tv1, struct timeval *tv2)
> {
>     int usec;
> 
>     usec = (tv2->tv_usec + 1000000 - tv1->tv_usec);
>     usec += (tv2->tv_sec - tv1->tv_sec - 1) * 1000000;
>     return(usec);
> }
> 

[-- Attachment #2 --]
-----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-----
help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010305044342.A23879>