From owner-freebsd-smp Tue Oct 26 10:15:26 1999 Delivered-To: freebsd-smp@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 13AF514EDE for ; Tue, 26 Oct 1999 10:15:14 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA20511; Tue, 26 Oct 1999 10:14:36 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199910261714.KAA20511@gndrsh.dnsmgr.net> Subject: Re: inquire(second time) In-Reply-To: <199910260226.TAA26348@usr06.primenet.com> from Terry Lambert at "Oct 26, 1999 02:26:34 am" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 26 Oct 1999 10:14:36 -0700 (PDT) Cc: twinkle.star@263.net, freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > The need to exclusively access the I/O bus is one of the main > > > factors sited for the developing RAMBus technology coming from > > > major vendors. > > > > > > You had better go sit in the corner and think about that real > > real real hard. RAMBus technology in no way effects exclusive > > access to the I/O bus. That is purely in the domain of the > > CPU / IO bridge chip, and no place near the CPU / Memory controller > > bridge chip. > > > > The main factor driving RAMBus and other fast memory technologies > > is the fact that our CPU cores are now running in production at 2 > > to 4 times the data rate of the fastest memory system designs in > > production. And thats for a single CPU design. The problem of > > CPU demand vs memory bandwidth is only aggrevated, and thusly > > requireing a faster memory subsystem, by SMP. > > It was my understanding that this would apply to memory mapped I/O, > as well, but of course I haven't investigated RAMBus closely enough > (obviously) to be able to say for sure. > > The idea I was trying to communicate is that memory mapped I/O is > a hell of a lot more friendly to SMP than inb/outb based device > communication (c.v. my keyboard LED example later in the posting). > > Anyway, if the RAMBus stuff is useless for direct memory mapped > regions on devices (e.g. they can't come in except via slower > memory elsewhere), then consider me thwacked. 8-). Thwack... RAMBus will not change the fact that the I/O devices are hanging on a PCI bus, unless someone decided to design RAMbusPCI :-). Memory mapped IO devices still sit on the PCI bus, and are in no way effected by the real memory bus. They simply map a portion of the memory address space to the PCI bus, and it runs at PCI speeds. Memory on things like PCI Video cards will continue to operate at PCI memory speeds of 132MiB/s (32b/33MHz PCI) or 533MiB/s (64b/66MHz PCI) regardless of the system memory interface type (SDRAM, DDRAM, RAMBus). The keyboard LED speed issue would require a new design of the keyboard interface and a new keyboard design. The major problem here is the very slow 8042 chips used in controlling the keyboard and the bit level dumb (ie, non-intelegent) interface protocol over a single set of bit lines (serial interface) at a fairly low clock rate (I seem to want to say 100KHz, but can't remember what f of keyclk is, anyway, it has not changed since the original IBM PC in frequency, and only mildly changed in protocol since the XT). RAMBus can not and will not effect this in any way. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message