Yes, I've been using it without Jumbo Frames for almost a year. I get about 75MB/s up and down. It's pretty good, but I need to improve it. Also, there are some latency issues. I sometimes get "dropped frames" when capturing video to it. Everyone I've spoken to says the Jumbo Frames is a must for this type of application. My switch and all components are set to use Jumbo Frames.
The disks are nowhere even close to being a bottleneck. It's a 3ware controller, 256kb block size with write cache enabled. And as I said, the write speed only goes down a lot when Jumbo Frames are enabled.
The default settings on Atto XtendSAN v2.0 have all burst lenghts's very high compared to the Open-E's default settings (1048576). The Open-E settings seem to override them anyways.
Thanks for posting that link, but it's really just a description of what the code lines are to configure it. It doesn't explain what things like InitialR2T and ImmediateData mean.
Try to test the system and review the results using this system status for CPU, Memory... https://x.x.x.x/check_sys/127.0.0.1.html on the iSCSI server (has this been updated to Version 172 Build 2512) . Check to see if all firmwares have been updated. Some testing on all levels will need to be performed. Again, on the internet there are many areas that talk about these subjects from your inquires of what do they mean " InitialR2T and ImmediateData" .
InitialR2T
The InitialR2T key is used to turn off the default use of R2T for
unidirectional and the output part of bidirectional commands, thus
allowing an initiator to start sending data to a target as if it has
received an initial R2T with Buffer Offset=Immediate Data Length and
Desired Data Transfer Length=(min(FirstBurstLength, Expected Data
Transfer Length) - Received Immediate Data Length).
The default action is that R2T is required, unless both the initiator
and the target send this key-pair attribute specifying InitialR2T=No.
Only the first outgoing data burst (immediate data and/or separate
PDUs) can be sent unsolicited (i.e., not requiring an explicit R2T).
ImmediateData
The initiator and target negotiate support for immediate data. To
turn immediate data off, the initiator or target must state its
desire to do so. ImmediateData can be turned on if both the
initiator and target have ImmediateData=Yes.
If ImmediateData is set to Yes and InitialR2T is set to Yes
(default), then only immediate data are accepted in the first burst.
If ImmediateData is set to No and InitialR2T is set to Yes, then the
initiator MUST NOT send unsolicited data and the target MUST reject
unsolicited data with the corresponding response code.
If ImmediateData is set to No and InitialR2T is set to No, then the
initiator MUST NOT send unsolicited immediate data, but MAY send one
unsolicited burst of Data-Out PDUs.
If ImmediateData is set to Yes and InitialR2T is set to No, then the
initiator MAY send unsolicited immediate data and/or one unsolicited
burst of Data-Out PDUs.
MaxRecvDataSegmentLength
The initiator or target declares the maximum data segment length in
bytes it can receive in an iSCSI PDU.
The transmitter (initiator or target) is required to send PDUs with a
data segment that does not exceed MaxRecvDataSegmentLength of the
receiver.
A target receiver is additionally limited by MaxBurstLength for
solicited data and FirstBurstLength for unsolicited data. An
initiator MUST NOT send solicited PDUs exceeding MaxBurstLength nor
unsolicited PDUs exceeding FirstBurstLength (or
FirstBurstLength-Immediate Data Length if immediate data were sent).
MaxBurstLength
The initiator and target negotiate maximum SCSI data payload in bytes
in a Data-In or a solicited Data-Out iSCSI sequence. A sequence
consists of one or more consecutive Data-In or Data-Out PDUs that end
with a Data-In or Data-Out PDU with the F bit set to one.
FirstBurstLength
The initiator and target negotiate the maximum amount in bytes of
unsolicited data an iSCSI initiator may send to the target during the
execution of a single SCSI command. This covers the immediate data
(if any) and the sequence of unsolicited Data-Out PDUs (if any) that
follow the command.
FirstBurstLength MUST NOT exceed MaxBurstLength.
DefaultTime2Wait
The initiator and target negotiate the minimum time, in seconds, to
wait before attempting an explicit/implicit logout or an active task
reassignment after an unexpected connection termination or a
connection reset.
A value of 0 indicates that logout or active task reassignment can be
attempted immediately.
Thanks for the detailed post, and I also found some other websites with good info. Unfortunately it's a bit over my head. I'm just don't understand the discrepancies between the default settings on Open-E and the initiators' default settings.
Open-E has R2T on by default, and ImmediateData off. Both Atto and MS initiators have the opposite by default.
Open-E default max data segment length (send and receive) is 8k. MS default receive is 512k and Atto is 1M.
Open-E default first burst length is 65k. MS is 512k, Atto is 1M.
Open-E default max burst length is 256k. Again, MS is 512k and Atto is 1M.
Sorry, forgive my ignorance. I'm just confused by the whole thing.
Our engineers decided these where the best tested default settings from many tests. Additionaly alowing you to adjust some of the perameters in our daemon acordingly to be matched with the approved initiatotoers. Many adjustemnst can be made as you are experincing just as long as you keep them the same on both sides. Many other manufactures have different settings as well. I use this site below to perform many different test and this might help in your research for your environment as no two environments are usually the same.
Reply With Quote
