lkml.org 
[lkml]   [2002]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Warning - running *really* short on DMA buffers while doing file transfers
    >> Hooks for sending ordered tags have been in the aic7xxx driver, at
    >> least in FreeBSD's version, since '97. As soon as the Linux cmd
    >> blocks have such information it will be trivial to have the aic7xxx
    >> driver issue the appropriate tag types.
    >
    > They already do in 2.5, see scsi_populate_tag_msg() in scsi.h. This
    > assumes you're using the generic tag queueing, which the aic7xxx
    > doesn't, but you could easily key the tag type off REQ_BARRIER.

    If anyone wants to play with the updated aic7xxx and aic79xx drivers
    (new port to 2.5, plus it honors the otag stuff), you can pick it up
    from here:



    --On Friday, September 27, 2002 13:21:29 -0400 James Bottomley
    <James.Bottomley@steeleye.com> wrote:

    >> Which part of the OS are you talking about?
    >
    > I'm not, I'm talking about the pure physical characteristics of the
    > transport bus.
    >
    >> I also do not believe that the command overhead is as significant as
    >> you suggest. I've personally seen a non-packetized SCSI bus perform
    >> over 15K transactions per-second.
    >
    > Well, lets assume the simplest setup possible: select + tag msg + 10 byte
    > command + disconnect + reselect + status; that's 17 bytes async. The
    > maximum bus speed async narrow is about 4Mb/s, so those 17 bytes take
    > around 4us to transmit. On a wide Ultra2 bus, the data rate is about
    > 80Mb/s so it takes 50us to transmit 4k or 800us to transmit 64k.
    > However, the major killer in this model is going to be disconnection
    > delay at around 200us (dwarfing arbitration delay, bus settle time etc).
    > For 4k packets you spend about 3 times longer arbitrating for the bus
    > than you do transmitting data. For 64k packets it's 25% of your data
    > transmit time in arbitration. Your theoretical throughput for 4k
    > packets is thus 20Mb/s. In my book that's a significant loss on an
    > 80Mb/s bus.
    >
    > On Fabric busses, you move to the network model and collision
    > probabilities which increase as the packet size goes down.
    >
    > gibbs@scsiguy.com said:
    >> Because of read-ahead, the OS should never send 16 4k contiguous reads
    >> to the I/O layer for the same application.
    >
    > read ahead is basically a very simplistic form of I/O scheduling.
    >


    --On Friday, September 27, 2002 13:21:29 -0400 James Bottomley
    <James.Bottomley@steeleye.com> wrote:

    >> Which part of the OS are you talking about?
    >
    > I'm not, I'm talking about the pure physical characteristics of the
    > transport bus.
    >
    >> I also do not believe that the command overhead is as significant as
    >> you suggest. I've personally seen a non-packetized SCSI bus perform
    >> over 15K transactions per-second.
    >
    > Well, lets assume the simplest setup possible: select + tag msg + 10 byte
    > command + disconnect + reselect + status; that's 17 bytes async. The
    > maximum bus speed async narrow is about 4Mb/s, so those 17 bytes take
    > around 4us to transmit. On a wide Ultra2 bus, the data rate is about
    > 80Mb/s so it takes 50us to transmit 4k or 800us to transmit 64k.
    > However, the major killer in this model is going to be disconnection
    > delay at around 200us (dwarfing arbitration delay, bus settle time etc).
    > For 4k packets you spend about 3 times longer arbitrating for the bus
    > than you do transmitting data. For 64k packets it's 25% of your data
    > transmit time in arbitration. Your theoretical throughput for 4k
    > packets is thus 20Mb/s. In my book that's a significant loss on an
    > 80Mb/s bus.
    >
    > On Fabric busses, you move to the network model and collision
    > probabilities which increase as the packet size goes down.
    >
    > gibbs@scsiguy.com said:
    >> Because of read-ahead, the OS should never send 16 4k contiguous reads
    >> to the I/O layer for the same application.
    >
    > read ahead is basically a very simplistic form of I/O scheduling.
    >

    http://people.FreeBSD.org/~gibbs/linux/linux-2.5-aic79xxx.tar.gz

    --
    Justin
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:29    [W:0.027 / U:63.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site