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 <h...@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 <h...@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@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 >> h...@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 > h...@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 h...@redzone.com www.redzone.com
_______________________________________________ Support-list mailing list Support-list@support.elphel.com http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
