I have usually only had the minimal number of plots on a worksheet that I needed to ensure that the samples I was running looked reasonable. Being a Friday morning, and having some time on my hands, I decided to check out Ryan's comment about speeding up the display process by reducing/removing plots. 13 parameters 2e6 events collected 5 dot plot 4 gates 500 events displayed refresh time 63 sec 13 parameters 2e6 events collected 1 dot plot 0 gates 500 events displayed refresh time 53 sec 13 parameters 2e6 events collected 1 histogram 0 gates 500 events displayed refresh time 52 sec 13 parameters 2e6 events collected 3 dot plots 2 gates 500 events displayed refresh time 59 sec 13 parameters 2e6 events collected 3 dot plots 2 gates 5000 events displayed refresh time 62 sec 13 parameters 2e6 events collected 3 dot plots 2 gates 50000 events displayed refresh time 64 sec So, as Ryan suggests, decreasing the number of plots increases refresh time, but the type of plot does not seem to matter as much. Increasing the number of displayed events increases the I also wonder if the refresh can be affected by the 'worksheet' vs 'global worksheet'. Yours with a grain of salt on a Friday morning. Timothy Bushnell, Ph.D. Director, CPBR Flow Lab University of Rochester tel: 585-273-1361 http://www.urmc.rochester.edu/Aab/geneped/flow/ <http://www.urmc.rochester.edu/Aab/geneped/flow/> http://www.urmc.rochester.edu/wnyfug/ <http://www.urmc.rochester.edu/wnyfug/> Use of the return email address on this message for commercial purposes is prohibited. The transmission of unsolicited commercial material is prohibited under federal laws (47 USC 227). Civil penalties and claims of $500.00 per occurrence (47 USC 227[c]) may be assessed for violations. _____ From: Ryan Duggan [mailto:rduggan@flowcity.bsd.uchicago.edu] Sent: Thursday, August 11, 2005 9:40 AM To: cyto-inbox Subject: Re: FACS Diva software Stuart, I'm not a technical computer person, but I have been able to speed up this process by moving all or most of the plots off-screen, or by only creating one plot or histogram (a single histogram may be best). It doesn't help much to see your data as it's being collected, but as long as you have set up the instrument properly, you technically wouldn't need to see your data until it gets analyzed. I've always attributed this to the graphics card, and I believe that even the BD specified graphics card is not robust enough to display all that data. For those who work with high-end graphics on their computers, they have commented that the graphics card on our computer is really slow. I don't know, however, if you could simply upgrade to a higher-end graphics card; you'd probably have to check that with BD. It may also have something to do with the Java platform it runs on, which I've heard many programmers dislike, and in that case, we're pretty much stuck. Ryan Duggan Flow Cytometry Facility University of Chicago On Aug 9, 2005, at 11:50 PM, Stuart Berzins wrote: Has anyone got a way to improve the speed of the FACS Diva software? We are using a 6-color BD LSR2 with the latest FACS Diva software. The software itself does all that we want it to do, but it struggles to cope with large data files (especially files above 2 million). We find that when acquisition stops, there is a delay of up to 3 minutes for various forms of data processing before another acquisition can take place. During the stoppage, progress bars appear to say that the data is being prepared for display etc. Is there anyway to cut back on this time? Worse still, when acquisition gating, this delay is proportional to the total number of cells looked at, rather than the cells to be stored. Lastly, when a sample involves numbers above 5 million, there needs to be a continual appending of data or the software will simply shut down and say that memory is insufficient at around the 4 million cell mark. We have upgraded the computer to the highest performance available, adjusted the graphics card to BD specifications, reduced the 'events shown' to a minimum, avoided statistical displays and so forth, all with no discernable benefit. Because the software won't let us cut this process short and just jump to the next tube, some experiments have up to 2 hours spent just sitting there waiting for the machine to let us acquire new data. We were told that the latest version of the software would be much quicker, but after installing that a month ago, there seems to be no change (same story with the version before that too). I am told this is a widespread issue, but has anyone found a way to improve things? Stuart -- Stuart Berzins Ph.D, Research Fellow, Godfrey Laboratory, Department of Microbiology and Immunology, The University of Melbourne, Parkville 3010, AUSTRALIA. email: berzins@unimelb.edu.au <mailto:berzins@unimelb.edu.au> Ph: +61-3-8344-5704 Fax: +61-3-9347-1540 Mobile: 0427 849 123Received on Fri Aug 12 16:38:00 2005
This archive was generated by hypermail 2.1.8 : Sat Jan 14 2006 - 22:03:52 EST