EVA 8400 Processor Speed

[BrianPB]

Anyone know the Processor Speed of the 8400's controllers? Have they gone to 64bit? Or is it still 32bit?

[Steven Clementi]

Why would this even matter? (Just wondering)

[Víctor Cespón]

I don't think that has been published anywhere public, but anyway it's irrelevant, the controller CPU has never been limiting the performance on an EVA.

Moving to 4 or 8 GB of cache per controller, and to SSD drives gives a much bigger performance improvement.

[BrianPB]

Not thinking about performance per se, but it seems like scalability is lacking slightly in the 8400. Was hoping for something more. Wondering if processor speed limits the amount of drives the back end can handle.

[Víctor Cespón]

Can't follow your logic. The CPU on an EVA8000, even fully loaded with 18 enclosures seldom goes above 20%.

The 8400 has 20% more performance, 3 independent loop pairs with 9 enclosures, 108 drives per loop.

The limit for I/O are always the disk drives. Assumming a typical 8K I/O size, and a maximum 150 I/Os per drive (15K drives), that's 1.2 MB/s per drive or 130 MB/s per loop. The backend is all 4 Gb/s, so...

[BrianPB]

Right. I guess I'm wondering why they limit the 8400 to 324 Drives. I can understand it with the 8000/8100 with the CAN switches, but you would think now that they have gone to the cascading disk shelves that they would have offered more capacity especially in the 8400. Thought it might have been processor limited, or perhaps just marketing... :)

[Víctor Cespón]

No, that's due to the FC_AL protocol. There are 127 AL_PAs per loop, you need 108 for the drives, 9 for the I/O modules and 2 for the controllers.

Not enough addresses to have 10 enclosures per loop. Anyway, the I/Os are daisy-chained, a packet has to pass through several I/Os to reach it's destination disk. Not good to have too many.

[Susan Tafolla]

what if the IO is 256K rather than 8K? the max IO per disk could be 256K x 150 ios/second?

[Patrick Terlisten]

Hello,

there is a german saying: "Haette, waere, wenn". You need 108 drives, with each drive delivering 150 IOPS with 256k IOs to fill up a 4 GB backend-loop. Sure you can do this, but that's theory.

Think about EMC² CLARiiONs which are still using Intel P4 CPUs on their storage processor.

The limiting factor are the loops, not the controller. The cache upgrade is more marketing then true need. HP no differs anymore the cache in differnt parts, cache is cache.

Best regards,
Patrick

[Kranti Mahmud]

Hi BrianPB,

Check this PDF: http://hp.sharedvue.net/sharedvue/resources/tsg-fg-storageworks_array.pdf


Rgds-Kranti

[Uwe Zessin]

Patrick,
a single "4 GB backend-loop" has a bandwidth of 400 MegaBytes per second, not 4,000.

[Patrick Terlisten]

Hello Uwe,

you're right, my fault. Maybe I should repeat some classes in primary school to refresh my knowledge in elementary mathematics. :-|

Best regards,
Patrick

[Torsten.]

I found a source that talks about the processor:

http://de.wikipedia.org/wiki/Enterprise_Virtual_Array

Sorry, I did not found something in english wiki.

It says, PowerPC CPUs are used, but I don't think this is relevant for overall array performance in any way.
BTW, some of them have even 128bit processing in certain units, AFAIK.

[Patrick Terlisten]

Hello Torsten,

I wrote the first version this wiki article nearly a year ago. I don't know if the PPC cpu is doing all the work, rather I think that the PPC is supported by some other special ASIC. There is another hint in the OCP menu under "System Information -> PIC -> PowerPC Processor".

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c00365593

Best regards,
Patrick

[Torsten.]

Nice work.
I know for sure it is a PPC CPU :-) but it doesn't really matter.

[Uwe Zessin]

> some other

There are a number of special ASICs to do the work.

[Jeffrey Wolfanger]

Well the CPU on 8400s do often go above 20% in production I see them as high as 90 with a mean at 70% and that is far from fully loaded. So to the comments on to why it matters and 8400 isnt an 8000 and it does matter.

[DavidWarburton]

I'm having the same problem with our 8400 too.

We had some really weird issues where one controller would be happily hovering around the 30% CPU usage but the other would either be at 0% or shoot up to 90%+ (either quick spikes or sustained for about 10-20 seconds).

I moved a really heavily used LUN to the other controller and both controllers are now much more evenly matched - sadly both controllers are now steady between 70-90% !!!

All these LUNs were previously on an 8100 and although I don't have any stats to back up my thoughts, we didn't seem to be suffering from such bad performance!

Can anyone give me any tips as to what's causing such high CPU usage? I mean I can see what LUNs have high IO and high latency, but I wouldn't have thought that CPU usage should EVER get this high (at least not sustained).