Comments on: I’M BAAACK, and I’m Rested http://blogs.hds.com/claus/2007/08/im_baaack_and_im_rested.html Thu, 21 Aug 2008 19:34:11 +0000 http://wordpress.org/?v=2.0.4 by: Barry Whyte http://blogs.hds.com/claus/2007/08/im_baaack_and_im_rested.html#comment-9651 Mon, 15 Oct 2007 19:45:41 +0000 http://blogs.hds.com/claus/2007/08/im_baaack_and_im_rested.html#comment-9651 Claus, Thanks for the response. I can see the advantage of having a lot of archive type storage attached behind the USP/V controllers, especially with the 'MAID' style function. I think the IBM model and HDS model of virtualization is probably closer than flow-through designs which are limited in the services they can provide, and the idea of a virtualizing controller has its merits. As far as the 3.5 million IOPs, I know this is a 'super read cache hit' number - do you have details of the actual number that USP-V can achieve when reading from actual physical cache and not just the front end FC hardware? IBM choses not to publish its 'read cache hit' 512 byte numbers as they are unrepresentative of any known customer workload and so would lead us open to similar comments like "where's the other 3.3 million IOPS gone" when we submitted our SPC benchmarks. But I can tell you that our true read cache hit (actually from cache) is not that far behind your 3.5 million. Not bad for a commodity hardware with a non-disruptive hardware upgrade strategy :) Claus,

Thanks for the response. I can see the advantage of having a lot of archive type storage attached behind the USP/V controllers, especially with the ‘MAID’ style function. I think the IBM model and HDS model of virtualization is probably closer than flow-through designs which are limited in the services they can provide, and the idea of a virtualizing controller has its merits.

As far as the 3.5 million IOPs, I know this is a ’super read cache hit’ number - do you have details of the actual number that USP-V can achieve when reading from actual physical cache and not just the front end FC hardware?

IBM choses not to publish its ‘read cache hit’ 512 byte numbers as they are unrepresentative of any known customer workload and so would lead us open to similar comments like “where’s the other 3.3 million IOPS gone” when we submitted our SPC benchmarks. But I can tell you that our true read cache hit (actually from cache) is not that far behind your 3.5 million. Not bad for a commodity hardware with a non-disruptive hardware upgrade strategy :)

]]> by: claus http://blogs.hds.com/claus/2007/08/im_baaack_and_im_rested.html#comment-9290 Tue, 02 Oct 2007 18:12:58 +0000 http://blogs.hds.com/claus/2007/08/im_baaack_and_im_rested.html#comment-9290 Firstly, the number is (only!) 247PB of addressing capacity in external storage, not 296PB. That said, we already have customers with many PB's of external storage and one approaching 10PB and growing and I think that's pretty impressive. Will anyone ever reach 247PB? Perhaps. With our recently announced "power down" feature of our midrange AMS line, this becomes an archivers dream. That is, growing to PB of external storage is a capacity play, not just an IOPS play. So your IOPS math, although interesting, is based on assumptions that all external storage is "active". Having all your storage (SAN, NAS, Archiving, VTL, mainframe, open systems, etc.)in a pool of storage managed from a single interface, is quite compelling. As far as the 3 million IOPS (actually, it's 3.5 million), you guys should be so lucky! Firstly, the number is (only!) 247PB of addressing capacity in external storage, not 296PB. That said, we already have customers with many PB’s of external storage and one approaching 10PB and growing and I think that’s pretty impressive. Will anyone ever reach 247PB? Perhaps. With our recently announced “power down” feature of our midrange AMS line, this becomes an archivers dream. That is, growing to PB of external storage is a capacity play, not just an IOPS play. So your IOPS math, although interesting, is based on assumptions that all external storage is “active”. Having all your storage (SAN, NAS, Archiving, VTL, mainframe, open systems, etc.)in a pool of storage managed from a single interface, is quite compelling.

As far as the 3 million IOPS (actually, it’s 3.5 million), you guys should be so lucky!

]]> by: Barry Whyte http://blogs.hds.com/claus/2007/08/im_baaack_and_im_rested.html#comment-8522 Thu, 23 Aug 2007 21:22:09 +0000 http://blogs.hds.com/claus/2007/08/im_baaack_and_im_rested.html#comment-8522 WB Claus, So I've quizzed Hu about the marketing figure of 296PB of external attach. He's neglected to post my comments, hopefully you will. So lets assume all of that 296PB is 750GB SATA drives that can handle about 80 IOPS each. Scaling that up, thats over 31 MILLION IOPs... even if they are only 25% busy thats almost 8 MILLION IOPs. Now just how can you claim this level of support with a system that istelf can only do 3 MILLION read cache hits - especially when the cache isn't supported on the external attach.... ? Is this marketing figure really something thats worth mentioning in practice ??? Further I understand there is a limit of about 12K IOPS per port, so that would need 660 ports to attach and make use of the 25%... or 2640 ports for 100% use... What would you say is a REALISTIC external attach capacity? WB Claus,

So I’ve quizzed Hu about the marketing figure of 296PB of external attach. He’s neglected to post my comments, hopefully you will.

So lets assume all of that 296PB is 750GB SATA drives that can handle about 80 IOPS each. Scaling that up, thats over 31 MILLION IOPs… even if they are only 25% busy thats almost 8 MILLION IOPs. Now just how can you claim this level of support with a system that istelf can only do 3 MILLION read cache hits - especially when the cache isn’t supported on the external attach…. ? Is this marketing figure really something thats worth mentioning in practice ???

Further I understand there is a limit of about 12K IOPS per port, so that would need 660 ports to attach and make use of the 25%… or 2640 ports for 100% use…

What would you say is a REALISTIC external attach capacity?

]]>