Re: [i3] [i3status] Update interval alignment glitch
Hi, Marco Hunsicker wrote: It's a pity that Gereon did not comment any further. Sorry for that, but I have been on vacation for the last 12 days or so... :-) Marco Hunsicker wrote: The alignment is there purely for aesthetic reasons, right? That the clock displays the seconds in a predictable way? Yes, just as you describe a few mails later: 00 - 05 - 10 - ... Anyhow, I don't have a strong opinion about this. I just consider refreshs that are due to a USR1 exceptional and deem the default case to be more important. Ultimately, both problems are only aesthetical: ugly numbers vs. refreshs earlier than interval seconds...http://dict.leo.org/ende/index_de.html#/search=aestheticalsearchLoc=0resultOrder=basicmultiwordShowSingle=on Cheers, Gereon
Re: [i3] [i3status] Update interval alignment glitch
Hi Marco, Marco Hunsicker i...@hunsicker.de writes: I think strategy 3, i.e. refreshing upon SIGUSR1, starting with the intervals from there and still aligning to minutes, sounds like the best option. But it's only a compromise if I understand the intention of the minute aligning correctly. Why is it a compromise? What is the intention behind the minute aligning? I thought it’s to have an update at the beginning of every minute, just as we align on full seconds. This will still be true with the proposed change. And in case people who use minute alignment don’t want to have updates during the minute, they should just not send SIGUSR1 to i3status, right? -- Best regards, Michael
Re: [i3] [i3status] Update interval alignment glitch
Hi Marco, Marco Hunsicker i...@hunsicker.de writes: I'm not sure as no one really explained it. From Gereon's comment regarding ugly numbers my guess is that the alignment should make sure that the refreshes happen in a deterministic way in order to display the time information in a consistent manner. 05s - 10s- 15s - 20s. You never see 01s 02s 03s 11s etc. I see. This will still be true with the proposed change. And in case people who use minute alignment don’t want to have updates during the minute, they should just not send SIGUSR1 to i3status, right? A bit prohibitive to my liking as the signal is very useful and I would rather find a solution that works for all use cases. But then I don't I’m not sure why you say that. No matter what you align on (e.g. 05, 10, 15, as you described), the signal will always _force_ an update right now. If you don’t want that, don’t send the signal. The next update after the signal should happen at the regular interval, i.e. as if the signal was not sent. Personally, I'm fine with the patch. But in order to cater for all needs, I would find a new configuration option worth thinking about. This would enable all parties to choose the policy which makes most sense to them. The new default could be to align only once, but users would be able to disable alignment or enforce it always. I don’t think adding a configuration option for this subtlety is worth it. -- Best regards, Michael
Re: [i3] [i3status] Update interval alignment glitch
Hello Michael, A bit prohibitive to my liking as the signal is very useful and I would rather find a solution that works for all use cases. But then I don't I’m not sure why you say that. I was probably too fixated on my needs. You're right with your conclusion that someone who prefers the alignment might just want to wait a little while for the next automatic refresh. But there is still the (small) problem of misalignment after startup. I don’t think adding a configuration option for this subtlety is worth it. If you're fine with the provided patch, I certainly am. It's a pity that Gereon did not comment any further. Cheers, Marco
Re: [i3] [i3status] Update interval alignment glitch
Hello Michael, So what about a patch that inspects the time definitions to see if seconds are involved and only performs the alignment if that is the case? Unless I misunderstand what you’re trying to say, that sounds like a horrible hack, not a viable strategy :) Well, it's certainly not the cleanest approach, but as the patterns are clearly documented and probably won't change over time, it does not sound horrible to me. But you decide ;) I think strategy 3, i.e. refreshing upon SIGUSR1, starting with the intervals from there and still aligning to minutes, sounds like the best option. But it's only a compromise if I understand the intention of the minute aligning correctly. What about a general option to control the behavior of the loop? Essentially one extra line of code compared to option 3. Cheers, Marco
Re: [i3] [i3status] Update interval alignment glitch
Hello Gereon, As I don't care about an additional refresh once in a while, I'd go for the nice numbers... What are your opinions? The alignment is there purely for aesthetic reasons, right? That the clock displays the seconds in a predictable way? I don't display seconds in my clock and therefore the alignment makes no sense for me at all. So what about a patch that inspects the time definitions to see if seconds are involved and only performs the alignment if that is the case? Does that sound like a viable strategy? Thanks. Cheers, Marco
[i3] [i3status] Update interval alignment glitch
Howdy,
i3status uses the following code to determine how much time it should
wait until the output is generated again:
/* To provide updates on every full second (as good as possible)
* we don’t use sleep(interval) but we sleep until the next
* second (with microsecond precision) plus (interval-1)
* seconds. We also align to 60 seconds modulo interval such
* that we start with :00 on every new minute. */
struct timeval current_timeval;
gettimeofday(current_timeval, NULL);
struct timespec ts = {interval - 1 - current_timeval.tv_sec % interval,
(10e5 - current_timeval.tv_usec) * 1000};
This works fine if nanosleep() is not interrupted. But when interrupted
(to force an update by sending the USR1 signal), the alignment most
often means that the next invocation does not happen after 'interval'
seconds, but earlier (I'm using a 5 sec interval time)!
Would it not be more important to enforce that updates happen (roughly)
every 'interval' seconds? Is it really that important to update at the
start of a new minute anyway?
I would propose that the code is at least changed that the alignment
only happens once per minute in order to maximize correctness towards
the interval time instead of the minute alignment.
Does that sound reasonable? Thanks.
Cheers,
Marco
Re: [i3] [i3status] Update interval alignment glitch
Hi Marco, Marco Hunsicker i...@hunsicker.de writes: Would it not be more important to enforce that updates happen (roughly) every 'interval' seconds? Is it really that important to update at the start of a new minute anyway? I don’t understand why you are asking which behavior is more important. Can’t we fix this problem properly and have both? -- Best regards, Michael
Re: [i3] [i3status] Update interval alignment glitch
Hello Michael, thanks again for your quick response. Would it not be more important to enforce that updates happen (roughly) every 'interval' seconds? Is it really that important to update at the start of a new minute anyway? I don’t understand why you are asking which behavior is more important. Can’t we fix this problem properly and have both? Well, sometimes there is behavior for no good reason and if I touch the code anyway, I might as well get rid of the alignment. But if it should stay there, fine with me. I will forward a patch for review. Thanks. Cheers, Marco
Re: [i3] [i3status] Update interval alignment glitch
Hi Marco, As I'm the one who added this alignment in the first place [1], I somewhat feel obligated to answer here :-) At that time, I did not think about nanosleep() being interupted. Can you describe under which circumstances i3status receives an USR1? I've never noticed such a behavior... What would be your preferred solution here? As for me, we must decide on what we consider more important (the implementation is easy in either case): The overall number of refreshs? Have nice numbers? Possible solutions: 1) We could suppress or defer the signal and continue sleeping until the proper number of seconds have passed. Not what I'd like to do... 2) We could refresh and start with the intervals from there. This however means that we drop the alignment. This basically amounts to the code before I changed it. 3) We could refresh, start with the intervals from there and realign every minute or so. In this case, we have another shorter interval right before a new minute starts and ugly numbers in between. 4) We could refresh and return to the alignment directly afterwards. That is what happens right now. As I don't care about an additional refresh once in a while, I'd go for the nice numbers... What are your opinions? Cheers, Gereon [1] http://code.stapelberg.de/git/i3status/commit/?id=11757b8105ebebba40c3a94c5d6c5431cc58b3d1 On 03/11/2014 07:12 PM, Marco Hunsicker wrote: Hello Michael, thanks again for your quick response. Would it not be more important to enforce that updates happen (roughly) every 'interval' seconds? Is it really that important to update at the start of a new minute anyway? I don’t understand why you are asking which behavior is more important. Can’t we fix this problem properly and have both? Well, sometimes there is behavior for no good reason and if I touch the code anyway, I might as well get rid of the alignment. But if it should stay there, fine with me. I will forward a patch for review. Thanks. Cheers, Marco -- Email: gereon.kre...@rwth-aachen.de Mobil: 01520 / 9844454 Adalbertsteinweg 1b, 52070 Aachen 0x78359F29.asc Description: application/pgp-keys
Re: [i3] [i3status] Update interval alignment glitch
Hello Gereon, thanks for stepping in. As I'm the one who added this alignment in the first place [1], I somewhat feel obligated to answer here :-) At that time, I did not think about nanosleep() being interupted. I haven't checked the timeline, but that feature probably has been added later and nobody noticed the consequences. Can you describe under which circumstances i3status receives an USR1? I've never noticed such a behavior... The signal has been added to be able to force a refresh of the output from the outside. The most common example is to refresh the status if the system volume has been changed (commonly done right in the i3 config). What would be your preferred solution here? As for me, we must decide on what we consider more important (the implementation is easy in either case): The overall number of refreshs? Have nice numbers? It's really a minor issue, but I think the given interval time should matter. And yes, the number of refreshes increases if the alignment is performed on each update. Personally, I don't see a need for alignment at all, but it's no problem to support both, so this seems the way to go. Possible solutions: 1) We could suppress or defer the signal and continue sleeping until the proper number of seconds have passed. Not what I'd like to do... 2) We could refresh and start with the intervals from there. This however means that we drop the alignment. This basically amounts to the code before I changed it. 3) We could refresh, start with the intervals from there and realign every minute or so. In this case, we have another shorter interval right before a new minute starts and ugly numbers in between. 4) We could refresh and return to the alignment directly afterwards. That is what happens right now. It can happen quite often. I for one force an update on every window focus change. As I don't care about an additional refresh once in a while, I'd go for the nice numbers... What are your opinions? I'm about to submit a patch that will ensure that the minute alignment will be performed only once per minute. This ensures the given interval is obeyed as much as possible, but still perform the alignment. The best of both worlds :) Cheers, Marco
Re: [i3] [i3status] Update interval alignment glitch
Hello Gereon, 1) We could suppress or defer the signal and continue sleeping until the proper number of seconds have passed. Not what I'd like to do... 2) We could refresh and start with the intervals from there. This however means that we drop the alignment. This basically amounts to the code before I changed it. The whole point of the signal is to force a refresh immediately, so that's not really an option. 3) We could refresh, start with the intervals from there and realign every minute or so. In this case, we have another shorter interval right before a new minute starts and ugly numbers in between. That's what my patch does. What do you mean by ugly numbers? I get the feeling that I totally miss the point ;) Cheers, Marco
