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

[Harry Kim]

I realized that you already answered my question in another e-mail.
If there is any new information, please let me know.

On Fri, Mar 13, 2015 at 8:09 AM, Harry Kim <hkim at redzone.com> wrote:

> Hi Andrey,
>
> For your information, I attached a simple program that writes data chunk
> of 200KB 10,000 times to a CF card connected to the Elphel board.
>
> With this program, I have noticed maximum 3 second writing time.
> And I had the similar result on my Linux machine.
> I like to understand why it takes 3 seconds although it is rare.
>
> Do you have any idea?
>
> Thanks,
> Harry
>
> On Thu, Mar 12, 2015 at 6:09 PM, Harry Kim <hkim at redzone.com> wrote:
>
>> I just want to see if writing speed to a CF card can significantly change
>> when a highest priority is assigned to my application.
>>
>> According to the link, it seems like I can use "renice" instead of nice
>> for my purpose.
>>
>> Thanks!
>>
>> 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
>> www.redzone.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
>
>
>


-- 
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/1b5406b5/attachment-0002.html>