Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Oct 1999 10:14:36 -0700 (PDT)
From:      "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
To:        tlambert@primenet.com (Terry Lambert)
Cc:        twinkle.star@263.net, freebsd-smp@FreeBSD.ORG
Subject:   Re: inquire(second time)
Message-ID:  <199910261714.KAA20511@gndrsh.dnsmgr.net>
In-Reply-To: <199910260226.TAA26348@usr06.primenet.com> from Terry Lambert at "Oct 26, 1999 02:26:34 am"

next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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




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