Dave Smith wrote:
> I have a machine built around a P5B Deluxe MB. Originally it had a
> Core 2 6600 proc which I just replaced with a Quad 9550. It has 4GB
> Micron DDR2 memory and a Maxtor 160GB C drive with two 500GB storage
> drives.
>
> The problem is that some programs seem to take far too long to load
> the first time. For example, ACDsee 3.1 takes 9-10 seconds to load
> the first time I use it after booting up. After that, it's almost
> instantaneous. The same program takes about 1-2 seconds max to load
> first time on my other comp with a P5Q-EM and also with previous other
> machines. Some other programs, like Photoshop CS4, seem to load
> fairly quickly.
>
> Anyone have any ideas why this is? Any help would be much
> appreciated.
>
> Dave
You can monitor the startup process, by using the Performance display
in Windows, and selecting PhysicalDisk read bytes/sec and write bytes/sec.
That would allow you to watch the loading process on the first attempt.
What you'd be looking for, is whether program execution results in
immediate disk activity, or whether there is a delay.
http://www.serverwatch.com/img/perf1.jpg
There are various small utilities, that set the "Affinity" bit for the
program at launch. By default, on your new setup, if you open Task
Manager and check the Affinity setting for a running program, all
four tick boxes will be set. Meaning, the program can migrate from
core to core. Sometimes, a program will misbehave, when in a
multicore environment, and you can experiment with the affinity
setting, to see if it helps or not. But to set the affinity, while
the program is launching (and not yet in Task Manager), a third party
app is a way to do it. Runfirst is one example. There are more of these
program concepts around. You can make a shortcut icon, with something
like "runfirst acdsee.exe" or whatever. That starts acdsee running
on one core only, with no opportunity to migrate (until you go to Task
Manager and change the setting).
http://www.softpedia.com/get/System/...RunFirst.shtml
A program like Photoshop, should not be run with Affinity restricted
to just one core, because some of the filters are multithreaded. So if you
used something like "PSBench" benchmark, the benchmark should show slower results
for the filters that use multiple cores. Some versions of Photoshop seem
to have an issue with the quad, and there is some kind of patch, so that
instead of using two cores, it'll use four cores. You can see this in
some of the Tomshardware charts - it looks like Photoshop is not taking
advantage of all four cores. It is one of the things I check for, if I happen
to be looking at that particular chart.
So perhaps with some monitoring applications, you can get an idea of what
resource is the issue. For example, if you see no disk activity for the
first five seconds, and then normal looking byte per second rates while
ACDSee loads, that might signify an issue with reading that area of the
disk, or even an issue with the disk driver itself. There used to be
a problem like that, with SIS Southbridges, but I've never heard of
a similar problem with Intel Southbridges.
Sysinternals.com (now owned by Microsoft) is another source of monitoring
utilities. In this case though, I don't know of anything suspicious you might
monitor with Process Explorer. Process Explorer does display Deferred Procedure
Calls (DPC), which is a way of completing interrupt handlers at user level,
which means less delay in servicing other interrupts. Some owners of
motherboards with Intel chipsets have noticed high latency in getting
a DPC serviced, which may be fixed by updated software or BIOS from the
manufacturer. (That is a microsecond to millisecond issue, and not likely
the source of your problem. But, it is something to check on a new system
setup.)
http://en.wikipedia.org/wiki/Deferred_Procedure_Call
An activity that can cause "DPC spiking" is SMM. SMM totally takes over the computer,
and is not visible to the user. Improper usage of SMM, can cause the spiking.
http://en.wikipedia.org/wiki/System_Management_Mode
As a "health check" for a computer, you can use the DPC Latency Checker. I
have version V1.1.0 here, and have only run it a couple of times for a look.
This checks to see how long it takes a DPC to get serviced. I think it is
possible for SMM activity (which runs transparently in the background),
to basically make the computer unresponsive for periods of milliseconds.
I treat this as a "health check" issue, in that for the computer to be
properly responsive, there shouldn't be a lot of spiking in DPC latency.
I'm only mentioning this, as another thing you can look at - I don't see
any mechanism, why this would cause slow load times. But it is one of
the few other stats you can look at.
http://www.thesycon.de/deu/latency_check.shtml
The Windows Performance plugin (the very first picture at the top of this post),
does have a number of counters to monitor in the "Memory" section, but I've
never needed to look at them. Again, perhaps if you monitored some of those,
for the period of time the system seems unresponsive/not loading etc., you
can see something abnormal.
In your System control panel, a couple of levels down (click a couple of
Advanced buttons), there is a control for "Memory Usage", which can be
set to "Programs" or to "System Cache". Apparently, the latter option is
good if the computer is running as a file server. I don't know how much
that would slow up the computer, if the System Cache needed to be flushed,
to make room for a program to load. I've always left mine at the default
setting of "Programs".
It could even be your AV software doing something...
Paul