Visit Open-E website
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: iSCSI R3 Enterprise performance tuning

  1. #11
    Join Date
    Jun 2007
    Posts
    84

    Default

    I tested some things:

    Used a additional Reaktek GigaBit NIC, but the IOMeter read speed was only 7 MB/s and the write speed like the Intel NIC at 40 MB/s.

    I tested with the multiprocessor and sigleprocessor testing kernels, but all the same...

    I updated the Firmware of the 3Ware to the last one, but no change.

    Some questions:

    - What is the better enviroment: Direct links from the target to the initiator with a single cable or is it better to use a switch.

    - Can i test the network performance from the initiator to the target and ignore the performance of the raid?

    - What must i do to configure the NIC to 1000 FullDuplex fix, no autodetection.

    Regards
    Stefan

  2. #12

    Default

    Maybe disabling Flow control will help. Try changing this from the Console Tools in ALT+CTRL+T -> Modify driver option function. Any option will need to restart system. Sometimes forcing the speed value parameters may work for some NICs also look to see what the AutoNeg is set to (Intel NICs are set to 32).
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  3. #13
    Join Date
    Jun 2007
    Posts
    84

    Default

    But what must i enter in the fields for "FlowControl", "AutoNeg", "Duplex" and "Speed" to set them?

    I don't think that this will help, because a few hours ago i startet my restore again, this data will go with eth1 into the storage and runs with 70 MBit/s (from check_sys). In ESX i saw a speed of 8 MB/s. Then i started a IOMeter from my workstation which is connected to eth0 and got 30-35 MB/s but in this moment the speed in ESX goes down to 500 KB/s. Wehen i stop IOMeter the speed in ESX goes up again... But i will leave nothing untested.

    The best will be when i can made a networking test, to see what performance i got when i made this on one NIC and then on two and final at all three NIC's.

    Regards
    Stefan

  4. #14
    Join Date
    Jun 2007
    Posts
    84

    Default

    I configured with now FlowControl and fix at 1000 Full Duplex, but no change...

    Can this be a hardware issue?

    I use this Supermicro Board: PDSM4

    Are there recommendations which board i can use with a 3Ware RAID and some Intel NIC's?

    Regards
    Stefan

  5. #15

    Default

    Try with the Intel Pro 1000 and tell me what you have for the driver settings. Here is the link for Intel settings:

    http://www.intel.com/support/network/sb/cs-009209.htm?
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  6. #16
    Join Date
    Jun 2007
    Posts
    84

    Default

    I tryed to set the FlowCotrol to 0 and the AutoNeg to 32.

    Tomorrow i'm one week out of the country...

    Regards
    Stefan

  7. #17

    Default

    Set the Duplex to (2)=full and Speed to 1000
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  8. #18
    Join Date
    Jun 2007
    Posts
    84

    Default

    In the Description of the AutoNeg: When this parameter is used, the Speed and Duplex parameters must not be specified.

    But i had this specified too....

    Best Regards
    Stefan

  9. #19

    Default

    Running out of options.... try changing the iSCSI daemon settings in the Tuning options - did you enable the WB on the Target? Not sure if we covered that area - checking....

    Try using a different version of client initiator.

    Some report good speeds from these settings:

    maxRecvDataSegmentLen=262144
    MaxBurstLength=16776192
    Maxxmitdatasegment=262144
    maxoutstandingr2t=8
    InitialR2T=No
    ImmediateData=Yes


    a) MaxRecvDataSegmentLength - Sets the maximum data segment length that can be received. This value should be set to multiples of PAGE_SIZE. Currently the maximum supported value is 64 * PAGE_SIZE, e.g. 262144 if PAGE_SIZE is 4kB.
    Configuring too large values may lead to problems allocating sufficient memory, which in turn may lead to SCSI commands timing out at the initiator host. The default value is 8192.

    b) MaxBurstLength - Sets the maximum amount of either unsolicited or solicited data the initiator may send in a single burst. Any amount of data exceeding this value must be explicitly solicited by the target. This value should be set to multiples of PAGE_SIZE. Configuring too large values may lead to problems allocating sufficient memory, which in turn may lead to SCSI commands timing out at the initiator host. The default value is 262144.

    c) MaxXmitDataSegmentLength - Sets the maximum data segment length that can be sent. This value actually used is the minimum of MaxXmitDataSegmentLength and the MaxRecvDataSegmentLength announced by the initiator. It should be set to multiples of PAGE_SIZE. Currently the maximum supported value is 64 * PAGE_SIZE, e.g. 262144 if PAGE_SIZE is 4kB. Configuring too large values may lead to problems allocating sufficient memory, which in turn may lead to SCSI commands timing out at the initiator host. The default value is 8192.

    d) DataDigest <CRC32C|None> - If set to "CRC32C" and the initiator is configured accordingly, the integrity of an iSCSI PDU's data segment will be protected by a CRC32C checksum. The default is "None". Note that data digests are not supported during discovery sessions.

    e) MaxOutstandingR2T <value> - Controls the maximum number of data transfers the target may request at once, each of up to MaxBurstLength bytes. The default is 1.

    f) InitialR2T <Yes|No> - If set to "Yes" (default), the initiator has to wait for the target to solicit SCSI data before sending it. Setting it to "No"
    allows the initiator to send a burst of FirstBurstLength bytes unsolicited right after and/or (depending on the setting of ImmediateData together with the command. Thus setting it to "No" may improve performance.

    g) ImmediateData <Yes|No> - This allows the initiator to append unsolicited data to a command. To achieve better performance, this should be set to "Yes".
    The default is "No".

    h) DataPDUInOrder <Yes|No> - It tells initiator if data has to be sent in order. Default is "Yes", which is also recommended.

    i) DataSequencerInOrder <Yes|No> - It tells initiator if data has to be sent in order. Default is "Yes", which is also recommended.

    j) HeaderDigest <CRC32C|None> - If set to "CRC32C" and the initiator is configured accordingly, the integrity of an iSCSI PDU's header segments will be protected by a CRC32C checksum. The default is "None".
    Note that header digests are not supported during discovery sessions.

    k) Wthreads - The iSCSI target employs several threads to perform the actual block I/O to the device. Depending on your hardware and your (expected) workload, the number of these threads may be carefully adjusted. The default value of 8 should be sufficient for most purposes.
    All the best,

    Todd Maxwell


    Follow the red "E"
    Facebook | Twitter | YouTube

  10. #20
    Join Date
    Jun 2007
    Posts
    84

    Default

    Moin,

    i tested this values but no change... Next week, when i'm back, i will install a windows with san melody or a open filer to see if it is a hardware problem. When this works it is a open-e problem...

    Best regards
    Stefan

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •