[Kst] kst 2.0 : No auto update?

[Peter Kümmel]

Am Dienstag, den 17.08.2010, 21:21 +0100 schrieb 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.

OK, then we should at least support the kst 1.8 way of change detection.
But I will also try how the OS specific detections work.

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

Could you reproduce the blank plots? This is worth a new bugzilla entry.

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

This sounds like a very good test setup for our new detection code on
Windows!

Cheers,
Peter