 | |
What core speed were/are north bridges and/or MCH's clocked at?
Hardware Chips Processor, cache, memory chips, etc. (comp.sys.ibm.pc.hardware.chips)
 |
| | Thread Tools | Search this Thread | Display Modes |
#51
 
| |||
| |||
|
Re: What core speed were/are north bridges and/or MCH's clocked at? -
11-15-2006
, 02:33 AM
|
On Fri, 10 Nov 2006 06:14:17 GMT "pigdos" <NA (AT) nowhere (DOT) com> wrote in Message id: <ZMU4h.189$yE6.15 (AT) newssvr14 (DOT) news.prodigy.com>: Um daytripper, how do you figure a hard drive unilaterally writes to main memory? Do you honestly think devices just independently begin writing to main memory (aside from memory NIC's) without any CPU intervention at all? Have you ever read up on what exactly is involved in setting up a DMA xfer? There is also the concept of uncacheable memory addresses maybe you should read up on that as well. I dub thee PigIgnorant. |
#52
| |||
| |||
|
|
pigdos wrote: Gosh... The CPU writes into some controller register the address range it might use. Thats all. The device is then allowed to start transfer at will (for example disk might start transfering the data after 15ms -- by that time typical OS will switch task about 15 times as well -- probably whole CPU cache will be swapped few times as well and CPU has already executed about 30 million instructions. The data disk writes into memory must get in sync with CPU caches, and how do you thing the CPU is informed about data being written? No, no cache flushing instruction and stuff is done when disk finishes tranfer, as performance would be terrible. Hint: google for memory snoops. There are only two viable options: either address bus is bidirectinal (Pentiums & Cores and stuff) or there is additional snoop access bus (K7). There is also the concept of uncacheable memory addresses maybe you should read up on that as well. Take your own advice. The areas where disk transfers occurs are cacheable in any hald-baked OS! Such areas are typically for some controller memory and/or io ports mapped into CPU's physical address range. Uncacheable memory area is needed when memory accesses must be stricly controlled (for example accessing to some address triggers some action in the device). rgds -- Sebastian Kaliszewski -- "Never underestimate the power of human stupidity" -- from Notebooks of L.L. |
#53
| |||
| |||
|
|
On Fri, 10 Nov 2006 06:14:17 GMT, "pigdos" <NA (AT) nowhere (DOT) com> wrote: Um daytripper, how do you figure a hard drive unilaterally writes to main memory? Do you honestly think devices just independently begin writing to main memory (aside from memory NIC's) without any CPU intervention at all? Have you ever read up on what exactly is involved in setting up a DMA xfer? There is also the concept of uncacheable memory addresses maybe you should read up on that as well. Ok, game over. I've given you *way* more time than you are clearly worth. While I don't use killfiles, I suspect our sun will burn out before I try to help you again... /daytripper |
#54
| |||
| |||
|
|
In article <9p54h.67$IR4.23 (AT) newssvr25 (DOT) news.prodigy.net>, NA (AT) nowhere (DOT) com says... Um, nothing writes to memory unless the CPU initiates it. DMA xfers are not initiated without CPU intervention (at least to set up the starting and ending addresses). I'm referring here to a single CPU situation w/a N. Bridge. Nothing? You really need to be beat about the head and body by a *large* cluestick! BTW, you have been but the hurt apparently hasn't set in yet. -- Keith |
#55
| |||
| |||
|
|
Nice response, I hope you didn't have to think too hard to come up with it. |
Quote:
|
Doug "Trent" <none (AT) dev (DOT) nul.pissoff> wrote in message news:44c9l2paeos713fp51v0m3jv79p83n7fgj (AT) 4ax (DOT) com... On Fri, 10 Nov 2006 06:14:17 GMT "pigdos" <NA (AT) nowhere (DOT) com> wrote in Message id: <ZMU4h.189$yE6.15 (AT) newssvr14 (DOT) news.prodigy.com>: Um daytripper, how do you figure a hard drive unilaterally writes to main memory? Do you honestly think devices just independently begin writing to main memory (aside from memory NIC's) without any CPU intervention at all? Have you ever read up on what exactly is involved in setting up a DMA xfer? There is also the concept of uncacheable memory addresses maybe you should read up on that as well. I dub thee PigIgnorant. |
#56
| |||
| |||
|
|
I see your point on ethernet. But, why would any device (aside from NIC's) begin writing to memory *independently* without any CPU intervention? Even in the case of NIC xfers, we can make the memory buffer uncacheable (which would make a LOT of sense). I'm talking single CPU setups here, no dual-core. |
A device can be set to do so independantly of the CPU to offload
the interrupt/setup load from the CPU. This is especially
important when the CPU is loaded and would suffer high latency in
servicing the interrupt that would jeopardize the device buffer.
NICs are the obvious example, but other I/O cards (RS-422)
could qualify. Even disks in some (database?) applications.
Or imagine a DVD player that operates with minimum CPU
intervention: the drive drops into RAM, the GPU processes.
-- Robert
#57
| |||
| |||
|
|
If the CPU sets up the DMA xfer then it would KNOW about what memory addresses are about to be invalidated wouldn't it? I guess the problem is it doesn't know when they will be invalidated? |
if only it could recognize the incoming addresses. It can't.
When the CPU sets up transfers, it does nothing that the
cache hardware can recognize as potentially invalidating
lines. Just a series of OUT instructions to control ports.
Cache hardware does know which one is the address and which
is length. And these will vary for different controllers.
MOESI [qv] and cache snooping are the chosen solution, and
very handy for modern systems, almost all of which are SMP.
-- Robert
#58
| |||
| |||
|
|
Give me an example of a device (aside from a NIC or AGP card) that writes to memory without the CPU setting up the xfer in advance. Proof? |
--
Keith
|
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.