From owner-freebsd-hardware Sun May 7 15:29:13 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA04581 for hardware-outgoing; Sun, 7 May 1995 15:29:13 -0700 Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id PAA04575 for ; Sun, 7 May 1995 15:29:07 -0700 Received: from post.demon.co.uk by disperse.demon.co.uk id aa07903; 7 May 95 23:28 GMT-60:00 Received: from bagpuss.demon.co.uk by post.demon.co.uk id aa05626; 7 May 95 23:28 GMT-60:00 Received: (karl@localhost) by bagpuss.demon.co.uk (99.9/99.9) id XAA01274; Sun, 7 May 1995 23:30:21 +0100 From: Karl Strickland Message-Id: <199505072230.XAA01274@bagpuss.demon.co.uk> Subject: Intel 'ZAPPA' motherboard -details? To: freebsd-hardware@FreeBSD.org Date: Sun, 7 May 1995 23:30:20 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 678 Sender: hardware-owner@FreeBSD.org Precedence: bulk Just seen this advertised, but with few details. The ad says it uses the triton chipset, does anyone have more info? Few questions: Is a triton based board currently the best to buy? I understand triton boards give better performance using pipelined burst SRAM for the cache, and EDO SIMMS. (right?) Can you mix standard fast page SIMMS & EDO simms on the same motherboard? Thanks! -- ------------------------------------------+----------------------------------- Mailed using ELM on FreeBSD | Karl Strickland PGP 2.3a Public Key Available. | Internet: karl@bagpuss.demon.co.uk | From owner-freebsd-hardware Sun May 7 15:35:11 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA04759 for hardware-outgoing; Sun, 7 May 1995 15:35:11 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA04748 for ; Sun, 7 May 1995 15:35:02 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id PAA15187; Sun, 7 May 1995 15:34:42 -0700 From: "Rodney W. Grimes" Message-Id: <199505072234.PAA15187@gndrsh.aac.dev.com> Subject: Re: Intel 'ZAPPA' motherboard -details? To: karl@bagpuss.demon.co.uk (Karl Strickland) Date: Sun, 7 May 1995 15:34:42 -0700 (PDT) Cc: freebsd-hardware@FreeBSD.org In-Reply-To: <199505072230.XAA01274@bagpuss.demon.co.uk> from "Karl Strickland" at May 7, 95 11:30:20 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1104 Sender: hardware-owner@FreeBSD.org Precedence: bulk > > Just seen this advertised, but with few details. The ad says it uses > the triton chipset, does anyone have more info? It uses the Triton chip set, it has only 3 PCI slots, I have a vendor who is bringing the product in. Once he gets it I will take a closer look at the board. Given that it has the AMI winbios on it, I would guess it is a bad board for most Unix systems as you'll run into the interrupt sharing problems that the Intel Plato has. > Few questions: > Is a triton based board currently the best to buy? It is the highest performance in OEM type motherboards, it does have the miss feature of lacking parity support for main memory. > > I understand triton boards give better performance using > pipelined burst SRAM for the cache, and EDO SIMMS. (right?) It is better in performance without these options too. > Can you mix standard fast page SIMMS & EDO simms on the same > motherboard? Not to my knowledge. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-hardware Sun May 7 16:08:58 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA05716 for hardware-outgoing; Sun, 7 May 1995 16:08:58 -0700 Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id QAA05707 for ; Sun, 7 May 1995 16:08:56 -0700 Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA13211; Mon, 8 May 95 01:08:38 +0100 Date: Mon, 8 May 95 01:08:38 +0100 From: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) Message-Id: <9505080008.AA13211@cabri.obs-besancon.fr> To: rgrimes@gndrsh.aac.dev.com Cc: karl@bagpuss.demon.co.uk, freebsd-hardware@FreeBSD.org In-Reply-To: <199505072234.PAA15187@gndrsh.aac.dev.com> (rgrimes@gndrsh.aac.dev.com) Subject: Re: Intel 'ZAPPA' motherboard -details? X-Mailer: Emacs Sender: hardware-owner@FreeBSD.org Precedence: bulk >>>>> "Rodney" == Rodney W Grimes writes: >> >> I understand triton boards give better performance using >> pipelined burst SRAM for the cache, and EDO SIMMS. (right?) > It is better in performance without these options too. >> Can you mix standard fast page SIMMS & EDO simms on the same >> motherboard? > Not to my knowledge. What is the difference between "EDO" simms and "normal" simms? Jean-Marc. > -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation Company Custom computers for FreeBSD _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-hardware Sun May 7 16:19:56 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA06141 for hardware-outgoing; Sun, 7 May 1995 16:19:56 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA06129 for ; Sun, 7 May 1995 16:19:51 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id QAA15309; Sun, 7 May 1995 16:19:27 -0700 From: "Rodney W. Grimes" Message-Id: <199505072319.QAA15309@gndrsh.aac.dev.com> Subject: Re: Intel 'ZAPPA' motherboard -details? To: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) Date: Sun, 7 May 1995 16:19:27 -0700 (PDT) Cc: karl@bagpuss.demon.co.uk, freebsd-hardware@FreeBSD.org In-Reply-To: <9505080008.AA13211@cabri.obs-besancon.fr> from "Jean-Marc Zucconi" at May 8, 95 01:08:38 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1128 Sender: hardware-owner@FreeBSD.org Precedence: bulk > > >>>>> "Rodney" == Rodney W Grimes writes: > > >> > >> I understand triton boards give better performance using > >> pipelined burst SRAM for the cache, and EDO SIMMS. (right?) > > > It is better in performance without these options too. > > >> Can you mix standard fast page SIMMS & EDO simms on the same > >> motherboard? > > > Not to my knowledge. > > What is the difference between "EDO" simms and "normal" simms? EDO stands for Extended Data Out, I don't have any technical books that cover just what changed in the DRAM design at this time, though my new set of Micron Technology memory books shipped on Thursday so I will have the ``official'' story very soon. My current understanding is that EDO simms basically hold valid data on the output after RAS has been brought inactive, this allows you to start the RAS precharge time early, effectively eliminating the difference between access and cycle times on DRAM. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-hardware Sun May 7 18:47:16 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA15607 for hardware-outgoing; Sun, 7 May 1995 18:47:16 -0700 Received: from athens.emi.net (root@ns.emi.net [204.181.45.2]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA15601 for ; Sun, 7 May 1995 18:47:13 -0700 Received: from florence.emi.net (florence.emi.net [204.181.45.5]) by athens.emi.net (8.6.10/8.6.10) with ESMTP id UAA30518; Sun, 7 May 1995 20:52:06 -0400 Received: (from tb@localhost) by florence.emi.net (8.6.10/8.6.10) id VAA00617; Sun, 7 May 1995 21:51:03 -0400 From: Thomas Bagli Message-Id: <199505080151.VAA00617@florence.emi.net> Subject: Re: Intel 'ZAPPA' motherboard -details? To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Sun, 7 May 1995 21:51:02 -0400 (EDT) Cc: jmz@cabri.obs-besancon.fr, karl@bagpuss.demon.co.uk, freebsd-hardware@FreeBSD.org In-Reply-To: <199505072319.QAA15309@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 7, 95 04:19:27 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 862 Sender: hardware-owner@FreeBSD.org Precedence: bulk In a previous encounter, Rodney W. Grimes writes: > > EDO stands for Extended Data Out, I don't have any technical books > that cover just what changed in the DRAM design at this time, though > my new set of Micron Technology memory books shipped on Thursday so > I will have the ``official'' story very soon. > > My current understanding is that EDO simms basically hold valid data > on the output after RAS has been brought inactive, this allows you > to start the RAS precharge time early, effectively eliminating the > difference between access and cycle times on DRAM. Not that I believe everything I read, but the word is from some test lab that the difference between EDO and conventional memory shows no significant change in systems or graphic performance. The tests were, of course, DOS/Windows tests. Let us know what you find out. Thomas Bagli From owner-freebsd-hardware Sun May 7 19:54:54 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id TAA17513 for hardware-outgoing; Sun, 7 May 1995 19:54:54 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id TAA17502 for ; Sun, 7 May 1995 19:54:47 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id TAA15618; Sun, 7 May 1995 19:52:59 -0700 From: "Rodney W. Grimes" Message-Id: <199505080252.TAA15618@gndrsh.aac.dev.com> Subject: Re: Intel 'ZAPPA' motherboard -details? To: tb@emi.net (Thomas Bagli) Date: Sun, 7 May 1995 19:52:58 -0700 (PDT) Cc: freebsd-hardware@FreeBSD.org In-Reply-To: <199505080151.VAA00617@florence.emi.net> from "Thomas Bagli" at May 7, 95 09:51:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7503 Sender: hardware-owner@FreeBSD.org Precedence: bulk > > In a previous encounter, Rodney W. Grimes writes: > > > > EDO stands for Extended Data Out, I don't have any technical books > > that cover just what changed in the DRAM design at this time, though > > my new set of Micron Technology memory books shipped on Thursday so > > I will have the ``official'' story very soon. > > > > My current understanding is that EDO simms basically hold valid data > > on the output after RAS has been brought inactive, this allows you > > to start the RAS precharge time early, effectively eliminating the > > difference between access and cycle times on DRAM. > > Not that I believe everything I read, but the word is from some test > lab that the difference between EDO and conventional memory shows no > significant change in systems or graphic performance. The tests were, > of course, DOS/Windows tests. Let us know what you find out. Here are some numbers for you to see that infact there is a measurable difference between standard simms and EDO simms, you just have to test for specific things. Stuff like the Windows/DOS benchmarks are so tuned to run out of a 256K cache that it makes me sick: This is from a memory benchmark posted to -hackers by Bruce Evans, changed by L Jonas Olsson, and then changed again by Bruce Evans to correct for an extra store operation per loop. This is basically 4 x 32 bit memory read or write test per iteration of the loop written in assembler. First a set of test comparing the Intel Neptune chip set to the Intel Triton chip set: Board: ASUS PCI/E-P54NP4 Board: ASUS PCI/I-P54TP4 CPU: P54C-90 CPU: P54C-90 Cache: 256K-15nS SRAM Cache: 256K-15nS SRAM Memory: 32MB Fast Page Mode Memory: 32MB Fast page mode -DBDE_ORIGINAL -DCORRECTED -DBDE_ORIGINAL -DCORRECTED 1024: 204081633 bytes/sec 1024: 208333333 bytes/sec 2048: 212765957 bytes/sec 2048: 227272727 bytes/sec 4096: 227272727 bytes/sec 4096: 227272727 bytes/sec 8192: 204081633 bytes/sec 8192: 217391304 bytes/sec 16384: 103092784 bytes/sec 16384: 101010101 bytes/sec 32768: 89285714 bytes/sec 32768: 104166667 bytes/sec 65536: 89285714 bytes/sec 65536: 80000000 bytes/sec 131072: 86206897 bytes/sec 131072: 90090090 bytes/sec 262144: 71942446 bytes/sec 262144: 76923077 bytes/sec 524288: 65789474 bytes/sec 524288: 66666667 bytes/sec 1048576: 60240964 bytes/sec 1048576: 62111801 bytes/sec 2097152: 59880240 bytes/sec 2097152: 62111801 bytes/sec 4194304: 56179775 bytes/sec 4194304: 60606061 bytes/sec 8388608: 52910053 bytes/sec 8388608: 57471264 bytes/sec 16777216: 41493776 bytes/sec 16777216: 52356021 bytes/sec -DLJO_WRITE_NOCACHE -DCORRECTE -DLJO_WRITE_NOCACHE -DCORRECTED 1024: 23201856 bytes/sec 1024: 37735849 bytes/sec 2048: 23255814 bytes/sec 2048: 38022814 bytes/sec 4096: 23255814 bytes/sec 4096: 37735849 bytes/sec 8192: 23255814 bytes/sec 8192: 38022814 bytes/sec 16384: 23148148 bytes/sec 16384: 38022814 bytes/sec 32768: 23148148 bytes/sec 32768: 38022814 bytes/sec 65536: 23148148 bytes/sec 65536: 37593985 bytes/sec 131072: 23201856 bytes/sec 131072: 37735849 bytes/sec 262144: 22988506 bytes/sec 262144: 37313433 bytes/sec 524288: 23148148 bytes/sec 524288: 37735849 bytes/sec 1048576: 23041475 bytes/sec 1048576: 37453184 bytes/sec 2097152: 22883295 bytes/sec 2097152: 37313433 bytes/sec 4194304: 22831050 bytes/sec 4194304: 37037037 bytes/sec 8388608: 22675737 bytes/sec 8388608: 36496350 bytes/sec 16777216: 22371365 bytes/sec 16777216: 35087719 bytes/sec -DLJO_WRITE_CACHE -DCORRECTED -DLJO_WRITE_CACHE -DCORRECTED 1024: 238095238 bytes/sec 1024: 250000000 bytes/sec 2048: 256410256 bytes/sec 2048: 270270270 bytes/sec 4096: 263157895 bytes/sec 4096: 263157895 bytes/sec 8192: 243902439 bytes/sec 8192: 227272727 bytes/sec 16384: 62111801 bytes/sec 16384: 55555556 bytes/sec 32768: 57471264 bytes/sec 32768: 55555556 bytes/sec 65536: 61349693 bytes/sec 65536: 50000000 bytes/sec 131072: 47169811 bytes/sec 131072: 45871560 bytes/sec 262144: 37453184 bytes/sec 262144: 42918455 bytes/sec 524288: 30395137 bytes/sec 524288: 40160643 bytes/sec 1048576: 29239766 bytes/sec 1048576: 38167939 bytes/sec 2097152: 28735632 bytes/sec 2097152: 38314176 bytes/sec 4194304: 28571429 bytes/sec 4194304: 37593985 bytes/sec 8388608: 27777778 bytes/sec 8388608: 37313433 bytes/sec 16777216: 26809651 bytes/sec 16777216: 36231884 bytes/sec And now the TP4 using EDO memory and the cache turned OFF (running with the cache on seems to defeat any benifit from the EDO memory due to the delay waiting for the cache miss to start main memory). I do not know if this holds true when you use the pipelined burst cache. The real thing that EDO memory was meant to do was to replace the cache in Notebook computers, since SRAM cache's eat a lot of power. I know running my Trition machine with EDO memory and the cache turned off feals just like it does with standard memory and the cache on. Board: ASUS PCI/I-P54TP4 CPU: P54C-90 Cache: 256K-15nS SRAM (Disabled) Memory: 16MB EDO -DBDE_ORIGINAL -DCORRECTED 1024: 217391304 bytes/sec 2048: 227272727 bytes/sec 4096: 227272727 bytes/sec 8192: 185185185 bytes/sec 16384: 64516129 bytes/sec 32768: 64516129 bytes/sec 65536: 64516129 bytes/sec 131072: 64516129 bytes/sec 262144: 64102564 bytes/sec 524288: 62500000 bytes/sec 1048576: 62500000 bytes/sec 2097152: 61728395 bytes/sec 4194304: 58823529 bytes/sec 8388608: 54054054 bytes/sec -DLJO_WRITE_NOCACHE -DCORRECTED 1024: 37313433 bytes/sec 2048: 37878788 bytes/sec 4096: 37878788 bytes/sec 8192: 37878788 bytes/sec 16384: 37878788 bytes/sec 32768: 37735849 bytes/sec 65536: 37593985 bytes/sec 131072: 37735849 bytes/sec 262144: 37313433 bytes/sec 524288: 37313433 bytes/sec 1048576: 37174721 bytes/sec 2097152: 36900369 bytes/sec 4194304: 36496350 bytes/sec 8388608: 34364261 bytes/sec -DLJO_WRITE_CACHE -DCORRECTED 1024: 232558140 bytes/sec 2048: 250000000 bytes/sec 4096: 270270270 bytes/sec 8192: 217391304 bytes/sec 16384: 38759690 bytes/sec 32768: 39525692 bytes/sec 65536: 39525692 bytes/sec 131072: 39370079 bytes/sec 262144: 38610039 bytes/sec 524288: 38910506 bytes/sec 1048576: 38461538 bytes/sec 2097152: 38610039 bytes/sec 4194304: 36496350 bytes/sec 8388608: 18148820 bytes/sec -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-hardware Sun May 7 20:02:28 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA17612 for hardware-outgoing; Sun, 7 May 1995 20:02:28 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA17602 for ; Sun, 7 May 1995 20:02:20 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.11) id VAA13295; Sun, 7 May 1995 21:05:16 -0600 Date: Sun, 7 May 1995 21:05:16 -0600 From: Nate Williams Message-Id: <199505080305.VAA13295@trout.sri.MT.net> To: "Rodney W. Grimes" Cc: tb@emi.net (Thomas Bagli), freebsd-hardware@FreeBSD.org Subject: Re: Intel 'ZAPPA' motherboard -details? In-Reply-To: <199505080252.TAA15618@gndrsh.aac.dev.com> References: <199505080151.VAA00617@florence.emi.net> <199505080252.TAA15618@gndrsh.aac.dev.com> Sender: hardware-owner@FreeBSD.org Precedence: bulk > This is from a memory benchmark posted to -hackers by Bruce Evans, changed > by L Jonas Olsson, and then changed again by Bruce Evans to correct for > an extra store operation per loop. This is basically 4 x 32 bit memory > read or write test per iteration of the loop written in assembler. Any chance that we could get this benchmark into the ports tree? Nate From owner-freebsd-hardware Sun May 7 20:10:30 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA17865 for hardware-outgoing; Sun, 7 May 1995 20:10:30 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA17858 for ; Sun, 7 May 1995 20:10:26 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id UAA15686; Sun, 7 May 1995 20:07:42 -0700 From: "Rodney W. Grimes" Message-Id: <199505080307.UAA15686@gndrsh.aac.dev.com> Subject: Re: Intel 'ZAPPA' motherboard -details? To: nate@trout.sri.MT.net (Nate Williams) Date: Sun, 7 May 1995 20:07:42 -0700 (PDT) Cc: tb@emi.net, freebsd-hardware@FreeBSD.org In-Reply-To: <199505080305.VAA13295@trout.sri.MT.net> from "Nate Williams" at May 7, 95 09:05:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 949 Sender: hardware-owner@FreeBSD.org Precedence: bulk > > > This is from a memory benchmark posted to -hackers by Bruce Evans, changed > > by L Jonas Olsson, and then changed again by Bruce Evans to correct for > > an extra store operation per loop. This is basically 4 x 32 bit memory > > read or write test per iteration of the loop written in assembler. > > Any chance that we could get this benchmark into the ports tree? If it was not so dependent on compile time options, and was cleaned up so that it did not run forever and fill all of swap maybe. But for right now I use it the way it is but would not wish to have it hanging out in ports as anything I would have to support. Another good quick test of memory speeds is iozone, as long as you are hitting the buffer cache you are basically looking at how fast we can bcopy memory. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-hardware Sun May 7 22:27:56 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA18979 for hardware-outgoing; Sun, 7 May 1995 22:27:56 -0700 Received: from mail.barrnet.net (mail.BARRNET.NET [131.119.246.7]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA18917 for ; Sun, 7 May 1995 22:26:42 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by mail.barrnet.net (8.6.10/MAIL-RELAY-LEN) with ESMTP id WAA03775 for ; Sun, 7 May 1995 22:23:35 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA03744; Mon, 8 May 1995 14:57:53 +1000 Date: Mon, 8 May 1995 14:57:53 +1000 From: Bruce Evans Message-Id: <199505080457.OAA03744@godzilla.zeta.org.au> To: nate@trout.sri.MT.net, rgrimes@gndrsh.aac.dev.com Subject: Re: Intel 'ZAPPA' motherboard -details? Cc: freebsd-hardware@FreeBSD.org, tb@emi.net Sender: hardware-owner@FreeBSD.org Precedence: bulk >> This is from a memory benchmark posted to -hackers by Bruce Evans, changed >> by L Jonas Olsson, and then changed again by Bruce Evans to correct for >> an extra store operation per loop. This is basically 4 x 32 bit memory >> read or write test per iteration of the loop written in assembler. >Any chance that we could get this benchmark into the ports tree? It is a toy. I was playing with a better one that mmaps /dev/mem to avoid cache collisions from page fragmentation, but gave up because there were too many mmap bugs. I'm more interested in measuring the cache collisions and avoiding them and in picking the best memory access order than in benchmarking. Testing memory writes safely is harder. One neat method is to write a unique pattern to pages that you own and then search for the pattern in /dev/mem. Then it is probably safe to write to overwrite when the pattern is in /dev/mem. This method also tells you the physical address of the pages that you own. I'm not sure how to find the end of physical memory. On my system, it is where accesses become very slow. Accessing nonexistent memory may cause a panic. Bruce From owner-freebsd-hardware Sun May 7 23:01:55 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id XAA19813 for hardware-outgoing; Sun, 7 May 1995 23:01:55 -0700 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA19806 for ; Sun, 7 May 1995 23:01:51 -0700 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id XAA16028; Sun, 7 May 1995 23:00:24 -0700 From: "Rodney W. Grimes" Message-Id: <199505080600.XAA16028@gndrsh.aac.dev.com> Subject: Re: Intel 'ZAPPA' motherboard -details? To: bde@zeta.org.au (Bruce Evans) Date: Sun, 7 May 1995 23:00:23 -0700 (PDT) Cc: freebsd-hardware@FreeBSD.org In-Reply-To: <199505080457.OAA03744@godzilla.zeta.org.au> from "Bruce Evans" at May 8, 95 02:57:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2572 Sender: hardware-owner@FreeBSD.org Precedence: bulk > > >> This is from a memory benchmark posted to -hackers by Bruce Evans, changed > >> by L Jonas Olsson, and then changed again by Bruce Evans to correct for > >> an extra store operation per loop. This is basically 4 x 32 bit memory > >> read or write test per iteration of the loop written in assembler. > > >Any chance that we could get this benchmark into the ports tree? > > It is a toy. I was playing with a better one that mmaps /dev/mem to avoid > cache collisions from page fragmentation, but gave up because there were > too many mmap bugs. I'm more interested in measuring the cache collisions > and avoiding them and in picking the best memory access order than in > benchmarking. I have to agree with Bruce here on this one, it is a toy, and unless you very carefull control the conditions under which you run it the results can be skewed pretty badly. I typically cold boot the machine single user and run the sequence of tests. This tends to give me a big free memory pool that has not been trashed to death by lots of vm activity. Upon Nate prodding me for a copy of the code I sent it to him and he sent me back results that are somewhat reasonable but probably not very comparitive to any results I have since his test conditions did not duplicate mine. To do this testing ideally a single user program should be written that can take over the whole machine to control the alignment of things with respect to the cache (ie, stop direct mapped cache thrashing do to logical != physical address). The other thing to be done running this as a stand alone program is to measure the different regions's of memory and how fast they are. The all important ones being L1 cache, L2 cache, main memory, and video memory. Even possible shared ISA memory on say something like a WD8013. > > Testing memory writes safely is harder. One neat method is to write a > unique pattern to pages that you own and then search for the pattern in > /dev/mem. Then it is probably safe to write to overwrite when the pattern > is in /dev/mem. This method also tells you the physical address of the > pages that you own. I'm not sure how to find the end of physical memory. > On my system, it is where accesses become very slow. Accessing nonexistent > memory may cause a panic. I think I would rather hack a kernel to bits to do the specific testing than try much harder from a user land program. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD From owner-freebsd-hardware Wed May 10 03:25:38 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id DAA16104 for hardware-outgoing; Wed, 10 May 1995 03:25:38 -0700 Received: from Hydro.CAM.ORG (Hydro.CAM.ORG [198.168.73.132]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id DAA16096 for ; Wed, 10 May 1995 03:25:35 -0700 Received: from vasyl.HIP.CAM.ORG by Hydro.CAM.ORG with SMTP id GAA00636 (8.6.11/8.6.9 for ); Wed, 10 May 1995 06:25:29 -0400 Date: Wed, 10 May 1995 06:25:29 -0400 Message-ID: <199505101025.GAA00636@Hydro.CAM.ORG> X-Sender: vasyl@pop.hip.cam.org X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-hardware@FreeBSD.org From: vasyl@cam.org (Bill Pawlowsky) Sender: hardware-owner@FreeBSD.org Precedence: bulk index Vasyl Pawlowsky vasyl@cam.org Yes, I check my e-mail at least 3 times / day! It doesn't mean I read it! http://www.cam.org/~vasyl/index.html http://www.cam.org/~vasyl/susk.htm From owner-freebsd-hardware Fri May 12 22:54:23 1995 Return-Path: hardware-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA01409 for hardware-outgoing; Fri, 12 May 1995 22:54:23 -0700 Received: from ercc.snu.ac.kr (ercc.snu.ac.kr [147.46.80.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id WAA01381 for ; Fri, 12 May 1995 22:54:10 -0700 Received: from eltn20.snu.ac.kr by ercc.snu.ac.kr (5.0/SMI-SVR4) id AA01389; Sat, 13 May 1995 14:57:58 --900 Received: from eltn19.snu.ac.kr by eltn20.snu.ac.kr (4.1/SMI-4.1) id AA24299; Sat, 13 May 95 14:51:46 KST From: chilly@eltn20.snu.ac.kr (Kim Gyudong ISDL PH91) Message-Id: <9505130551.AA24299@eltn20.snu.ac.kr> To: hardware@FreeBSD.org Date: Sat, 13 May 1995 14:51:44 +0900 (KST) X-Mailer: ELM [version 2.4 PL24H1] Content-Type: text Content-Length: 209 Sender: hardware-owner@FreeBSD.org Precedence: bulk -- Gyudong Kim chilly@jaguar.snu.ac.kr Phone +82 2 880 7280 | chilly@eltn20.snu.ac.kr Fax +82 2 873 0073 | Dept. of Electronics Engineering, Seoul Nat'l Univ, 151-742, Seoul, Korea