|
From: <pa...@mi...> - 2004-10-28 15:46:45
|
Hi, I would appreciate answer to following problem related to fast updated real time data. I plot an ASCII file using a "plot" command. Upon arrival of new data (with a frequency close to 1 second) I issue a "replot" command. In effect I see that gnuplot_x11 takes al large amount of CPU resurces (no matter if the gnuplot is iconified or not). Worst, when X11 is displayed on a PC through an emulator Exceed, Exceed runs out of memory (or so it says) no matter how it is configured. Questions are 1) What is the best way to use gnuplot for real-time visualization (are there any buffering options reducing resouces needed for redraw) 2) How to iconify gnuplot windows (other through -noraise option) so when window is inconified gnuplot does not eat X11 resources. Thanks Pawel |
|
From: Daniel J S. <dan...@ie...> - 2004-10-28 17:36:51
|
Pawel, Could you please give us some idea of the quantity of data and its nature? For example, 2D plot 500 lines? 3D plot 500 surfaces? I assume you say that X11 is slow because that is the only terminal you are using. I say that because there are several parts of gnuplot, bringing data into gnuplot, generating the plot internally, sending the plot across a pipe to the X11 driver, interpretting the plot commands in the driver. Technically HBB is correct that gnuplot really isn't for real-time applications. (Such applications--ones where the frame refresh must occur at required moments in time--need more low-level approaches where only necessary portions of the visual are updated. For example, if you are trying to generate some kind of oscilloscope, gnuplot won't work.) But perhaps what you have in mind isn't necessarily "real-time" but just something adequately fast. (E.g., very low frame rate with allowable occassional timing blip due to OS behavior.) Also, I imagine running through and emulator will slow things down. Dan pa...@mi... wrote: >Hi, >I would appreciate answer to following problem related to fast updated >real time data. > >I plot an ASCII file using a "plot" command. Upon arrival of new data >(with a frequency close to 1 second) I issue a "replot" command. > >In effect I see that gnuplot_x11 takes al large amount of CPU resurces >(no matter if the gnuplot is iconified or not). > >Worst, when X11 is displayed on a PC through an emulator Exceed, Exceed >runs >out of memory (or so it says) no matter how it is configured. > >Questions are > 1) What is the best way to use gnuplot for real-time visualization > (are there any buffering options reducing resouces needed for redraw) > > 2) How to iconify gnuplot windows (other through -noraise option) > so when window is inconified gnuplot does not eat X11 resources. > > >Thanks > > Pawel > >------------------------------------------------------------------------ > >--------------------------------------------------------- > >This e-mail contains information some or all of which may be confidential, proprietary and/or legally privileged. If an addressing or transmission error has misdirected this e-mail, please notify the sender by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. > >--------------------------------------------------------- > > -- Dan Sebald email: daniel DOT sebald AT ieee DOT org URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/ |
|
From: Daniel J S. <dan...@ie...> - 2004-10-28 20:49:37
|
pa...@mi... wrote: >Daniel, >Thanks for your reply. > You're welcome. >What I am trying to do is to replot simple time series file every second >(or every update whichever is less frequent). The file would look like >12:44:51 GOOG.O +193.00 >12:44:52 GOOG.O +193.058 >12:44:53 GOOG.O +193.95 >..... >and although file can be large (several thousand lines) the performance >issue is not >in just gnuplot itself (which takes about 10% of CPU), bbut gnuplot_x11 >that takes upto 20% and crashes my Exceed emulator of X. So I would >think that objective is to reduce >amount of data sent to: > Well, several thousand lines is starting to get up there. It would probably work on the setup Ethan described. However, when you think of a video screen, it's what? Maybe 800x1200? Several thousand lines would mean each line averaging the space of a pixel. In other words both gnuplot and gnuplot_x11 are doing a lot of number crunching to compute at a resolution that ends up being discarded. (Unless you are going to do zooming!! But in real time that's a big if.) So reducing that data up front might help. You can't just discard data points for fear of aliasing, perhaps something like averaging of the samples, i.e., reduce 2000 points to 200 points by averaging groups of ten. (I'm talking uniform sampling now.) Just a thought. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-28 19:32:01
|
On Thursday 28 October 2004 08:46 am, pa...@mi... wrote: > > In effect I see that gnuplot_x11 takes al large amount of CPU resurces > (no matter if the gnuplot is iconified or not). Please explain your configuration in more detail. Is gnuplot_x11 running on the same PC? Or is it running on another machine and displaying on a separate X-server (the PC + Exceed)? Also, please tell us exactly what version of gnuplot you are running. If you built from the CVS source, please look in the ChangeLog to see what was the most recent date of bug-fixes. > Worst, when X11 is displayed on a PC through an emulator Exceed, Exceed > runs out of memory (or so it says) no matter how it is configured. There have been at least 2 memory leaks fixed in gnuplot_x11 since the release of version 4.0 (one that also affected 4.0, one that did not). Neither was terribly serious for a typical X11 configuration on a single unix/linux machine, but I could imagine that the effect on a more complicated setup would be larger. So it is at least possible that switching to very recent CVS versions of gnuplot_x11 would fix one of your problems. > Questions are > 1) What is the best way to use gnuplot for real-time visualization > (are there any buffering options reducing resouces needed for redraw) If "real-time" means event-driven - there is no good way that I know of. If "real-time" means repeated refresh - it's pretty easy: load 'setup.gnu' # prepare the plot description load 'loop.gnu' # loop forever where loop.gnu contains replot pause 1 # wait 1 second before looping reread On my machine this 1 second loop and repeat consumes less than 0.5% of the CPU even for a reasonably complicated 3D surface. > 2) How to iconify gnuplot windows (other through -noraise option) > so when window is inconified gnuplot does not eat X11 resources. That is an interesting question. You will definitely need the -noraise option (or "set term x11 noraise"). But also the gnuplot_x11 program itself should check to see if it is currently iconfied, and skip at least some of its processing if so. I will have a look at what is possible. I'm not sure there is much to be gained, however. If things are working properly it shouldn't be consuming substantial resources in any case. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-29 16:23:24
|
On Thursday 28 October 2004 08:46 am, pa...@mi... wrote: > > 2) How to iconify gnuplot windows (other through -noraise option) > so when window is inconified gnuplot does not eat X11 resources. I have placed a patchset on SourceForge that causes gnuplot_x11 to skip most of the actual X11 commands if the plot window is currently iconified. It still reads and buffers new commands coming from gnuplot, however, so the CPU does not go to zero. I don't really think this will accomplish much in practice. The only way I was able to test it was to put gnuplot in an infinite loop of continual replotting. But this is not a reasonable thing to do. Anyhow, you are welcome to try it out. If it really does solve a problem, please let us know. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |