> > Hello, Andrey, thanks for the quick response! > You are welcome , Flavio
> > I'm also online (here it is 3:40am) =) > Not that late he - less than 1AM :-) > > My Kingston cards are not listed in the blacklist. Let's get them to > work and see how far they go. Here are the results of the tests, I'm > ssh-ed into the cam: > > [root@Elphel353 /mnt/0]944# time dd if=/dev/circbuf of=/dev/null > 38656+0 records in > 38656+0 records out > real 0m 0.42s > user 0m 0.03s > sys 0m 0.39s > [root@Elphel353 /mnt/0]944# time dd if=/dev/circbuf of=/dev/hdb1 > 38656+0 records in > 38656+0 records out > real 0m 6.75s > user 0m 0.19s > sys 0m 2.46s > [root@Elphel353 /mnt/0]944# > > If I understood correctly, my card takes 6.75 seconds to write the > 19MB and 19 MB / 6.75 = 2.8MB/s should be the maximum data rate my > cards can handle, is that it? > Yes, the cards are in PIO mode so seem to be disabled. And as I wrote - it is not only that they are ~16/2.8 ~= 5.5 times slower than those in DMA mode, they use CPU much more during recording, so no resources fro other CPU tasks. Can you try them with hdparm -I and send the reply? The CPU-limited recording rate in DMA mode should be ~16MB/s > > Meanwhile, I've tested normal HD JP4, at 720p and observed that > compression 100% is a killer, but at about 90%, the recording > proceeded without cutting the video, even tough the gui refresh rate > suffered. > Yes that is so - 90% is really good quality. It may also make sense to fine-tune coring value () in addition to JPEG quality to find the best overall quality/image size ratio. With Eyesis we use 97-98%, but that is only because we use aberration correction by de-convolution that amplifies the noise and artifacts. BTW - here are our last panoramas made with the new camera (viewing requires good videocard and WebGL-capable browser) http://community.elphel.com/files/eyesis/pano-db-3/webgl_panorama_editor.html?kml=mainstreet_ro.kml&proto=mainstreet_ro.kml&ntxt=2&as_camera=95&start=result_1334548264_780764_1.jpeg&range=95&labels=false&keepzoom=false&closest2d=false&seethrough=0.4&transition=5&mask=&azimuth=23.2&elevation=-70.5&zoom=0.386&follow=false&mv3d=false > > ps.: I considered buying the Sundisk Extreme III, but I saw they were > not being sold at B&H at the moment. =/ If there is any other you > would recommend... > I'll ask here tomorrow, but I think recently we only used that card (different capacities) Andrey > > 2012/4/26, Andrey Filippov <[email protected]>: > > Hello Flavio, > > > > Most likely the problem is related to the CF - as I wrote in that old > > article, most CF cards in IDE mode lie about support of the DMA mode. > They > > do support UDMA so most people never notice that small lie. But Axis CPU > > used in the camera has a bug of it's own - and this bug is related to the > > UDMA. If the card would hostly report that it does not support DMA camera > > driver would just go to PIO mode (ABSOLUTELY NOT SUITABLE for the video > > recording - both slow and using to much of the camera CPU resources), but > > it does not, so camera may hang up and never come out of the boot > scripts. > > So what we did was to add some known "bad" cards to the driver black > list: > > > > > > > http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/os/linux-2.6-tag--devboard-R2_10-4/drivers/ide/ide-dma.c?view=markup(lines > > 130..136). > > > > At some point we black-listed all no-name cards (we did not find any > among > > them that did support DMA) You may use hdparm -I (from > > http://192.168.0.9/phpshell.php, telnet or serial console that you > should > > have cable for) and the only way to re-enable (if you card matches the > > black-listed one) the card is to modify that file and recompile the > camera > > firmware. The only type of CF cards we use ourselves is "Sandisk Extreme > > III". > > > > When the card is blacklisted, camera bots correctly and is able to mount > > (and use) the card - it can be used to save images or very slow video > > (still useful for timelapse), but not the normal video. > > > > You may test the speed of the CF card (that test will destroy data on > it!) > > with the following command (again - phpshell, telnet, serial console): > > > > time dd if=/dev/circbuf of=/dev/hda #(or hdb - depending how is the card > > inserted/configured) > > > > /dev/circbuf is the circular buffer ~19MB in size that is very fast to > read > > for the camera, so the speed will be related to the CF itself > > > > You may try it on /dev/null first: > > > > [root@Goniometer /dev]16713# time dd if=/dev/circbuf of=/dev/null > > 38656+0 records in > > 38656+0 records out > > real 0m 0.43s > > user 0m 0.11s > > sys 0m 0.32s > > > > With phpshell you may just open the following link (provided you have the > > default IP) - just replace all spaces in the command line with "+" signs > > > http://192.168.0.9/phpshell.php?command=time+dd+if=/dev/circbuf+of=/dev/null > > > > Then divide 19MB by the time measured. > > > > Andrey > > > > _______________________________________________ > Support-list mailing list > [email protected] > http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com >
_______________________________________________ Support-list mailing list [email protected] http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
