| [News] Marvell announces Discovery III Northbridge | ANN.lu |
| Posted on 30-Sep-2003 15:01 GMT by takemehomegrandma | 94 comments
View flat
View list | |
Marvell today announced the Discovery III northbridge. It features a 200MHz PowerPC CPU interface, 200MHz DDR SDRAM Interface (400Mbps data rate), Dual CPU SMP Support (MPX and 60x modes), PCI-X, Gigabit ethernet and is software compatible with other Discovery northbridges.
Source: morphos-news.de
|
|
| List of all comments to this article |
| Marvell announces Discovery III Northbridge : Comment 85 of 94 | ANN.lu |
| Posted by Joe "Floid" Kanowitz on 02-Oct-2003 02:55 GMT | In reply to Comment 84 (tarbos):
tarbos said,
>>AMD64’s northbridge
>And what may this be?
I know (or hope) you're just playing, but he meant the on-die memory controller. For the even-less-technical sorts reading, it's a fair comparison; AMD64 does away with the northbridge as we know it, integrating half of it on the CPU itself... and the other half as well, if you count HyperTransport as the Uberbus it is. (The 'tunnels' or 'bridges' used to provide PCI, PCI-X, AGP, 3GIO, USB, legacy ports, IDE and so on are basically just HyperTransport peripherals. Think of a conventional CPU bus crossed with Rambus/Firewire/SCSI.)
The performance numbers speak for themselves; designing it that way certainly doesn't hurt. How much of that is really based on clock rate... I dunno. You need the clock rate in some respect to have the fat internal bandwidth that makes it all possible, but if my perspective is accurate, it's more that it helps remove the chance of an external chipset screwing things up (viz. Apple's discussion of MPX? reordering lower down). Or a bottlenecking bus, sure... but it's more a matter of *design* and parallelism than just clock-speed waving.
I'm really lost on roadmaps right now, but whatever ClawHammer was/is, it was once supposed to ship without the onboard memory controller. Meanwhile, the brit sites have noted a trend on low-end SMP boards:
http://theinquirer.net/?article=11845
...manufacturers are opting to use only one chip's controller. This clouds the issue a good bit, but maybe the impact can be derived somehow. (Gah, can't just take the hit versus 'regular' bank-per-CPU designs, because the data in the banks aren't coherent... Maybe you could try to derive the impact on regular bank-per-CPU multiprocessor boards versus uniprocessors, but that seems pretty specious, sounds like a job for synthetic benchmarking.)
http://tinyurl.com/oa40 pretty much stops at the edge of the L2, annoyingly. At least for a dork like me.
@Andreas:
Wow. I was looking for those numbers, and I think it's fair to say "Holy ****, how'd they **** that up?"
Barefeats suspects the cache is the story. I dunno.
http://tinyurl.com/pen1 links to Apple's sparse documentation of their "U2" chipset. The concept of "prefetch" comes to mind, but I'm not skilled enough to apply it, and my halfa__ed research suggests that'd be the wrong tree... Alternatively, it smells like buffering/"converting" from DDR down to MPX (this is MPX, right?) adds a latency they couldn't counter. (Hm, but putting more?/faster? SRAM in the controller, and then cranking up the memory even faster -- DDR400 vs. 333 -- and presumably the internal chipset operations along with it -- less wait to 'undouble' each bit, pack it into that SRAM, and get it aimed at the CPU -- should compensate? Maybe U2 isn't asynchronous *enough* internally, since Apple only did it for "marchitectural" reasons, and fear of the price spike for plain SDR?)
Since the few Articia benchmarks we have have been pretty close on both platforms, we have a good baseline for the existing hardware... Guess we'll have to wait and see if the Discovery III beats it. (OTOH, the numbers I'm thinking of -- http://personal.inet.fi/cool/pekosbil/a1benchmarks.htm -- were mostly tasks that could run out of cache? Anyone want to post some LAME numbers or something?) |
|
| List of all comments to this article (continued) |
|
- User Menu
-
- About ANN archives
- The ANN archives is powered by #AmigaZeux. It was updated daily (news last: 22-Oct-2004; comments last: 18-May-2005).
ANN.lu was created, previously owned and maintained by Christian Kemp, www.ckemp.com.
- Contribute
- Not possible at this time!
- Search ANN archives
- Advanced search
- Hosting
- ANN.lu was hosted by Dreamhost. Sign up through this link, mention "ckemp" as referrer and he will get a 10% commission on any account you purchase.
Please show your appreciation for any past, present and future work on ANN.lu by making a contribution via PayPal.
|
