[Elphel-support] Is there a way to assign a higher priority to an application on the Elphel board?

[Harry Kim]

image size 1136x960 at 7 fps is the normal usage for our application.

With the old CF cards, we never had a problem.
With the newer CF cards, although it is rare, we have seen communication
failure between the image and the camera server/our application.    This is
a big concern for our existing products
and new products we need to develop in the near future.

Since I can't produce the problem with the normal usage, I am using
2244x1808  (about 220kB in jpg) at 6 fps.  With the old CF cards, our
application still works fines although I expected it to cause the same
issue.  But as soon as I use newer CF cards, the communication failure
occurs a lot.
So I have been using the old CF card as a benchmark.

Do you think the old CF card is a good bench mark to find replacement CF
cards?

Do you have any suggestions for other CF cards that we can use for our
application?

Harry


On Fri, Mar 13, 2015 at 2:23 PM, support-list <
support-list at support.elphel.com> wrote:

> Harry,
> Flash memory controllers use proprietary algorithms,  so it is out of our
> control. I tried to contact CF manufacturer about another problem I
> discovered (described in this article:
> http://archive.linuxgizmos.com/open-source-camera-records-geotagged-video-to-sata-hdd/
> ),  but they could not provide me with any information. So you can play
> around and try to guess - what the card "likes" and what - does not.
>
> You did not reply my questions about the image size and frame rate you
> have in your application, so it is difficult to suggest you anything on the
> camera side.
>
> Andrey
>
> ---- On Fri, 13 Mar 2015 10:40:39 -0700 *Harry Kim<hkim at redzone.com
> <hkim at redzone.com>>* wrote ----
>
> The reason I was asking this question was that the CF card (SandDisk Ultra
> at 30MB/sec) we purchased recently started to cause problems with an
> existing application occasionally in a random fanshion.
>
> However, the old CF cards (SanDisk Extreme III at 30MB/sec) doesn't cause
> any problems.  The problem is we can't buy these old CF cards any longer.
> So I am in pursuit of finding "good" CF cards with similar specs to work
> with the application.
>
> As an experiment, I delayed a few milliseconds right after writing a chunk
> data into a CF card and the maximum writing time was reduced by a third
> consistently.
> Not sure if this is a good solution to avoid excessive writing timeout.
>
> What do think?
>
>
> On Thu, Mar 12, 2015 at 5:32 PM, support-list <
> support-list at support.elphel.com> wrote:
>
> Hello Harry,
>
> Which process do you want to have low priority? What kind of problems do
> you have with insufficent CPU power? As we already found the CF card
> timeouts are internal to the card (I noticed similar ~3 sec timeouts with
> the modern SD card we use in the new 10393 camera). The internal buffer is
> set 19MB, so if you know the average compressed frame size (in bytes) and
> the frame rate you may calculate how long the buffer can accumulate data
> without loosing data - normally 19MB should be enough.
>
> There are not many processes that can use much of the CPU (much of the
> activity is inside the kernel), and it depends on the applications you
> really need.
>
> How do you use the images/video from the camera? Do you stream it out over
> the network or record in the camera?
> These two processes are handled by the two different applications, and for
> recording I would suggest to use camogm, not the streamer. If you only
> record, and not stream out simultaneously you may disable streamer
> completely. That will still allow you to acquire images over the network
> with minimal overhead.
>
> There is also an autoexposure daemon running - you may disable it if you
> control the exposure/white balance manually
>
> PHP, web server do not eat up CPU when not specifically requested by the
> host, and there is nothing like Firefox or Flash running in the camera :-)
>
> And yes, default busybox (used in the camera as in most other embedded
> systems) configuration does not have nice command - you may read some
> discussion here: https://communities.intel.com/message/265279
>
> All the above  considerations are for the currently used firmware, really
> old legacy code (more than 6-7 years old) had different applications, FPGA
> clock rate and running software.
>
> Andrey
>
>
>
>
>
> --
> Best regards,
>
> Harry Kim
> Senior Embedded Software Engineer
> RedZone Robotics Inc.
> 91 43rd Street, Suite 250
> Pittsburgh, PA 15201
>
> office 412-927-3456 or 412-476-8980 x214   cell 412-897-0066
> hkim at redzone.com
> http://www.redzone.com/
>
>
>  _______________________________________________
> Support-list mailing list
> Support-list at support.elphel.com
> http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
>
>
>
>


-- 
Best regards,

Harry Kim
Senior Embedded Software Engineer
RedZone Robotics Inc.
91 43rd Street, Suite 250
Pittsburgh, PA 15201

office 412-927-3456 or 412-476-8980 x214   cell 412-897-0066
hkim at redzone.com
www.redzone.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20150313/2a930fb9/attachment-0002.html>