[Kst] kst 2.0 : No auto update?

[Peter Milne]

Hi Peter

On 08/20/2010 05:57 AM, Peter Kümmel wrote:
> 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.

Picking out Barth's earlier comment:
> https://bugs.kde.org/show_bug.cgi?id=248104
> --- Comment #4 from  <netterfield astro utoronto ca>  2010-08-17 23:12:36 ---
> Under 1.x, we polled the files (in the case of dirfiles, we polled a reference
> vector through the getdata library).

If the Kst 1.8 detection method is in the getdata library, and Kst 2.0 
uses the same library, then it looks like a lot of the work is already 
in place.

Although I also would agree with you, OS detect eg a notify should be 
better than polling..

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

I'll try. It may be a little difficult to snapshot the data that causes 
the fail state, since it's dynamic:
One refresh : good, Next refresh: blank, Next refresh: good

My _guess_ was that it comes up blank when some of the vectors have 
updated to N+1, but some of them are still at N. But on faking this with 
static data, Kst 2.0 shows it can handle it.

It's quite likely that the blank screens are unique to my particular 
setup, then probably shouldn't be logged as a general bug?

Is it possible to get a running error console out of Kst2.0 (like 
Firefox console)? If it said something like "refusing to plot data 
because ..." that would be helpful.


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

I'll be very happy to test it. Thank you!.

/Peter(M)


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