Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: tlug: dual-pentium processors
- To: tlug@example.com
- Subject: Re: tlug: dual-pentium processors
- From: Karl-Max Wagner <karlmax@example.com>
- Date: Tue, 11 Aug 1998 14:17:36 +0000 (GMT)
- Content-Transfer-Encoding: 7bit
- Content-Type: text/plain; charset=US-ASCII
- In-Reply-To: <Pine.LNX.4.00.9808112159350.3454-100000@example.com> from "Christopher Sekiya" at Aug 11, 98 10:03:29 pm
- Reply-To: tlug@example.com
- Sender: owner-tlug@example.com
> I see no point to paying extra cash for anything faster than 233 MHz, as > the extra CPU speed[1] is ultimately limited by the bus speed[2]. Not necessarily. You forget the L1 cache. If you have highly localized code most of the time ( and this is not so unreasonable to assume ) then you do a lot of computation in cache and you suck in new pages in a kind of burst mode. Using programming tricks ( the "intentional cache miss" trick ) you can even see to it that the required page is already in cache as far as you need it. > [1] Does anyone else remember the dire warnings by the EE pundits around > 86/87 about the dangers of emitting EMF in the high MHz range -- Pundits ????? Buhahahahaha....! In RF enginerering it is common practice to run signals in the tens of GHz range over PCB traces. You have to follow proper design rules ( characteristic impedance, avoidance of crosstalk etc . ) though - but this has been commonplace engineering in the radio field for decades. > which is why we'll never see a bus speed higher than 33 MHz? Why Bullshit ! 33 MHz is almost DC. Even if you consider the harmonics ( don't consider anything beyond the 3rd... ) that's just middle VHF. Where is the problem ? > isn't that a concern anymore? Probably because the digital guys got some teaching from the RF gang, I guess.... > > [2] Yes, I know about the 83/100 MHz bus. How much of a performance win > is that? Enough to shave a couple of milliseconds off of my kernel > compiles? It simply triples your I/O capabilities, thus reducing latencies by the same factor. Depends on your I/O intensity. See above. Actually, I'm always shocked by the knowledge ( or better lack thereof ) in rf engineering issues common to digital hardware designers. Just look at PCI and their great ( truly hair raising ) scheme of dealing with line reflections. The inventors of that ought to be nuked. I just remember a friend designing a frame grabber using totally inadequate wiring techniques ( actually, looking at it made insulted my rf instincts enough to make me sick ). The thing behaved erratically. After being unable to solve the problems he followed my advice and did a new breadboard following sound rf engineering practices - oh wonder, it worked without a hitch...! There ain't anything like some years of solid rf design experience..... Karl-Max Wagner karlmax@example.com -------------------------------------------------------------- Next Nomikai: 18 September, 19:30 Tengu TokyoEkiMae 03-3275-3691 Next Meeting: 10 October, Tokyo Station Yaesu central gate 12:30 -------------------------------------------------------------- Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp
- Follow-Ups:
- Re: tlug: dual-pentium processors
- From: Christopher Sekiya <wileyc@example.com>
- tlug: Re: PCI [was: dual-pentium processors]
- From: Rex Walters <rex@example.com>
- References:
- Re: tlug: dual-pentium processors
- From: Christopher Sekiya <wileyc@example.com>
Home | Main Index | Thread Index
- Prev by Date: Re: tlug: GUI Linux reliability vs other OS
- Next by Date: Re: tlug: Re: djb [was: ibm.net with LINUX (Red Hat)]
- Prev by thread: Re: tlug: dual-pentium processors
- Next by thread: Re: tlug: dual-pentium processors
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links