Disk configuration with VxWorks 6.2 - VxWorks

This is a discussion on Disk configuration with VxWorks 6.2 - VxWorks ; I have an application that streams large volumes of data to and from the hard drive and does some processing on the data. On a comparable Windows machine, this application processes the data marginally slower than the disk can feed ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Disk configuration with VxWorks 6.2

  1. Disk configuration with VxWorks 6.2

    I have an application that streams large volumes of data to and from
    the hard drive and does some processing on the data. On a comparable
    Windows machine, this application processes the data marginally slower
    than the disk can feed it. Barring disk contention, the process is
    CPU bound. Under VxWorks 6.2, with a Pentium-M processor), the same
    process seems to be overwhelmingly IO bound (ataSrv consumes 70% of
    the clock ticks, while my application consumes less than 30%, and
    throughput is proportionally impacted). Enabling disk caching helped
    moderately with this (previously ataSrv consumed over 80% of the cpu
    according to spy), but we're still decidedly IO bound.

    I'm trying to determine if this is typical behavior from VxWorks, or
    caused by system misconfiguration. ataShow seems to identify the
    device properly (PIO-4, UDMA-5), but I'm not sure how to determine
    which features of the hardware are being utilized by the system. For
    instance, I found that the BIOS had 32 bit PCI transfers disabled, and
    upon changing this, I was unable to confirm any behavioral differences
    from VxWorks or our application. I presume I'm simply looking in the
    wrong places.

    The general consensus from the archives indicated that VxWorks doesn't
    actually exploit DMA for ATA drives. Is that still the case? Even if
    we were using PIO transfers, I would expect better behavior from the
    system, but perhaps I'm expecting too much.

    I'm wondering if anyone has a cookbook of IDE drive tips and tricks or
    troubleshooting that they could point me too, or any other
    observations about why I may be experiencing these problems. If the
    VxWorks drivers are not up to the task, is there a third party that
    offers better drive performance?

    Thanks,
    Jason


  2. Re: Disk configuration with VxWorks 6.2

    It has been a while since I used VxWorks 6.2, but if memory serves,
    the XBD ATA driver does support DMA transfers. I assume that you are
    using DosFS and that you have the cache enabled. If the cache is
    enabled and the transfers are large enough, setting the
    DOS_CACHE_VOL_NO_DMA option may give you a performance boost.

    Sparky.

    On Apr 13, 3:06 pm, jdmarsh...@gmail.com wrote:
    > I have an application that streams large volumes of data to and from
    > the hard drive and does some processing on the data. On a comparable
    > Windows machine, this application processes the data marginally slower
    > than the disk can feed it. Barring disk contention, the process is
    > CPU bound. Under VxWorks 6.2, with a Pentium-M processor), the same
    > process seems to be overwhelmingly IO bound (ataSrv consumes 70% of
    > the clock ticks, while my application consumes less than 30%, and
    > throughput is proportionally impacted). Enabling disk caching helped
    > moderately with this (previously ataSrv consumed over 80% of the cpu
    > according to spy), but we're still decidedly IO bound.
    >
    > I'm trying to determine if this is typical behavior from VxWorks, or
    > caused by system misconfiguration. ataShow seems to identify the
    > device properly (PIO-4, UDMA-5), but I'm not sure how to determine
    > which features of the hardware are being utilized by the system. For
    > instance, I found that the BIOS had 32 bit PCI transfers disabled, and
    > upon changing this, I was unable to confirm any behavioral differences
    > from VxWorks or our application. I presume I'm simply looking in the
    > wrong places.
    >
    > The general consensus from the archives indicated that VxWorks doesn't
    > actually exploit DMA for ATA drives. Is that still the case? Even if
    > we were using PIO transfers, I would expect better behavior from the
    > system, but perhaps I'm expecting too much.
    >
    > I'm wondering if anyone has a cookbook of IDE drive tips and tricks or
    > troubleshooting that they could point me too, or any other
    > observations about why I may be experiencing these problems. If the
    > VxWorks drivers are not up to the task, is there a third party that
    > offers better drive performance?
    >
    > Thanks,
    > Jason




+ Reply to Thread