From owner-freebsd-hackers Mon Mar 5 14:30:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id A2DE337B718 for ; Mon, 5 Mar 2001 14:30:33 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id QAA84736; Mon, 5 Mar 2001 16:30:22 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Mon, 5 Mar 2001 16:30:21 -0600 (CST) From: Chris Dillon To: Matt Dillon Cc: "E.B. Dreger" , Subject: Re: Machines are getting too damn fast In-Reply-To: <200103052027.f25KRK442804@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 5 Mar 2001, Matt Dillon wrote: > :On Mon, 5 Mar 2001, E.B. Dreger wrote: > : > :I've got a ServerWorks III HE-SL system with 512MB of two-way > :interleaved PC133 SDRAM and dual PIII-800's. Is that close enough? > ::-) > : > :Here is my "memory bandwidth test", much much simpler and less > :scientific than Matt's: > : > :dd if=/dev/zero of=/dev/null bs=10m count=1000 > :1000+0 records in > :1000+0 records out > :10485760000 bytes transferred in 23.716504 secs (442129245 bytes/sec) > : > :I just did a recent 4.2-STABLE 'make -j 4 buildworld' on that system > :in just over 34 minutes. Here's the time output: > :1980.707u 768.223s 34:20.89 133.3% 1297+1456k 39517+6202io 1661pf+0w > > That is quite impressive for SDRAM, though I'm not exactly sure what's > being measured due to the way /dev/zero and /dev/null operate. On > my system the above dd test returns around 883MB/sec so I would guess > that it is only doing a read-swipe on the memory. I figured if /dev/null and /dev/zero had relatively little memory impact, which I figure is the case, it would matter more how dd does its blocking. If you reduce the blocksize to something that will fit in your L2 caches, you'll see a very significant increase in throughput. For example, on the PIII-850 (116MHz FSB and SDRAM, its overclocked) here on my desk with 256KB L2 cache: dd if=/dev/zero of=/dev/null bs=10m count=200 200+0 records in 200+0 records out 2097152000 bytes transferred in 10.032157 secs (209042982 bytes/sec) dd if=/dev/zero of=/dev/null bs=512k count=4000 4000+0 records in 4000+0 records out 2097152000 bytes transferred in 8.229456 secs (254834825 bytes/sec) dd if=/dev/zero of=/dev/null bs=128k count=16000 16000+0 records in 16000+0 records out 2097152000 bytes transferred in 1.204001 secs (1741819224 bytes/sec) Now THAT is a significant difference. :-) > (sony 1.3G / RIMM) > apollo:/home/dillon> dd if=/dev/zero of=/dev/null bs=10m count=1000 > 1000+0 records in > 1000+0 records out > 10485760000 bytes transferred in 11.867550 secs (883565697 bytes/sec) Very impressive. Looks about right given the theoretical maximum bandwidth of your memory system. From what I've been gathering, that dd-test shows roughly 1/4 of the total theoretical memory bandwidth (two reads and two writes happening?), minus any chipset deficiencies when it comes to memory transfers. For example, this PIII-850 on a BX board is actually an overclocked 700MHz 100MHz FSB PIII. So, it is using a 116MHz FSB and the SDRAM is running at that speed as well. The theoretical maximum bandwidth of this should be 8(bytes-per-clock)*116(MHz)=928MB/sec. I'm seeing about 210MB/sec on the dd-test, so thats pretty close to 1/4. In your case, you are using PC800 RDRAM on a Pentium-4 system on an i850 board, which IIRC uses a dual-channel RDRAM setup, theoretically doubling the bandwidth that you could get with only one channel. Since you're using dual RDRAM channels of PC800 RDRAM, that would be 4(bytes-per-clock)*800(MHz)=3200MB/sec. Again, the dd-test is pretty close to 1/4 the total theoretical bandwidth (actually a little over), since you achieved about 883MB/sec. In an HE-SL system I have here, it uses dual-interleaved PC133 SDRAM. That would be 16(bytes-per-clock)*133(MHz)=2128MB/sec. The dd-test is a little off the mark of 1/4 the theoretical maximum bandwidth at 442MB/sec, but this thing is the only system I've seen the dd-test on so far that hasn't used an Intel chipset. The Intel chipsets have shown in other benchmarks to be more efficient than anybody else's chipsets (VIA, AMD, RCC, etc) at doing the memory thing, so that makes sense. I think I'm on to something here with this 'cheap' dd-test. :-) A PC2100 DDR-SDRAM system will have a theoretical bandwidth of 2100MB/sec (duh), so a dd-test should come out to around 525MB/sec. I'm guessing it will actually be a bit less since the AMD and especially VIA chipsets aren't going to be anywhere near as efficient as the Intels have been. I'm guessing 95% efficiency for the AMD, so about 500MB/sec from the dd-test. 85% efficient for the VIA, so around 450MB/sec. Anyone care to test that on one or both of the new AMD-chipset and VIA-chipset DDR systems and see how close it comes? :-) > The only thing I don't like about this baby is the IBM IDE hard drive's > write performance. I only get 10-12 MBytes/sec. Read performance is > incredible, though... I get 37MB/sec dd'ing from /dev/ad0s1a to > /dev/null. > > ad0: 58644MB [119150/16/63] at ata0-master UDMA100 That is a 75GXP series, which is supposed to be one of the fastest, if not the fastest, IDE drive on the market right now. Hmm. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message