lkml.org 
[lkml]   [2009]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Scst-devel] [ANNOUNCE]: Comparison of features sets between different SCSI targets (SCST, STGT, IET, LIO)
Tomasz Chmielewski, on 04/04/2009 11:12 PM wrote:
> Vladislav Bolkhovitin schrieb:
>> Hi All,
>>
>> I set up http://scst.sourceforge.net/comparison.html page, which
>> compares features of existing SCSI target subsystems for Linux. The
>> comparison includes SCST, STGT, IET and LIO.
>>
>> I might be not fully correct somewhere, so, if you don't agree with me
>> about some item(s) in the comparison table, please let me know and I
>> will fix that.
>
> Performance is a bit debatable.

The result "in average" was listed in the comparison. Of course, one
target can be better somewhere, another one somewhere else. That a
nature of storage: it's pretty hard to optimize for all at once.

BTW, if I remember correctly your logs, you didn't apply all the SCST
kernel patches on your kernel. Then your results aren't much applicable
to this comparison, because it assumes all SCST kernel patches applied.

> I made some simple SCST and STGT tests last week, there were some where
> SCST won, there were some where STGT won.
>
> What was surprising to me, although STGT has a bigger CPU impact than
> SCST, STGT was faster when reading from an encrypted (dm-crypt) volume,
> on a system where the CPU is the bottleneck (it can't decrypt as fast as
> HDD can deliver data).
>
> STGT was much slower when reading from a non-encrypted volume, when
> target had "blockdev --setra 16384 ..." for a given target.
> On the other hand, STGT was faster than SCST with default blockdev
> readahead settings (256).
>
> If anyone's interested, I can show results in a readable form on Monday
> (right now, I have only raw data which is pretty long and would be hard
> to compare).
>
>
>



\
 
 \ /
  Last update: 2009-04-04 21:23    [W:0.089 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site