[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] Announcement: STEC EnhanceIO SSD caching software for Linux kernel

> -----Original Message-----
> From: Jason Warr [mailto:jason warr net]
> Sent: Friday, January 18, 2013 10:15 PM
> To: Amit Kale; device-mapper development; kent overstreet gmail com;
> Mike Snitzer; LKML; linux-bcache vger kernel org
> Subject: Re: [dm-devel] Announcement: STEC EnhanceIO SSD caching
> software for Linux kernel
> On 01/18/2013 10:11 AM, thornber redhat com wrote:
> > On Fri, Jan 18, 2013 at 09:56:19AM -0600, Jason Warr wrote:
> >> If I can help test and benchmark all three of these solutions please
> >> ask.  I have allot of hardware resources available to me and perhaps
> >> I can add value from an outsiders perspective.
> > We'd love your help.  Perhaps you could devise a test that represents
> > how you'd use it?
> >
> > - Joe
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-bcache" in the body of a message to majordomo vger kernel org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> As much as I dislike Oracle that is one of my primary applications.  I
> am attempting to get one of my customers to setup an Oracle instance
> that is modular in that I can move the storage around to fit a
> particular hardware setup and have a consistent benchmark that they use
> in the real world to gauge performance.  One of them is a debit card
> transaction clearing entity on multi-TB databases so latency REALLY
> matters there.  

I am curious as to how SSD latency matters so much in the overall transaction times.

We do a lot of performance measurements using SQL database benchmarks. Transaction times vary a lot depending on location of data, complexity of the transaction etc. Typically TPM (transactions per minute) is of primary interest for TPC-C.

> Hopefully I'll have a couple of them setup within a
> week.  At that point I may need help in getting the proper kernel trees
> and patch sets munged into a working kernel.  That seems to be the spot
> where I fall over most of the time.
> Unfortunately I probably could not share this specific setup but it is
> likely that I can derive a version from it that can be opened.

That'll be good. I'll check with our testing team whether they can run TPC-C comparisons for these three caching solutions.



This electronic transmission, and any documents attached hereto, may contain confidential, proprietary and/or legally privileged information. The information is intended only for use by the recipient named above. If you received this electronic message in error, please notify the sender and delete the electronic message. Any disclosure, copying, distribution, or use of the contents of information received in error is strictly prohibited, and violators will be pursued legally.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]