WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Enforcing 80 conductor IDE  (Read 577 times)

Offline MTCAT

  • Sr. Member
  • ****
  • Posts: 370
Enforcing 80 conductor IDE
« on: March 30, 2023, 05:43:55 AM »
Hi everyone,

I've made some good progress getting my little VortexDX3/24DSI12 data acquisition system to run reliably for days, I found that using the "taskset" command to force one application (mt_logger) to run on one core, all the GUI stuff basically, and the other application (mt_adc) to run on the other core, helped a lot. Before using taskset the two applications would flip-flop back and forth across the cores and seemed to be contributing to the "mt_adc timeout error" (presumably due to buffer overflow) that I was seeing, my current record is a continuous run time of 39 hrs (with taskset), I had to turn it off before the big battery died.

Anyway, another factor (it seems) are the file sizes getting written out to the CF card, for the 39 hr run I had to turn down the (decimated) continuous file sample rate to 1 kHz such that the continuous files saved to disk were ~ 1.37 MBytes, with larger file sizes, 5 or 20 times larger, the program has run for "only" 19 hrs and 10 hrs respectively....

The VortexDX3 is also working hard to draw the screen updates (~ 30 % load on one core in top) but another factor (I think) are the file sizes, and finally the write speed I'm getting.

Right now my kernel (2.6.33.3) is limiting the write speed to the CF card to UDMA/33, I would like to increase this to UDMA/66 or UDMA/100 since the CF-card can definitely handle these speeds, hopefully the controller can too.

I've read some posts on other forums about setting an option in /etc/modprobe.conf --> options ide_core ignore_cable=0, but then also had to rebuild the initrd image?

Other post indicated you could use something like (in extlinux.conf??) --> libata force=80c

Just wondering if anyone has done this before (over-rode the kernel enforced UDMA/33) and if they might know the best way to go about doing it.

Thanks,

David

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10864
Re: Enforcing 80 conductor IDE
« Reply #1 on: March 30, 2023, 10:26:03 AM »
You can pass the params on your bootloader line easily, "libata.force=80c" (note the dot) in extlinux.cfg if you're using that.

Have you considered using compression to write less data? Something very simple that does not take much cpu.
The only barriers that can stop you are the ones you create yourself.

Offline MTCAT

  • Sr. Member
  • ****
  • Posts: 370
Re: Enforcing 80 conductor IDE
« Reply #2 on: March 30, 2023, 11:08:56 AM »
Hi curaga,

Thanks, I am indeed using extlinux.cfg to pass in boot codes like waitusb=5 (thanks Rich), etc., I'll try adding in "libata.force=80c" and see what happens, sorry about missing the dot in the last post.

The mt_logger program does have an option for file compression but it "only" reduces the (binary) file size by ~ 30 percent, but you're right, might need to do that as well.

Thanks,

David

Offline patrikg

  • Hero Member
  • *****
  • Posts: 602
Re: Enforcing 80 conductor IDE
« Reply #3 on: March 31, 2023, 12:19:44 AM »
Do you need to shrink binary elf files, you can use tools like upx.
So when executing the file it self expands it self in memory.
I use this tools a lot, when compiling go applications that are very big because of it's nature that it's bring in all dependency's with in.


 

Offline MTCAT

  • Sr. Member
  • ****
  • Posts: 370
Re: Enforcing 80 conductor IDE
« Reply #4 on: March 31, 2023, 07:17:18 AM »
Hi Curaga and patrikg,

Thanks for the help, I added the "libata.force=80c" to my extlinux.conf and voila, I now have UDMA/100!, thanks a lot!

That should theoretically triple my write speed, which would be great, but I would be happy even with 2x increase.

I need to do some test recording now and see if I can write out continuous files that are ~ 6 MBytes without getting any timeout errors.

The compression inside mt_logger (according to the fellow who wrote the program) is some kind of special or "custom" algorithm, so one needs the corresponding decompression program to decompress the files, without that decompression program, you're out of luck apparently. And then I always end up with multiple copies of the data floating around, compressed, decompressed, but considering my recent SSD failure and complete loss of data I suppose multiple copies is not a bad thing sometimes.

Thanks,

David