HP3000-L Archives

March 2005, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Paul, Guy (San/Storage Delivery)" <[log in to unmask]>
Reply To:
Paul, Guy (San/Storage Delivery)
Date:
Thu, 3 Mar 2005 12:42:14 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (214 lines)
 Craig,

A lot of your overhead could be coming from hba's that are not plugged
into anything.
Use TDUTIL <path> disable or better yet remove the unused HBA's

Also check that your PDC is 43.22 or greater
You should also have 7.5 PP2 installed which will have the
patch (MPEMXL0A) to fix hba chip freeze issues that will cause
performance problems.

To answer an earlier question about EMC and fiber channel..HP has never
supported
MPE systems connecting to EMC fiber channel. SYM4 EMC models and FW-SCSI
(HVD) are the only supported
EMC configurations.

Guy

> -----Original Message-----
> From: HP-3000 Systems Discussion 
> [mailto:[log in to unmask]] On Behalf Of Bill Lancaster
> Sent: Thursday, March 03, 2005 10:37 AM
> To: [log in to unmask]
> Subject: Re: Glance question
> 
> Craig,
> 
>  
> 
> I don't know that it would be a *lot* of overhead being 
> off-loaded.  If you could eliminate all of the overhead of 
> those pins you'd only be talking about ten percent overall.  
> Since the FW-SCSI cards are still pci-based it's going to 
> take some amount (maybe the same as what you are currently 
> experiencing) of the same overhead to manage those.  At this 
> point it still comes back to the question "Is this system CPU-bound?"
> If the system is CPU-bound you can look at switching to 
> FW-SCSI and gain
> *some* headroom back.  If the system isn't CPU-bound then it 
> doesn't matter and I would recommend leaving the fibre in.
> 
>  
> 
> As far as why HP no longer supports native fibre to the EMC I 
> would expect it's a combination of not wanting to enhance the 
> ability of competitors to work on the 3000 and lack of 
> testing resources in the lab.
> 
>  
> 
> Bill
> 
>  
> 
> ________________________________
> 
> From: Craig Lalley [mailto:[log in to unmask]]
> Sent: Thursday, March 03, 2005 9:28 AM
> To: Bill Lancaster; [log in to unmask]
> Subject: Re: Glance question
> 
>  
> 
> Bill,
> 
> 
> Very interesting thoughts.
> 
>  
> 
> It looks like a lot of overhead can be off-loaded by using 
> the A5150A fw-scsi channels.  But to have the high 
> availablity and speed of an
> XP512/1024 the fiber scsi switch MAY be the way to go.
> 
>  
> 
> Maybe thats why HP no longer supports native fiber to the EMC?
> 
>  
> 
> I do have two systems to compare, one with fiber and one with 
> FW-SCSI, it should be an interesting comparison.
> 
>  
> 
> Thanks for the thoughts.
> 
>  
> 
> -Craig
> 
> 
> 
> Bill Lancaster <[log in to unmask]> wrote: 
> 
> These are totally reasonable numbers given what they provide for.
> N-class I/O cards are, in general, fairly stupid, thus 
> requiring the CPU to manage. However, these cards, and of 
> course, their associated devices, are the only thing that 
> allows the extraordinary (by MPE's
> standards) level of I/O throughput.
> 
> The normalizing factor the Goetz mentions is an important 
> one. Since a pin can only take CPU on one processor at a time 
> you should divide those numbers by the number of processors 
> to get the "real" number. Also keep in mind the N-class boxes 
> all seem to take a lot more CPU (in a relative
> sense) managing overhead (in particular, managing disk I/O). 
> I've seen systems that take 35 percent of the available CPU 
> managing disk I/O.
> 
> Is this an acceptable level of CPU utilization? Well, it 
> depends. What is the level of I/O required for the 
> application environment? We recently saw some data regarding 
> a similar system aggregating over 1500 I/O's per second, and 
> it didn't appear to even be breathing hard.
> 
> If the system is CPU bound, that's a different story. I'm 
> working with a customer who has a four-way N-4000 750, with 
> lots of growth potential in the business. They are currently 
> using F/W SCSI with Mirrored Disk/iX. My recommendation to 
> them is that they keep the current disk environment rather 
> than upgrade to faster I/O (Fibre) that would likely push 
> them over the top in terms of current CPU utilization and 
> remove all chance for expansion for the future.
> 
> This is a very obstinate place to be in the product line. The 
> only solutions are hard ones.
> 
> Bill
> 
> -----Original Message-----
> From: HP-3000 Systems Discussion 
> [mailto:[log in to unmask]] On Behalf Of Goetz Neumann
> Sent: Wednesday, March 02, 2005 11:02 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] Glance question
> 
> Craig asks:
> 
> > I continuely see these processes on the top of Glance.
> >
> > This is an N-class 550/300
> >
> > P2 SYS MANAGER.SYS 2 LOAD B142 2.0% 0.0 0 0.0
> MISC
> > P3 SYS MANAGER.SYS 3 B100 1.7% 0.0 0 0.0
> MISC
> > P4 SYS MANAGER.SYS 4 A 0 4.2% 0.0 0 0.0
> MSG
> > P5 SYS MANAGER.SYS 5 A 0 4.4% 0.0 0 0.0
> MSG
> > P6 SYS MANAGER.SYS 6 A 0 4.4% 0.0 0 0.0
> MSG
> > P7 SYS MANAGER.SYS 7 A 0 4.3% 0.0 0 0.0
> MSG
> > P8 SYS MANAGER.SYS 8 A 0 4.4% 0.0 0 0.0
> MSG
> > P9 SYS MANAGER.SYS 9 A 0 7.1% 0.0 0 0.0
> MSG
> >
> 
> > That's 32.5% overhead!
> 
> It would be, if you had only 1 CPU . but you have 3 .
> I.e. 'overhead' is ~ 11% .
> 
> > Does anybody know what is happening?
> 
> Pin 2 is LOAD.PUB.SYS used to load CM programs (FCOPY, DSCOPY 
> ?) and CM/SL library code of the OS or your applications.
> 
> Pin 3 is pm_cleanup, used to clean the remains of dead 
> processes (like deleting the stack, heap, etc) from memory. 
> 1.7 % might mean you have a higher than usual process 
> creation and termination rate.
> 
> Pins 4..9 are different on 7.5 compared to earlier releases.
> In very simple terms they are Fibre Channel's IO facilitating 
> processes (called PFPs - port facility process) . I do not 
> have ballpark numbers for what is "normal", it might simply 
> be that your system is doing a higher number of FibreChannel 
> IOs, or that something on your FC loop or SAN is very 'talkative'.
> 
> If your DISC screen in Glance shows the system as IO idle, 
> and you still get >= 4% CPU per process (pins 4..9) _then_ I 
> would think something is not ok.
> 
> 
> Goetz
> 
> PS: 'posting via email (reply to the DIGEST), the new news 
> gateway seems not operational yet?'
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection 
> around http://mail.yahoo.com 
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> 

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2