mm said:
I should ask you about the metal heat spreader. Seems like a good
idea but Kingston and Crucial don't use them afaik.
In some cases, heat spreaders are used for the purpose, of hiding
the chip numbers. Or perhaps UTT RAM is under there (a lesser grade
of memory, where the testing is done by the module manufacturer).
The module maker, is never as good as the factory, at testing chips.
"What are UTT Memory ?"
http://www.simmtester.com/page/news/showpubnews.asp?num=124
Especially on DDR3, there probably is no need of a heat spreader.
Module power is around 2 watts or less. DDR2 is a similar situation.
Perhaps with an abusive level of VDimm applied to the module,
the spreader helps. But the spreader also blocks the air channel
between DIMM slots, so in fact the spreader, depending on design,
can actually work against keeping a reasonable chip temperature.
The only time a heat spreader was really mandatory, was with RDIMM
designs (RAMBUS). That is a different memory architecture, where
an individual chip on the module can be accessed, and that chip
gets hot. Due to the possibility of hot spots, RAMBUS modules have
heat spreaders riveted to the module. You get two functions that
way - chip numbers are hidden, but with the rivets, it's less
likely the user will remove the heat spreader.
http://upload.wikimedia.org/wikipedia/commons/thumb/d/df/RAMBUS-Memory.jpg/800px-RAMBUS-Memory.jpg
(Chips were connected serially on those modules. One chip would respond
to a query. Continuous probing of a single chip, can cause the chip
to dissipate, maybe at a guess, about 4 watts. That was an estimate I
saw at the time, for how much power the package the chip was in,
would have to dissipate.)
http://web.archive.org/web/20001010...com/paedia/r/ram_guide/ram_guide.part3-6.html
( same as
http://arstechnica.com/paedia/r/ram_guide/ram_guide.part3-6.html,
only the archived copy still has the picture )
OT for this ng - I'm in "trouble" in another newsgroup because when
installing windows, I didn't install the Dell Chipset driver from the
CD that came with the computer. Yet everything so far seem to be
working fine. Should I install that driver now -- they say it has to
be done first? Or format the partition and reinstall Windows, doing
that driver first? This was meant to be a trial install anyhow.
Chipset drivers can be bundled with the OS. If you had a WinXP SP3
installer CD for example, it's possible the release date of that,
might be "after 865G". In which case, the chipset driver might
already be there. The thing is, the only thing that has to be
immediately resolved, is storage driver. And that can be resolved
by pressing F6 and putting a custom driver into place (like if
your board had RAID, and you were doing an OS install to the RAID).
The other elements of chipset drivers, may include network interfaces,
something for the AGP slot, and so on. The reason the video can
start without it, is the hardware supports VESA mode and the video
card has a VESA BIOS, and the bus path to the video card (or built-in),
may have a "PCI look" to it. The end result, is the OS can work at 640x480
in low color, right after you install. It means, you can install
drivers out of order at that point in time, if you wish. The
operating system enforces proper resolution, via the number of
reboots. So if you do things in the wrong order, it probably
results in more reboots than are absolutely necessary.
As a result, I wouldn't say "chipset driver package is critical".
It is a component in making a "clean Device Manager", it can
enable some other components to work properly (and they will,
after enough reboots, that any dependencies can be recognized
and resolved). But you could run the OS with its 640x480 screen
and no working network if you wanted, and get some work done.
The question would be, whether you could get data back out of the
system when you wanted to. Perhaps a hard drive on a removable
tray, would be your data interface, as an example.
You could always make a claim, that just about any driver was
critical (if the function it provided was something you needed
at the moment). The chipset drivers have their place, but
there's no "emergency" there.
I've also read of suggestions, to install OS, install latest
service pack, and then install chipset drivers. That is on the
theory, that the chipset driver package behaves differently
when a later Service Pack is present. Perhaps, but I'm not
really sure that's true or not. But by delaying the chipset
installation, you'd sure be violating what the other people
were saying about installing them right away.
In my work with installing graphics drivers, I noticed that
the system remained working, no matter what order I did them
in. Once the "driver stack" realized the state of something
underneath it, had changed, on the next reboot, that layer
of the stack could take advantage of the change. So an AGP
card, operating in PCI mode, once the AGP driver was in place,
would then have the option of using AGP commands, using the
GART and so on. The clever people who designed this stuff,
set it up in such a way, that you'd always have some level
of functionality, and that level would improve, the more
drivers that got installed.
The reverse of that, happens with storage drivers. There,
the hardware manufacturers seem to be determined, to put
as many roadblocks in your path as possible. They make
it virtually impossible, to switch from IDE to RAID for
example. In that case, VEN/DEV/SUBSYS/ClassCode are used
like a stick, to beat the user into submission. That has
improved a tiny bit in Windows 7, where at least you
can "arm" the OS just before shutdown, to re-examine
the hardware and available driver on the next restart.
But many WinXP RAID situations, it can be very hard
to make changes like that. And since hacks exist, to make
it smoother, it implies there was no need to make it so
hard in the first place. Presumably, the belief was, by
preventing mode changes, between IDE, AHCI, RAID, there
would be fewer support phone calls.
Some chipset drivers are "stubs". What they do, is remove
the "whining" of the New Hardware wizard. The only tangible
thing they offer, is an identity string for Device Manager,
so the item gets a proper label. So not all components of
the chipset driver package, are significant from a technical
standpoint.
Take USB as an example. Microsoft "owns" the USB drivers. If
you examine one of those old chipset driver packages (like
the one you'll be using for your 865G), you'll find the
Intel USB driver, just "calls" the Microsoft driver, to
get any work done. In that case, Intel didn't "write code",
as much as just redirecting the installation to stuff
already built into Windows.
That's why, if you do this work all the time, it pays to
look at the INF files that are part of the chipset drivers.
They'll tell you a few things, about what is actually
going on, and how things get done. (When I look at them,
it's just a hobby.)
Paul
