[OpenSPIM] OpenSPIM 64-bit [0000129]

[Nikul]

Hi everyone,

Thanks for the replies!

> Are you working with Brian McCabe? If yes, say hi to him. 

I work in the lab of Prof. Lazar, but we do collaborate with Brian. I'll
make sure to pass the greetings!




> May I ask how you plan to handle the data once it is acquired at this
> rate?! This is no small feat... I'm also interested in what you will
> image

We will be imaging drosophila larvae. For now, I am just dumping the 
data to a 4 TB raid array. Still working on the eventual data storage framework :)




> I'm not sure about actually improving the write speed, but if you haven't already, and your computer has a significant amount of memory, try enabling Asynchronous Output (a checkbox next to the destination directory) in OpenSPIM. With this setting on, the software will grab frames as quickly as it can capture them (until your RAM fills up, anyway).

Hi Luke, I am using the asynchronous output option and have been running some profiling tests.
Disabling all stage movements and calls to get positions from the stage, I am able to
get a 20fps capture from the camera. I suspect this is due to the use of software triggering.
Will investigate further

The write speed to the RAID array through openspim is really bad at this point(2-3 fps). I suspect
this is due to the use of the BioFormats writer., which somehow doesn't perform well
in this scenario. I will try to interface the TaggedImageStorageMultiPageTiff class from
MM with the openspim AsyncOutputWrapper to see if that improves things. (I am able to 
get 50 fps writes through micromanager) 

> Bear in mind also that if you aren't recording video, getting 100 fps suggests that all inter-frame actions complete in 10 ms. Since the default Z-stage settle delay (see "More Options") is 10 ms, achieving this may be quite difficult.
> 

Right now, I am just trying to ensure that the acquisition and output operations aren't a bottleneck.
I understand that the speed will be less once I include the stage movements. I am trying to take
a modular approach to maximize throughput. I have commented all calls to the
stage(even getPosition) to run acquisition/output benchmarks. 

> 
> Thanks for working through all these issues! If possible, could you document any necessary changes? I'd love to include a 64-bit OpenSPIM version in the near future.

If you could send me the code you used to produce the 32 bit self extracting archive, I can try
modifying it to have a 64 bit version in the coming weeks. On a related note, references to
commons-math3-3.2.jar might be necessary in the build xml files for 32 bit as well. I see that
the switch to commons math 3 was made recently but I wasn't able to find it included in the 
build files.







> - Writing a lot of small files takes a lot more time than a single big one. You might want to test your RAID system with something like ATTO Disk Benchmark, which measures data rates for different files sizes.

Hi Michael, I am getting a write speed of 1.4GBps for 16kb writes and more than 2GBps for 
anything more than 32kb writes through benchmarks,.
I will investigate further by writing a standalone program in Java using Java's I/O module and
another one using the BioFormats class to test their respective speeds.

> - Buffering the data in the RAM before writing to SSD could help, or streaming everything to RAM. Requires a lot of RAM, though.

I currently have 128 GB of DDR3-1600 ram. But even acquisition to ram at this point
seems to be slow(20fps) through openspim. 

In the video mode, I am able to get 50 fps in openspim, so it seems to be stemming from 
repeated calls to snapImage() as opposed to initiating a sequence acquisition.

----------------------------------------------
Nikul Ukani

Research assistant,
Bionet lab,
Columbia University.
http://www.bionet.ee.columbia.edu/









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openspim.org/pipermail/openspim/attachments/20140205/04b935fd/attachment-0002.html>