| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 8980.1 | might be fault of KZPAA | namix.fno.dec.com::jpt | FIS and Chips | Mon Mar 03 1997 04:37 | 20 |
|
Umh,
First you should of course check that there are no error
log entries related to CAM or other critical components.
Anyway, it is possible, that KZPAA itself causes the problems,
as it is VERY poor controller! You may have hit for example
situation where system has been cpu bound, and adding yet
another cpu-hog (KZPAA) causes you critical cpu bottleneck.
It's also possible, that if you have any critucal files behind
the KZPAA, you may have hit its io limitations andcaused an io
bottleneck.
More details would help to make better guesses...
-jari
|
| 8980.2 | ..more inputs..kzpaa.. | QCAV01::INETPUNE | | Tue Mar 04 1997 00:56 | 32 |
| hello jari ;
thanks for the reply.
but still i have a doubt.
i have a customer who has a sable running alpha-vms.
he has a kzpaa controller and system disk on integrated controller has been
shadowed onto the disk attached to kzpaa controller.
there , i donot found any performance degradation.( as per your reply , the
kzpaa is poor controller and hogs a lot of cpu time.)
anyway i am going to try one thing , i will remove either cdrom or dat drive
and connect the disk attached to kzpaa controller to integrated controller
and see the difference.
if there is appreciable difference , then i will have to think of replacing
the kzpaa controller by another suitable one.
but as the system is used for online application , hence getting back to you
wil take a long time.
until thnen....
best regards....
mahesh r gune
customer support
digital india
|
| 8980.3 | cpu load? io load? memory? errors? | namix.fno.dec.com::jpt | FIS and Chips | Tue Mar 04 1997 03:49 | 18 |
|
I'm not sure if what you're trying will change anything, as 2x00 series
embedded (internal) SCSI uses the same chip (NCR810) as KZPAA,
and 2x00 series embedded SCSI can't be expected to give good
performance.
Also, knowing that KZPAA serves someone else well enough does not
prove that it serves someone ese as well if you don't have
exactly similar load profiles. For example, the system that sees
problems with new adapter might have been short of cpu power
already, and adding cpu-hog KZPAA may have been the thing that
really brings in light the cpu bottleneck that has "Lurked
behind the corner" this far. This is only one possible
scenario, and because of this, it would be VERY useful to
provide at least information about vmstat/iostat and uerf
to give better chances to make right justifications.
-jari
|
| 8980.4 | Host bus HOG, not CPU hog. | SMURF::KNIGHT | Fred Knight | Tue Mar 04 1997 11:32 | 6 |
| Just so no one gets confused, the KZPAA isn't really that
big of a CPU hog. It IS however a really big host bus HOG.
The end result, is that the CPU can't do work (because the
bus is busy), but it never shows up as CPU time.
Fred
|
| 8980.5 | eats more cpu than KZPSA (for example) | namix.fno.dec.com::jpt | FIS and Chips | Tue Mar 04 1997 15:36 | 21 |
| >Just so no one gets confused, the KZPAA isn't really that
>big of a CPU hog. It IS however a really big host bus HOG.
>The end result, is that the CPU can't do work (because the
>bus is busy), but it never shows up as CPU time.
<RAT-HOLE-ALERT>
Fred, I always trust you when you tell anything SCSI related ;-)
My comment on cpu-hogness was based on two things:
- Our experiences with KZPAA/RZ28/RZ28B combination
and comparing it against other adapters
- StorageWorks performance characterisations with
KZPAA compared to other adapters
Anyway, It might be so that in this case the "host-bus-hogness"
might be the reason. Our study was system where additional load
generated by KZPAA killed the database resonse times...
</RAT-HOLE-ALERT>
|