Timeout after 30 seconds + Suspend/Resume

[Ryan Hamilton]

Howdy Folks,

We have some chromium code which attempts to timeout after 30 seconds of idle. We use TimeTicks to measure elapsed time, as per the advice in base/time.h. However, we've noticed that on Android, at least, TimeTicks may "stand still" between suspend and resume (again, as per the comments in base/time.h). This means that comparing base::TimeTicks::Now() to base::TimeTicks start_ does not do the right thing in this case. We could plausibly hook into OnSuspend/OnRestore to get a base::Time values which would let us understand how much time has elapsed during the suspend, but I'm wondering if there is a better solution for this? (Or if I'm doing something obviously wrong).

Cheers,

Ryan

[Peter Kasting]

On Fri, Nov 4, 2016 at 2:09 PM, Ryan Hamilton <r...@chromium.org> wrote:

Howdy Folks,

We have some chromium code which attempts to timeout after 30 seconds of idle. We use TimeTicks to measure elapsed time, as per the advice in base/time.h. However, we've noticed that on Android, at least, TimeTicks may "stand still" between suspend and resume (again, as per the comments in base/time.h). This means that comparing base::TimeTicks::Now() to base::TimeTicks start_ does not do the right thing in this case. We could plausibly hook into OnSuspend/OnRestore to get a base::Time values which would let us understand how much time has elapsed during the suspend, but I'm wondering if there is a better solution for this? (Or if I'm doing something obviously wrong).

Does Time track the wall clock time change?

A crude solution might be to use the max delta(Time::Now() - old_time, TimeTicks::Now() - old_time_ticks), but in cases like DST or manual user clock adjustments that could return large values when not much "real world time" had passed.

IIRC brettw originally wrote the Time classes, maybe he has advice.

PK

[Dale Curtis]

OnSuspend/OnResume should no longer fire on Android since they don't mean the same thing as other platforms. https://codereview.chromium.org/2324923002/ Which suspend/resume mechanism are you referring to?

- dale

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Justin DeWitt]

I think this also manifests on desktop platforms when you, for example, suspend by closing the lid of your laptop.  My team encountered this there when using the chrome.alarms API, which uses TimeTicks under the hood IIRC.  We didn't ever come up with a great solution.

Justin

--

[Charles Harrison]

+mui, charliea

This came up recently in a different Chrome bug regarding cookie expiration after suspend. It happens on desktop platforms as well.

Time should track the wall clock time change, but suffers from all sorts of weirdness like non-slewed clock adjustments.

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Ryan Hamilton]

On Fri, Nov 4, 2016 at 2:17 PM, Peter Kasting <pkas...@chromium.org> wrote:

On Fri, Nov 4, 2016 at 2:09 PM, Ryan Hamilton <r...@chromium.org> wrote:

Howdy Folks,

We have some chromium code which attempts to timeout after 30 seconds of idle. We use TimeTicks to measure elapsed time, as per the advice in base/time.h. However, we've noticed that on Android, at least, TimeTicks may "stand still" between suspend and resume (again, as per the comments in base/time.h). This means that comparing base::TimeTicks::Now() to base::TimeTicks start_ does not do the right thing in this case. We could plausibly hook into OnSuspend/OnRestore to get a base::Time values which would let us understand how much time has elapsed during the suspend, but I'm wondering if there is a better solution for this? (Or if I'm doing something obviously wrong).

Does Time track the wall clock time change?

​My understanding is yes.​

 

A crude solution might be to use the max delta(Time::Now() - old_time, TimeTicks::Now() - old_time_ticks), but in cases like DST or manual user clock adjustments that could return large values when not much "real world time" had passed.

​Yeah, this was exactly what I was thinking.

IIRC brettw originally wrote the Time classes, maybe he has advice.

​/me waits anxiously! :)

[Ryan Hamilton]

On Fri, Nov 4, 2016 at 2:27 PM, Dale Curtis <dalec...@chromium.org> wrote:

OnSuspend/OnResume should no longer fire on Android since they don't mean the same thing as other platforms. https://codereview.chromium.org/2324923002/ Which suspend/resume mechanism are you referring to?

As it happens I just discovered that CL, so I'm not sure where I'd hook into :) I could do the time fixup in some entry points into my code if I can't hook into suspend/resume. But it'd be nice if this were solved in a general way.​

[Ryan Hamilton]

On Fri, Nov 4, 2016 at 2:29 PM, Charles Harrison <cshar...@google.com> wrote:

+mui, charliea

This came up recently in a different Chrome bug regarding cookie expiration after suspend. It happens on desktop platforms as well.

Time should track the wall clock time change, but suffers from all sorts of weirdness like non-slewed clock adjustments.

​Yeah, exactly. This seems like it's screaming out for a chrome-wide solution...​

[Dale Curtis]

Sorry I should have been clearer, it seems surprising that time ever stops moving on Android; that would mean there does exist a real suspend/resume mode. On desktop it's understandable that time will stop and suddenly jump in that case; the typical solution is to invalidate on suspend / resume. I agree a wrapper could be helpful for this behavior, we have a few monitors that need this.

- dale

[Ryan Hamilton]

On Fri, Nov 4, 2016 at 2:39 PM, Dale Curtis <dalec...@chromium.org> wrote:

Sorry I should have been clearer, it seems surprising that time ever stops moving on Android; that would mean there does exist a real suspend/resume mode.

Ah, I understand now. So this is happening in an Android app using cronet on an Android Wear device. Looking at output from logs and net-internals, we see what appears to be ~20 seconds of time stamps which span an actually 50 second interval (by looking at a clock while this happens). In the middle of this run, the device ... goes to sleep/power save/something ... for 30 seconds. When it wakes up, time appears to not have moved. 

The chrome CL you mentioned earlier remove the calls from the .java code because they were triggering OnSuspend/OnRestore based on things which are not actually suspending, merely going into the background. However, it's not clear to me from that CL that the Android OS does not have suspend/resume, merely that the .java code in Chrome doesn't.

 

On desktop it's understandable that time will stop and suddenly jump in that case; the typical solution is to invalidate on suspend / resume. I agree a wrapper could be helpful for this behavior, we have a few monitors that need this.

​Makes sense.​

[Dale Curtis]

When I wrote that CL we couldn't find any real cases of suspend resume on Android; just an abuse of an idle signal. If there's a actually a real suspend/resume signal on Android we can (and should) hook that back up.

- dale

[Ryan Hamilton]

On Fri, Nov 4, 2016 at 2:53 PM, Dale Curtis <dalec...@chromium.org> wrote:

When I wrote that CL we couldn't find any real cases of suspend resume on Android; just an abuse of an idle signal. If there's a actually a real suspend/resume signal on Android we can (and should) hook that back up.

​Just to make sure I understand what you're saying... You think that Android devices do actually suspend/resume​

 

​(sleep/wake?) but you're not sure if there is an API by which applications can detect this condition?​

[Dale Curtis]

I'm only going on what you've said. Your comments seem to be indicating that Android Wear does have suspend type functionality.

Whether there's actually a true suspend/resume type sequence and if there's an API for such functionality -- I don't know. I'd try to find someone on the Wear team and ask them.

- dale

[Yuri Wiitala]

The original post said, "some chromium code which attempts to timeout after 30 seconds of idle." So, why is it a problem that TimeTicks clock freezes during system suspend? If the system is asleep after 30 "real-world" seconds have elapsed, your timeout handler could not run anyway.

If it's important to run the timeout handler the instant the system resumes, then I'd suggest you actually monitor system suspend/resume events; and call your timeout handler on resume to check whether 30 seconds have actually passed. Because you know TimeTicks clock has frozen, the only other clock available to check this is base::Time clock. However, I'd imagine OS authors would very likely make discontinuous adjustments to that clock right at system resume time. So, this may be very error-prone.

BTW--Do our APIs for system resume events include information on how long the system was suspended? Maybe that's all you need?

Note: The need for a TimeTicks clock that doesn't freeze has come up on a few occasions for other Chromium features. None that I'm aware of solved this problem directly (i.e., usually a design change or trade-off was made to resolve an issue). However, on Linux, CLOCK_BOOTTIME was introduced to solve this exact problem (http://man7.org/linux/man-pages/man2/clock_gettime.2.html). I'm not sure about other platforms (I'd have to research that). So, perhaps it makes sense to introduce another type of monotonic tick clock in base/time? Comments?

[Matthew Menke]

On Friday, November 4, 2016 at 7:35:38 PM UTC-4, Yuri Wiitala wrote:

The original post said, "some chromium code which attempts to timeout after 30 seconds of idle." So, why is it a problem that TimeTicks clock freezes during system suspend? If the system is asleep after 30 "real-world" seconds have elapsed, your timeout handler could not run anyway.

If it's important to run the timeout handler the instant the system resumes, then I'd suggest you actually monitor system suspend/resume events; and call your timeout handler on resume to check whether 30 seconds have actually passed. Because you know TimeTicks clock has frozen, the only other clock available to check this is base::Time clock. However, I'd imagine OS authors would very likely make discontinuous adjustments to that clock right at system resume time. So, this may be very error-prone.

BTW--Do our APIs for system resume events include information on how long the system was suspended? Maybe that's all you need?

Per earlier comments on this thread, it's unclear if there's even an API on Android to watch for suspend events.
 

[Ryan Hamilton]

On Fri, Nov 4, 2016 at 4:34 PM, Yuri Wiitala <m...@chromium.org> wrote:

The original post said, "some chromium code which attempts to timeout after 30 seconds of idle." So, why is it a problem that TimeTicks clock freezes during system suspend? If the system is asleep after 30 "real-world" seconds have elapsed, your timeout handler could not run anyway.

​Ah. Because this is a network idle timeout that both the client (Chrome) and the server negotiate. After 30 seconds of idle, the connection is closed by the server. When Chrome wakes up later than that, the connection is h0zed. Now, we can add retry-logic to work around this. But it'd be nice to avoit this problem.​

 

If it's important to run the timeout handler the instant the system resumes, then I'd suggest you actually monitor system suspend/resume events; and call your timeout handler on resume to check whether 30 seconds have actually passed. Because you know TimeTicks clock has frozen, the only other clock available to check this is base::Time clock. However, I'd imagine OS authors would very likely make discontinuous adjustments to that clock right at system resume time. So, this may be very error-prone.

BTW--Do our APIs for system resume events include information on how long the system was suspended? Maybe that's all you need?

​Alas, it appears that no such API exists on Android :(

​

 

Note: The need for a TimeTicks clock that doesn't freeze has come up on a few occasions for other Chromium features. None that I'm aware of solved this problem directly (i.e., usually a design change or trade-off was made to resolve an issue). However, on Linux, CLOCK_BOOTTIME was introduced to solve this exact problem (http://man7.org/linux/man-pages/man2/clock_gettime.2.html). I'm not sure about other platforms (I'd have to research that). So, perhaps it makes sense to introduce another type of monotonic tick clock in base/time? Comments?

​Yeah, that sounds quite useful.