Re: KIdleTime: early and/or failing/rejected timeout detection?
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?
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?
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?
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?
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
Re: KIdleTime: early and/or failing/rejected timeout detection?
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?
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 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?
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?
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