This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Inconsistent ATA write speeds between different boards

I have two different development kits for the DM6446. The first is running the old MontaVista 2.6.10 on a 3rd party demo board.

 

The second is running using the PSP 3.0.1 (linux 2.6.32) from the Arago project running on the DVM-6446.

 

On the first 2.6.10 I can get a sustanted write speed of about 20 MBps using a JFS filesystem. One the second (2.6.32) I can get peak 20 MBps, however it flucuates all over the place dropping down to 8MBps some times). This is all using UDMA Mode 4, the highest the davinci 6446 supports.

 

With that being said I have dived deep into this problem looking at the differences between the palm chip drivers. There are quite a few changes so I decided to hook up a logic analyzer to the the DMA signaling lines.

 

Now bear with me while I talk low level. On the ATA interface the DMARQ line signals to the host that the device is ready to receive data. Sometime during a large file transfer the DDMARDY asserts telling the host that the drive needs to pause communication. The ATA specification says that the device will eventually de-assert DDMARDY when its ready to receive more data. There is an additional STOP line that the host can assert to tell the device that it is done sending data or terminate.

 

Now here is what I am seeing. On the 3d-party 2.6.10 kernel board when the DDMARDY line asserts (telling the host to wait), the host stops sending data and waits, but after about 200 uS I see the STOP line assert and de-assert, then it toggles 8 times and another 50 uS laters it toggles again and the DMARQ line from the device finally goes high saying more data can be transferred. This scenario is presented exactly the same on the EVM-6446 however instead of ~200uS before the STOP line from the host starts toggeling, its more like 8millseconds!

 

This is quite puzzling to me, first why does the host even initiate a STOP when the device told it to pause, and second what is controlling this sort of timeout? I've looked through all the registers in the ATA spru document and I didn't see anything related to a timeout. There doesn't seem to be anything on the ATA specification that says a host should stop the DMA burst out when it has waited for too long.

 

Any thoughts? I'm pretty sure that this is the cause for slower write speeds on the newer kernel or this EVM board.

 

Thanks in advance

  • Joshua,

    Did you happen to test with another drive to confirm that this is not a drive specific behavior (I do acknowledge that the behavior is consistent on 2.6.10).

    Can you compare the timing programming between 2.6.10 and 2.6.32 driver to eliminate any programming issue.  Pl. note that you could go upto UDMA 5 (with relaxed timings) on DM6446 though not strictly compliant with UDMA5 still works fine.  You could give it a try.

    regards

    swami

  • Thank you for the response.

     

    I've tried two different drives (same model) on these boards with the same result.

     

    What do you mean you acknowledge the behavior is consistent in 2.6.10?

     

    I started comparing some of the registers. I've even made changes to make sure some of them are the same but I don't really know which registers would control what I am seeing with the STOP line being strobed during a device pause on DMA?

     

    Do you know why STOP has to be triggered before DMARQ would assert again?

     

    Thanks,

     

    Josh

  • *******UPDATE************

     

    I was able to get the Montavista 2.6.10 running on the DVEVM and boy does it sure write fast to the hard drive. I'm averaging about 23 MBps using a JFS partition.

     

    That then leads me to believe that the latest PSP 3.0.X has much slower write speeds (probably because of what I mentioned above) than whatever is taking place in 2.6.10.

     

    Now granted the filesystems are different where the Montavista usings the full compiled command line tools than the Arago which uses busybox but I don't think this would make a different for the simple C program I wrote that writes to the hard drive. Here are some results for writing to the hard drive using Montavista (2.6.10) vs Arago PSP (2.6.32)

    Writing 4 Meg chunks using Montavista

    Elapsed Time = 0.146470, Speed=26.669293 MBps
    Elapsed Time = 0.127114, Speed=30.730304 MBps
    Elapsed Time = 0.127177, Speed=30.715066 MBps
    Elapsed Time = 0.156928, Speed=24.891979 MBps
    Elapsed Time = 0.157516, Speed=24.799068 MBps
    Elapsed Time = 0.128205, Speed=30.468794 MBps
    Elapsed Time = 0.157320, Speed=24.829961 MBps
    Elapsed Time = 0.176330, Speed=22.153069 MBps
    Elapsed Time = 0.159571, Speed=24.479709 MBps
    Elapsed Time = 0.159211, Speed=24.535045 MBps
    Elapsed Time = 0.159356, Speed=24.512727 MBps
    Elapsed Time = 0.159944, Speed=24.422602 MBps
    Elapsed Time = 0.159236, Speed=24.531188 MBps
    Elapsed Time = 0.157849, Speed=24.746740 MBps
    Elapsed Time = 0.158100, Speed=24.707462 MBps
    Elapsed Time = 0.158164, Speed=24.697462 MBps

    Writing 4 Meg chunks using Arago PSP

    Elapsed Time = 0.197001, Speed=19.828582 MBps
    Elapsed Time = 0.198570, Speed=19.671903 MBps
    Elapsed Time = 0.186929, Speed=20.896973 MBps
    Elapsed Time = 0.202193, Speed=19.319411 MBps
    Elapsed Time = 0.247302, Speed=15.795461 MBps
    Elapsed Time = 0.320710, Speed=12.180000 MBps
    Elapsed Time = 0.274143, Speed=14.248951 MBps
    Elapsed Time = 0.294580, Speed=13.260405 MBps
    Elapsed Time = 0.263520, Speed=14.823353 MBps
    Elapsed Time = 0.250776, Speed=15.576647 MBps
    Elapsed Time = 0.351936, Speed=11.099316 MBps
    Elapsed Time = 0.200954, Speed=19.438532 MBps
    Elapsed Time = 0.275956, Speed=14.155328 MBps
    Elapsed Time = 0.278628, Speed=14.019595 MBps

     

    Any thoughts or suggestions or something that I'm missing that glarringly obvious?

     

     

  • Some more updated data....

     

    It seems that the device is not pausing the data flow, its actually initiating a device termination of data-out. The new kernels do not respond to this quickly for some reason while the old kernel does.

     

    Perhaps most hard drives don't do this?

     

    Any thoughts from the community?