[Kst] kst 2.0 : No auto update?
Peter.Milne at d-tacq.com
Tue Aug 17 22:21:24 CEST 2010
After handling more data ..
On 08/17/2010 09:49 AM, Peter Milne wrote:
> On 08/17/2010 12:21 AM, Peter Kümmel wrote:
>>> We'll get by with pressing the "Reload" button so long, I'll try the
>>> threaded timer hack some time.
>> Is it a solution to simply trigger a "Reload" automatically by a timer,
>> without touching any 'watcher' code?
> Yes. Simply pressing the button works OK, so a timer maybe would be
> better. Other than every so often the refresh is bad, maybe because Kst
> is reading data as it is being updated at the source. And there'd need
> to be a timer-disable button to stop reloading in the cases where the
> data is static.
Actually, can I change that to a "No" here..
Currently running with a system where it has been acquiring for some
minutes. So the low-rate data file is getting quite long (12000) points
On my Linux desktop, running Kst 1.8, plotting the last 100 points on 32
channels, count-from-end 100 frames, the plot is nice and smooth, with
at least one update per second.
Compare with Kst 2.0, running on the same computer, reading the same
network-mounted data source, press refresh, count to 6s. It feels really
slow, and we can only expect it to get slower. Worse sometimes the plot
comes up blank - probably some clash with the data producer process.
> Doing a full Reload is of course forcing Kst to re-read all the data,
> that could end up causing a lot of network traffic, whereas a
> file-change-notify certainly only triggers on change, and, depending on
> how the file read logic is structured, maybe only the new data has to be
> read, rather than _all_ the data?. There's still the possibility of a
> data fetch clashing with a data put, but that may be lower since the two
> actions are now in sequence.
The data source isn't particularly quick, it's a SAMBA export competing
for time on a 400MHz embedded processor that also happens to be
processing a 64MB/s data stream to memory - so brute force methods are
not advised, it's clearly better to track the head of the files as Kst
Peter Milne Peter.Milne at d-tacq.com
D-TACQ Solutions Ltd www.d-tacq.com
More information about the Kst