Re: KIdleTime: early and/or failing/rejected timeout detection?

[René J . V . Bertin]

Actually, there is one thing I may have missed in the documentation, if it's 
there:

Is KIdleTime supposed to detect system idling, or application idling? As it 
happens, it should be possible to make a distinction between the two with the 
latest implementation I made.

As to using an agent to centralise all polling: I think that agent would either 
have to use poll timer with a sufficiently short interval to serve all clients, 
or use a poll timer per current client. Evidently the latter option cancels any 
benefit of moving to an agent-based architecture (leaving only the IPC 
overhead), while the former will lead to worse overhead than what my current 
implementation allows.
That current implementation is not expensive in its default configuration (and 
that configuration is currently decided at build time), but I think that good 
programming practice would call anyway for deactivating any KIdleTime instances 
when they are not in use, regardless of whether they're based on alarms or on 
polling.

I have no idea how many applications will be using this framework concurrently 
at any given time, but it seems reasonable to expect that there will be less 
than on a system running a KF5 plasma desktop. I see it's used in Baloo, for 
instance, but that framework has dropped support for OS X. 

There's also always the possibility to reconsider implementing an Xcb-style 
alarm based mechanism that relies on a helper process, if it turns out in the 
future that KIdleTime/Mac is causing significant amounts of overhead. But 
KIdleTime has changed only minimally from KDE4 to KF5, and it is certainly not 
the case that it has led to any observable amount of continuous overhead until 
now.

R

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[Martin Gräßlin]

Am 2015-11-18 12:33, schrieb René J. V.  Bertin:
Actually, there is one thing I may have missed in the documentation, if 
it's

there:

Is KIdleTime supposed to detect system idling, or application idling? 
As it
happens, it should be possible to make a distinction between the two 
with the

latest implementation I made.


What's an "idle application"?



As to using an agent to centralise all polling: I think that agent 
would either
have to use poll timer with a sufficiently short interval to serve all 
clients,
or use a poll timer per current client. Evidently the latter option 
cancels any

benefit of moving to an agent-based architecture (leaving only the IPC
overhead), while the former will lead to worse overhead than what my 
current

implementation allows.
That current implementation is not expensive in its default 
configuration (and
that configuration is currently decided at build time), but I think 
that good
programming practice would call anyway for deactivating any KIdleTime 
instances
when they are not in use, regardless of whether they're based on alarms 
or on

polling.


Let's assume: you have two applications performing polling at a 3 sec 
interval: this means two applications are woken up every three seconds. 
That's already 100 % more wakeups compared to a daemon solution.


The number of applications using the agent doesn't affect the usage at 
all. Why should an agent with two clients at 3 sec interval need more 
timeouts?


At max such an agent approach needs to poll in an interval serving the 
shortest timeout. This means it's as good as this one client. The other 
ones come for free. If I have one with a three second timeout and one 
with a five second interval, I only need to poll for the three second 
interval. Only if that one is hit, the five second interval becomes 
interesting.


There's also always the possibility to reconsider implementing an 
Xcb-style
alarm based mechanism that relies on a helper process, if it turns out 
in the
future that KIdleTime/Mac is causing significant amounts of overhead. 
But
KIdleTime has changed only minimally from KDE4 to KF5, and it is 
certainly not
the case that it has led to any observable amount of continuous 
overhead until

now.


NO POLLING! Given your reply here, you did not even properly consider my 
argument at all. Which is sad. I'm spending quite some time here to help 
with the OSX implementation. I could also do a "what do I care about 
OSX?" Instead I spent quite some time on it.


Cheers
Martin
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[Christoph Cullmann]

Hi,

>> There's also always the possibility to reconsider implementing an
>> Xcb-style
>> alarm based mechanism that relies on a helper process, if it turns out
>> in the
>> future that KIdleTime/Mac is causing significant amounts of overhead.
>> But
>> KIdleTime has changed only minimally from KDE4 to KF5, and it is
>> certainly not
>> the case that it has led to any observable amount of continuous
>> overhead until
>> now.
> 
> NO POLLING! Given your reply here, you did not even properly consider my
> argument at all. Which is sad. I'm spending quite some time here to help
> with the OSX implementation. I could also do a "what do I care about
> OSX?" Instead I spent quite some time on it.
I can only tell: Better no implementation than any polling implementation.

The idea of that framework is to give applications a "efficient" way to schedule
stuff to do if idle (at least I thought so).

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[Aleix Pol]

On Wed, Nov 18, 2015 at 12:33 PM, René J. V.  wrote:
> Actually, there is one thing I may have missed in the documentation, if it's
> there:
>
> Is KIdleTime supposed to detect system idling, or application idling? As it
> happens, it should be possible to make a distinction between the two with the
> latest implementation I made.
>
> As to using an agent to centralise all polling: I think that agent would 
> either
> have to use poll timer with a sufficiently short interval to serve all 
> clients,
> or use a poll timer per current client. Evidently the latter option cancels 
> any
> benefit of moving to an agent-based architecture (leaving only the IPC
> overhead), while the former will lead to worse overhead than what my current
> implementation allows.
> That current implementation is not expensive in its default configuration (and
> that configuration is currently decided at build time), but I think that good
> programming practice would call anyway for deactivating any KIdleTime 
> instances
> when they are not in use, regardless of whether they're based on alarms or on
> polling.
>
> I have no idea how many applications will be using this framework concurrently
> at any given time, but it seems reasonable to expect that there will be less
> than on a system running a KF5 plasma desktop. I see it's used in Baloo, for
> instance, but that framework has dropped support for OS X.
>
> There's also always the possibility to reconsider implementing an Xcb-style
> alarm based mechanism that relies on a helper process, if it turns out in the
> future that KIdleTime/Mac is causing significant amounts of overhead. But
> KIdleTime has changed only minimally from KDE4 to KF5, and it is certainly not
> the case that it has led to any observable amount of continuous overhead until
> now.
>
> R

After a quick search, here's some relevant documentation by Apple:
https://developer.apple.com/library/mac/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/

They suggest you going "App Nap" as soon as possible. Polling from a
framework would ensure this doesn't really happen.

Here's an approach that could maybe inspire you somehow:
http://stackoverflow.com/questions/1419531/mac-screensaver-start-event

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[René J . V . Bertin]

Martin Graesslin wrote:


> I don't really understand. How can it signal too early?

I was wrong about the MS Windows implementation, but from WidgetBasedPoller:

Q_FOREACH(int timeOut, m_timeouts) {
if ( ( timeOut - idle < 300 && timeOut >= idle ) || ( idle - timeOut < 
300 && idle > timeOut ) ) {
// Bingo!
emit timeoutReached( timeOut );
}
}

that code accepts any idle value that is within ±300ms of timeOut. Since idle 
increases monotonically after onset, and if comparisons are done often enough, 
the code will signal up to 300ms early.

> I can say for Wayland as I wrote that recently:

I'm guessing Wayland will provide a mechanism that's inspired by what Xcb 
provides?

> * it will fire if it's hit - there might be a delay which I think doesn't
> matter in the case of being swapped out.

Do you mean that the delay is independent of whether or not you're swapped out, 
or that the question of how long the delay is is moot if you are (were) swapped 
out? It will "Fire if it's hit", but what "it" doesn't get hit at the 
configured 
time but at a later time?

> The Wayland implementation doesn't give a guarantee that if there is an idle
> time of 5 sec it will be signalled exactly after 5 sec. That's something a
> non-realtime system cannot provide.

Of course not. But that doesn't mean it is pointless to try to minimise the 
delay (for instance by polling ;))
To put this into perspective: the last thing I wrote in this context was an 
extension to Matlab/Simulink that allowed to run a compiled Simulink model 
realtime on a sufficiently fast host, without need for special realtime 
hardware.
Let's be clear about this: true realtime indeed requires a special system, or 
at 
the very least support from the OS, and the appropriate coding approach in your 
own application. I have a hunch that Qt is already used "that way" (it exists 
on 
Qnx after all). There aren't that many applications that need 100%, "hard" 
realtime behaviour (as opposed to only a fraction of their running time). 
Realtime also isn't necessarily about the lowest possible delays (they just 
need 
to be known and more or less constant). OTOH there are many more types of 
applications that want to be perceived to run in real time, with the smallest 
possible delays. IMHO those kind of applications (games, simulators, 
psychophysics or other empirical software, ...) are much more likely to resort 
to convenience frameworks like those provided by KF5.
(I was going to add "apps for controlling little trains" but those probably 
have 
little need for KIdleTime, just for other time-related functions with 
comparable 
"good" behaviour :))

> And honestly I don't think it matters. KIdleTime is about being noticed about
> being idle. We are talking here about timeouts which are in an area where
> realtime doesn't matter [...]
> If you want
> to use KIdleTime for anything below let's say half a minute, I think it's the
> wrong tool for it.

And I really don't see the point in providing a framework for this (and 
basically only this) if it's not going to try to be as versatile as possible. 
It 
can and should aim to avoid hogging any resources in the default configuration. 
But as it happens it is actually more complicated to implement that than to 
implement the basic approach that can also provide the best precision and 
detection delays. I think the framework becomes more versatile if it allows 
users to switch it to a more precise/powerful and (possibly) more intrusive 
mode.
If of course the majority of major platforms on which it is deployed support 
the 
kind of precision I'm thinking of.

BTW, the exact durations are inconsequential (as long as they're above what can 
be timed a reasonable precision). It's not because you're interested to learn 
if 
an application has been idle for 10min that all of a sudden it becomes more 
acceptable to detect that with a much worse precision.

And FWIW: any backend that's based on QTimer and use Qt::PreciseTimer to 
achieve 
better than 5% error (= at least ms accuracy).

R.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[Martin Graesslin]

On Tuesday, November 17, 2015 5:04:09 PM CET René J. V. Bertin wrote:
> > I can say for Wayland as I wrote that recently:
> I'm guessing Wayland will provide a mechanism that's inspired by what Xcb
> provides?

eh no. As I control both the server (hello KWin) and the client (hello 
KWayland) I just designed a protocol which is ideal for KIdleTime.

> 
> > * it will fire if it's hit - there might be a delay which I think doesn't
> > matter in the case of being swapped out.
> 
> Do you mean that the delay is independent of whether or not you're swapped
> out, or that the question of how long the delay is is moot if you are
> (were) swapped out? It will "Fire if it's hit", but what "it" doesn't get
> hit at the configured time but at a later time?

Sorry, but I just don't get your problem here. This all sounds highly 
theoretical to me and is nothing which I considered at all.

The implementation is basically:
* Wayland client registers an idle timeout
* KWayland::Server creates a QTimer
* on each input event the QTimer is restarted
* if the QTimer times out in the Wayland server the Wayland client is notified

Now this includes a few IPC roundtrips which are completely outside the 
control of my code. Like the last step. What do I know when the client will be 
notified by the kernel about it?

> 
> > The Wayland implementation doesn't give a guarantee that if there is an
> > idle time of 5 sec it will be signalled exactly after 5 sec. That's
> > something a non-realtime system cannot provide.
> 
> Of course not. But that doesn't mean it is pointless to try to minimise the
> delay (for instance by polling ;))

There is absolutely zero polling in the Wayland implementation!

> And I really don't see the point in providing a framework for this (and
> basically only this) if it's not going to try to be as versatile as
> possible. It can and should aim to avoid hogging any resources in the
> default configuration.

Repeat after me: no polling! I mean that: NO POLLING! Don't add code which 
polls. Don't do that.

NO POLLING!

If you cannot do that on OSX, I really think it's better to not provide it. If 
you think it's unfair that there is a backend for X11 which performs polling, 
then I'm going to delete the XScreenSaver based one.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[Martin Graesslin]

On Tuesday, November 17, 2015 2:59:57 PM CET René J.V. Bertin wrote:
> KIdleTime really seems to have captured my attention - it's after all very
> closely related to "problems" I've had to solve more than a few times in a
> previous life.
> 
> Currently, the MS Windows and OS X backends have 2 issues with detecting &
> signalling idle timeouts, aside from the fact they allow a heavy margin of
> error:
> 
> - timeouts can be (and are) signalled early (by up to the detection margin).
> I tend to think that time delays should not never be reported early. -
> timeouts can fail to be reported if detected too late.

I don't really understand. How can it signal too early?

> What does the XCB alarm-based mechanism do in this case? I would expect an
> alarm to fire even if it's late, rather than being missed completely. Also,
> does the XCB implementation allow for early reporting of timeouts?

I can say for Wayland as I wrote that recently:
* it cannot fire too early
* it will fire if it's hit - there might be a delay which I think doesn't 
matter in the case of being swapped out.

The Wayland implementation doesn't give a guarantee that if there is an idle 
time of 5 sec it will be signalled exactly after 5 sec. That's something a 
non-realtime system cannot provide.

And honestly I don't think it matters. KIdleTime is about being noticed about 
being idle. We are talking here about timeouts which are in an area where 
realtime doesn't matter and also being swapped out doesn't matter. If you want 
to use KIdleTime for anything below let's say half a minute, I think it's the 
wrong tool for it.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KIdleTime: early and/or failing/rejected timeout detection?

[René J . V . Bertin]

KIdleTime really seems to have captured my attention - it's after all very 
closely related to "problems" I've had to solve more than a few times in a 
previous life.

Currently, the MS Windows and OS X backends have 2 issues with detecting & 
signalling idle timeouts, aside from the fact they allow a heavy margin of 
error:

- timeouts can be (and are) signalled early (by up to the detection margin). I 
tend to think that time delays should not never be reported early.
- timeouts can fail to be reported if detected too late.

For that 2nd point, consider an application that has a timeout set for 5s and 
that got swapped out, or that for some other reason detects too late that it 
has been idle for 5s. If this is detected at, say, 6.5s, there still has been 
5s of idletime, but since the current idle time is outside the margin of error 
it is not signalled.

What does the XCB alarm-based mechanism do in this case? I would expect an 
alarm to fire even if it's late, rather than being missed completely.
Also, does the XCB implementation allow for early reporting of timeouts?

I'd test this empirically, but my current Linux systems aren't suitable for 
this kind of work.

R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[René J . V . Bertin]

Martin Graesslin wrote:


> NO POLLING!
> 
> If you cannot do that on OSX, I really think it's better to not provide it. If
> you think it's unfair that there is a backend for X11 which performs polling,
> then I'm going to delete the XScreenSaver based one.

I'm not adding code that polls, I'm modifying an implementation that polls. I'm 
even making it less dependent on frequent polling in its default configuration, 
inspired by WidgetBasedPoller.

I'm not touching your Wayland implementation, nor the Xcb implementation, but I 
don't see your gripe with changing things in code that is written by someone 
else...

If developing KF5 frameworks isn't a democratic endeavour I don't really see 
what I'm doing here either.

R.

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KIdleTime: early and/or failing/rejected timeout detection?

[Martin Graesslin]

On Tuesday, November 17, 2015 6:33:17 PM CET René J. V. Bertin wrote:
> Martin Graesslin wrote:
> > NO POLLING!
> > 
> > If you cannot do that on OSX, I really think it's better to not provide
> > it. If you think it's unfair that there is a backend for X11 which
> > performs polling, then I'm going to delete the XScreenSaver based one.
> 
> I'm not adding code that polls, I'm modifying an implementation that polls.
> I'm even making it less dependent on frequent polling in its default
> configuration, inspired by WidgetBasedPoller.
> 
> I'm not touching your Wayland implementation, nor the Xcb implementation,
> but I don't see your gripe with changing things in code that is written by
> someone else...
> 
> If developing KF5 frameworks isn't a democratic endeavour I don't really see
> what I'm doing here either.

erm, I don't see how you can come to that conclusion. I'm providing my 
feedback here based on the fact that I recently:

* changed KIdleTime to use plugins
* implemented a Wayland backend

The feedback I'm giving you is "no polling". You so far ignored this feedback 
and came up with very confusing mails about things which absolutely do not 
matter in the framework and stuff like optimal polling intervals and what not. 
All things that are completely irrelevant if you don't use polling. This makes 
the interaction very difficult, because I have a feeling of being ignored and 
having to explain things again and again.

Now of course I care about the implementation of KIdleTime on OSX. KIdleTime 
is a useful framework, but if it polls it's in my opinion a useless framework 
and hardly useable for applications. The idea of the framework is to be 
smarter than what applications would come up with. If the implementation polls 
it triggers wakeups in each application which uses it. This is bad, I hope I 
don't have to explain how bad it is. And this is completely independent on 
whether the code already polled or not. We have a common code ownership and 
this includes that I do care about the implementation on other platforms. 
Especially as I have written one of the supported platforms. At the moment 
there is nobody in KDE who could provide you better feedback on the framework, 
please don't ignore it.

It is relatively easy to change the architecture in ways that it doesn't poll 
in each application. If it's really impossible to do this without polling: 
create a dedicated process which does the polling for all other users. It's 
easy to come up with such solutions: all it needs is taking a step back when 
getting feedback which is "no polling".

Other solutions could involve looking at what OSX provides and not 
implementing everything. E.g. on Wayland I decided to not implement 
forcePollRequest because I considered this as exposing information a Wayland 
client is not proposed to get. Platform abstracted code also means to look at 
a platform and decide what's doable and what not.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel