[Kst] [Bug 248104] DirFile on NFS change detections

[netterfield at astro.utoronto.ca]

https://bugs.kde.org/show_bug.cgi?id=248104





--- Comment #3 from  <netterfield astro utoronto ca>  2010-08-17 22:52:39 ---
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.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.