[Solved] TC3.8_4 Real Time Upgrade

[MTCAT]

Hi Rich and Juanito,

Thanks for the help, I'll give that a try, before I do though, I was wondering, could installing gparted.tcz and e2sfprogs_apps.tcz have messed up something ? Maybe the pkg_config_path got messed up somehow ? I was able to compile the acquisition program no problem before installing those packages, so, what changed ?, the only changes that were made was installing gparted and e2sfprogs, and deleting sda1 (linux-swap) ?, and now I get this error when trying to compile, maybe just a coincidence ?

Thanks,

David

[MTCAT]

Hi Rich and Juanito,

Sorry for all the posts, I tried "echo $PKG_CONFIG_PATH" and it returned an empty string, nothing at all, is that correct ?

Thanks,

David

[Rich]

Hi MTCAT
I doubt installing  gparted.tcz  and  e2sfprogs_apps.tcz  caused it. If you want to test that, open your  onboot.lst  file
and delete the  gparted.tcz  and  e2sfprogs_apps.tcz  lines. Then reboot and try compiling again.

I suspect  libxcb-dev.tcz  needs to be loaded.

[MTCAT]

Hi Rich,

I'm just wondering because the acquisition program compiled just fine before with just libxcb.tcz ?, with onboot.lst as attached previously but w/o gparted.tcz and e2fsprogs_apps.tcz

I think make couldn't find xcb package but it also couldn't find the gtk header file ?

Does it seem correct that "echo $PKG_CONFIG_PATH" would return an empty line ?, that's what I'm getting right now, I assume that if installing gparted.tcz and/or e2fsprogs_apps.tcz messed up PKG_CONFIG_PATH that I would maybe just need to "re-set" the PKG_CONFIG_PATH, but I'm not sure what it should be.

If I'm barking up the wrong tree, I'll stop now, just seems odd that the program compiled okay with just libxcb.tcz before installing gparted and e2fsprogs_apps.

Thanks,

David

[Rich]

Hi MTCAT
I would not normally expect  PKG_CONFIG_PATH  to be set in a normal environment.

Did you try Juanitos suggestion in reply #359 ?

[MTCAT]

Hi Rich,

Oh, okay, no I haven't tried anything yet, I think Juanito's suggestion is really just the same as yours ?, right ?, namely, install libxcb-dev.tcz, but then Juanito also showed how to export the compiler and library flags, is that right ?

Thanks,

David

[Rich]

Hi MTCAT

... but then Juanito also showed how to export the compiler and library flags, is that right ?

Yes. That's how a script or make file retrieves the flags a particular  -dev  package requires.

[MTCAT]

Hi Rich and Juanito,

Sorry for being stubborn about libxcb-dev.tcz, you guys were right, I installed it and mt_logger compiled no problem, don't know why it compiled before okay with libxcb.tcz but will remain a mystery I guess !, thanks for the help, now I can see if the "O3" made the GUI any snappier !

Although I notice that the mt_adc Makefile has no optimization flag set in it all, and still uses the "-g" option. Lots of things to play around with I guess.

Thanks again, you guys saved the day for the 100'th time once again !

Thanks,

David

[Rich]

Hi MTCAT

... don't know why it compiled before okay with libxcb.tcz but will remain a mystery I guess ! ...

Either  libxcb-dev.tcz  was getting loaded before or you were compiling non-GUI parts of the program.

[MTCAT]

Hi Rich,

I've been playing around with the acquisition program and have noticed a few things. The "-O3" optimization for mt_logger has definitely
perked things up a bit but I'm getting an error which crashes the acquisition program ("adc timeout error") which I think is related to the
volume of data being transferred from the 24DSI into RAM (buffer overflow ?) - I was getting this error with "-O0" compilation as well.

I'm thinking it's due to data volume as I only see it happening with 200 kHz sample rate (which is max), at 100 kHz sample rate per channel, the
program seems pretty happy to run along with no problems at all, for like an hour or more. At 200 kHz sample rate though,
I usually see this error within something on the order of 15 minutes or so.

Peter defined two variables, "blk_size" and "dma_size", as shown in the attached file, lines 59 to 73. This is for setting up the "ring"
buffer and for initiating DMA transfers, right now, DMA transfers occur every 120,000 samples and the ring buffer is about 120 MBytes.

As you might recall, you helped me set up a 256 MByte shared memory segment for the acquisition program, which I thought was just for the ring
buffer alone, but it seems likes it's also used for other things (communication buffer and maybe others). I used 256 MBytes with the VortexDX3
as this is what Peter indicated in the comments of one of the programs, but technically, I haven't seen what is actually being
used on the Slackware boxes, but the original Pentium "only" has 512 MBytes total RAM, so I assume Peter did use a 256 MByte shared memory segment
there too.

But, the VortexDX3 has 2048 MBytes RAM, so we could go a lot bigger, and the 24DSI has a data buffer of 256,000 samples, so Peter is initiating
DMA's when the 24DSI onboard buffer is a little less than half full.

Do you think it might help to use a larger "blk_size" and "dma_size" with the VortexDX3 ?,240 k samples for example- as shown in the comments, and
possibly increase the size of the shared memory segment to 512 MBytes ? (ring buffer would be ~ 240 MBytes - is 256 MByte shared memory segment
large enough in that case ?, could use 512 MBytes just to be safe, kind of have RAM "to burn" with the VortexDX3).

Hopefully that wouldn't just be delaying the inevitable though, i.e., would still have the same failure, but would just take longer to do so.
Based on the General Standards test script "rxrate" it seems that the VortexDX3 can keep up with the 24DSI12, even at max sample rate, throughput
on the bus was good enough, it admittedly only runs for about 10 seconds or so, but maybe the VortexDX3 is being "hassled" by too many DMA
transfers ?, do less DMA's, but larger ones when we do ?

When this "adc timeout error" happens its quite harsh in the sense that it requires a complete re-boot of the computer before the acquisition
program will run again.

Another error I see is more gentle, "adc restart timeout error" which is happening when I try to change sample rate, or ADC scale, etc.,
the acquisition program attempts to "restart" the ADC with the new parameters but it seems to be taking too long and "times-out", there's one
spot where the program is set to give 20 seconds max (I think) to reset the ADC, weird thing is, when I do a change of parameters, I get this
"adc restart timeout error", I then close the acquisition program, then re-start it, and I can see that the desired change did actually take place,
but I'm still getting this error, so maybe it's just barely timing out so to speak. There's also a bunch of "usleep(xxx)" commands sprinkled
throughout, maybe some of those have to be tweaked too.

I'm hoping that if I simply increase the 20 (seconds ?) to say 30 seconds, then maybe it would be okay. The VortexDX3 does take noticeably
longer than the single core Pentium to start up the acquisition program, so it makes sense that I might be "timing-out" relative to the Pentium.


Thanks,

David

[MTCAT]

Hi Rich,

Sorry, noticed a typo, in mt_adc.c the variables are "BLKSIZE" and "DMASIZE", it's in another program (adc_control.c) where "dma_size" is referred too.

Thanks,

David

[Rich]

Hi MTCAT

... at 100 kHz sample rate per channel, the program seems pretty happy to run along with no problems at all, for like an hour or more. At 200 kHz sample rate though, I usually see this error within something on the order of 15 minutes or so. ...

That sounds like the ADC is collecting data faster than it can be transferred to shared memory.

[Rich]

Hi MTCAT
You could try changing  DMASIZE  to 60K:

Code: [Select]

#define DMASIZE ((60*1024)) /* buffer threshold for dma operations */so the buffer doesn't fill up as much before a DMA transfer starts.

[MTCAT]

Hi Rich,

I found that the error is coming from a general standards function (?) called "dsi_dsl_read", so I contacted General Standards and the fellow there sent me a neat little program (hopefully I can get it to work) that monitors the level of the 24DSI12 onboard buffer (percentage of fill I think) and saves this number to disk 1000 times a second. Don from GSC is recommending that I run this program, and then start the acquisition program at the 200 kHz sample rate and let it run until it presumably overflows (10 or 15 minutes), and can then see what's going in with the 24DSI12 onboard buffer.

Sounds like a good idea but, I can see already in his Makefile that I'll need to change the location of the libraries, and he's given some instruction already for changing arguments in a couple place, so hopefully it will actually build.

I guess if I can't it to get work, I'll just try the 60k sample DMASIZE and see how that looks.

Thanks,

David

[MTCAT]

Hi Rich,

As I suspected, Don's buffer examination program is written for the 4.x 24DSI12 driver and won't work with the older driver I'm using, I did run "./rxrate -r10000" to pump 10 GBytes (I guess ?) through the system, it ran fine for almost 20 minutes straight, flat out at 200 kHz, could try a 200 min test I suppose, but otherwise, I did get the full acquisition program to run for a few hours at 200 kHz sample rate with a larger 240ksample dma_blk_size, but results are kind of erratic with respect to the dma_blk_size, 120 ksample is perfect at 100 kHz (it seems), 240ksample at 200 kHz seems pretty good, but still not 100 percent I think.

Seems like there's something else going on as well, the Vortex is having a bit of a hard time with display related duties I think, the continuous stream, which can be displayed as it's collected (if the continuous tab in the GUI is selected), seems kind of "jerky" and I notice the seconds counter in the GUI jumps a bit irregularly sometimes to "catch up" with tinierclock.sh for example, it's not just a steady tick-tock kind of thing within the GUI, there is an integer variable called "loop_time_ms" which is set at 50 (ms) for which the comment says "run the acquisition loop at 20 Hz", I think this is the rate at which the GLADE GUI is refreshed, maybe could try a slower refresh rate of 100 (ms)...I'm also using the VGA output right now, but will use the LVDS output when it's finally done, I don't know if the LVDS output is more "direct" (faster ?).

Otherwise, I was also trying to investigate threads, to see if mt_logger or mt_adc are using multiple threads at all, which Don says is essential (to have separate read and write threads), I tried using "ps -o nlwp <pid>" but the "-o" option doesn't seem to work with the version of ps I have. I also tried looking in /proc/<pid>/task but it didn't make sense to me, there's supposed to be one directory for every thread but there were many directories in there with what looked like system related things, not specific to mt_logger, also "top -H" doesn't work with my version of top (to see threads).

Would you happen to know the best way to see threads for a given process in TC ?

Don also suggested commenting out the one and only include <pthread.h> statement in one of the mt_logger sub-programs and see what errors come up, he thought that this would also tell us where threaded operations, if any, are happening. It's weird though, the one and only include <pthread.h> is inside one of the mt_logger sub-programs but there is no -lpthread compile option in the mt_logger Makefile, but, there is a -lpthread compile option inside the mt_adc Makefile, so seems odd.

Thanks,

David