> -----Original Message-----
> From: iscsitarget-devel-bounces@...
> [mailto:iscsitarget-devel-bounces@...] On=20
> Behalf Of Dr. Net! - Eugen Rieck
> Sent: Monday, June 25, 2007 9:23 AM
> To: iscsitarget-devel@...
> Subject: Re: [Iscsitarget-devel] Proposal: New Hybrid IO Type
> Ross S. W. Walker schrieb:=20
> Let me know the different configs you have tried with=20
> the HD streams so I have an idea of what doesn't work.
> While we have tried lots of different configs, here is the essence:
> Write: blockio is superior by 30-100% - the better the=20
> hardware, the higher the lead (say: RAID-controller)
> Read: fileio is superior by 100-1000% - depending on number=20
> of spindles, readahead-settings and count of parallel streams per disk
I would assume that cache would be king for video streams.
I'm looking into the idea of a stackable cache driver that works
independently of IET, a generic one that should work on all block
devices. Maybe independent of any other driver, maybe as an add-on
> CPU doesn't matter (a simple Athlon X2 does everything you need)
CPU really matters when up are doing lots of small frame TCP packets
(1500 MTU) and large io requests or if you are using 10Gbps Ethernet,
as the CPU needs to handle the hundreds of thousands of interrupts
> RAM: scales excellent up to ca. 3 GB, no further improvement then
If you use a 64bit OS for the target RAM/Cache should scale linearly.
> NIC: Realtek is bad, Broadcom works perfect, Intel is even a=20
> bit better. (No "tuning" parameters, standard settings work best)
Not sure about the Broadcoms, but I find with the e1000 adapters if
you set InterruptThrottleRate=3D1 (adaptive-aggressive) it works well
> ietd.conf: most parameters have to be tuned on a=20
> server-per-server basis (with a few % significance)
> Posting a iet.conf doesn't really make sense, because they=20
> differ a lot.=20
> The above must be seen in the context of the initiators being=20
> completly different machines. MS initiator, no possibility of=20
> changing something on them (without violating the=20
> editing-software vendor's support policy). Most of them also=20
> use Broadcom, but there are some Intel. Latency varies by ca.=20
> 100% but this doesn't seem to be an issue (few but big IOs).
You can change the default session parameters for Microsoft
2BE10318}\<iSCSI Virtual Adapter Number>\Parameters
> BlockIO would be perfect, apart 2 facts:
> A) we need either readahead or an insane number of spindles -=20
> hard to work around
An independent read-ahead driver would fix this I bet.
> B) Having the storage volumes as regular files is nice (but=20
> definitly no must)
Using sparse files as storage targets will limit this to fileio
and with fileio the only way to handle large requests is to
use O_DIRECT and readv/writev.
> Any more I can gibe an idea of?
If your software uses large io request sizes, which I think it
does, then you will probably benefit from jumbo frames which
trades latency for throughput, and it seems in your application
that throughput is your bottleneck.
With jumbo frames, round-robin multi-pathing and blockio on a
target with 4 interfaces it is possible to drive 400MB/s for
Instead of having all your editing stations hit the back-end
storage directly, if you set up a storage concentrator as
the front-end and re-export the back-end then you may get some
added performance through combining and caching. You can also
abstract the back-end storage so you can move storage targets
and provide redundancy without having to re-configure the
initiators (which could be iSCSI or NFS/CIFS clients too).
Did mounting an NFS share on top of a local cache partition
solve the licensing problem? If you can get a caching mount
going it may also solve some of your performance problems
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.