[Kst] kst 2.0 : No auto update?

[Peter Milne]

Peter

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 
and growing.

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 
1.8 does.


Best regards


Peter.





-- 
Peter Milne			Peter.Milne at d-tacq.com
D-TACQ Solutions Ltd		www.d-tacq.com