Hi,
When running hidden services on Android I've found it's necessary to hold a wake lock to keep the CPU awake. Otherwise Tor's second_elapsed_callback() doesn't get called once per second. When the CPU eventually wakes and the callback is called, if 100 seconds or more have passed since the last call, second_elapsed_callback() calls circuit_note_clock_jumped(), which marks any dirty circuits as unusable.
If I understand right, this will have the effect of breaking any existing connections to the hidden service and making the service unreachable until it's built new intro circuits and published a new descriptor.
#8239, #16387 and #19522 might help to reduce the downtime by improving our chances of reusing the same intro points, but we'd still lose the existing circuits.
It would be nice if we could avoid this downtime without holding a permanent wake lock, which has a big impact on battery life.
A possible workaround would be to use Android's alarm API to wake the controller process once per minute. The controller process can acquire a wake lock for a couple of seconds to allow second_elapsed_callback() to be called, then release the lock until the next alarm.
However, it's pretty clear that Tor wants the callback to be called once per second and gets nervous if that doesn't happen, so I wanted to ask about the implications of calling the callback once or twice per minute before pursuing this idea further. Is it in any way sane?
Another possibility would be to look into how Libevent's timers work. Perhaps we can ensure that the timers wake the CPU on Android, so second_elapsed_callback() and any other timer-based functions get called without keeping the CPU permanently awake?
Thanks, Michael
On Thu, Dec 1, 2016 at 9:54 AM, Michael Rogers michael@briarproject.org wrote:
Hi,
When running hidden services on Android I've found it's necessary to hold a wake lock to keep the CPU awake. Otherwise Tor's second_elapsed_callback() doesn't get called once per second. When the CPU eventually wakes and the callback is called, if 100 seconds or more have passed since the last call, second_elapsed_callback() calls circuit_note_clock_jumped(), which marks any dirty circuits as unusable.
If I understand right, this will have the effect of breaking any existing connections to the hidden service and making the service unreachable until it's built new intro circuits and published a new descriptor.
#8239, #16387 and #19522 might help to reduce the downtime by improving our chances of reusing the same intro points, but we'd still lose the existing circuits.
It would be nice if we could avoid this downtime without holding a permanent wake lock, which has a big impact on battery life.
A possible workaround would be to use Android's alarm API to wake the controller process once per minute. The controller process can acquire a wake lock for a couple of seconds to allow second_elapsed_callback() to be called, then release the lock until the next alarm.
However, it's pretty clear that Tor wants the callback to be called once per second and gets nervous if that doesn't happen, so I wanted to ask about the implications of calling the callback once or twice per minute before pursuing this idea further. Is it in any way sane?
That's a hard question! We'd need to audit everything in second_elapsed_callback() to see what would actually happen if it weren't called so often. In many cases, it might be that we could make it happen only as needed, or more infrequently, without bad consequences... but I can't be too sure without going through all the code.
It's not crazy to try it and find out what breaks; let us know if you try?
Another possibility would be to look into how Libevent's timers work. Perhaps we can ensure that the timers wake the CPU on Android, so second_elapsed_callback() and any other timer-based functions get called without keeping the CPU permanently awake?
Interesting; I'd like to pursue that one too, but I don't know much about timed cpu waking on android; could you link to some good documentation?
best wishes,
On 02/12/16 16:56, Nick Mathewson wrote:
On Thu, Dec 1, 2016 at 9:54 AM, Michael Rogers michael@briarproject.org wrote:
Hi,
When running hidden services on Android I've found it's necessary to hold a wake lock to keep the CPU awake. Otherwise Tor's second_elapsed_callback() doesn't get called once per second. When the CPU eventually wakes and the callback is called, if 100 seconds or more have passed since the last call, second_elapsed_callback() calls circuit_note_clock_jumped(), which marks any dirty circuits as unusable.
If I understand right, this will have the effect of breaking any existing connections to the hidden service and making the service unreachable until it's built new intro circuits and published a new descriptor.
#8239, #16387 and #19522 might help to reduce the downtime by improving our chances of reusing the same intro points, but we'd still lose the existing circuits.
It would be nice if we could avoid this downtime without holding a permanent wake lock, which has a big impact on battery life.
A possible workaround would be to use Android's alarm API to wake the controller process once per minute. The controller process can acquire a wake lock for a couple of seconds to allow second_elapsed_callback() to be called, then release the lock until the next alarm.
However, it's pretty clear that Tor wants the callback to be called once per second and gets nervous if that doesn't happen, so I wanted to ask about the implications of calling the callback once or twice per minute before pursuing this idea further. Is it in any way sane?
That's a hard question! We'd need to audit everything in second_elapsed_callback() to see what would actually happen if it weren't called so often. In many cases, it might be that we could make it happen only as needed, or more infrequently, without bad consequences... but I can't be too sure without going through all the code.
It's not crazy to try it and find out what breaks; let us know if you try?
Another possibility would be to look into how Libevent's timers work. Perhaps we can ensure that the timers wake the CPU on Android, so second_elapsed_callback() and any other timer-based functions get called without keeping the CPU permanently awake?
Interesting; I'd like to pursue that one too, but I don't know much about timed cpu waking on android; could you link to some good documentation?
I'll spare you a long rant about the quality of Android's documentation and just say that I looked into this, and in summary, an unprivileged process can't use native calls to schedule alarms that will wake the CPU.
(There may be a few devices where alarm timer support is enabled in the kernel, *and* timerfd_create() supports the relevant clocks, *and* it hasn't yet been patched to check the CAP_WAKE_ALARM capability like timer_create() does, but those devices will never be the majority.)
Unfortunately, I also found that in doze mode, which was introduced in Android M, alarms can't be scheduled via the Android API more frequently than once every nine minutes. I don't think we can realistically expect to refactor second_elapsed_callback() to be called once every nine minutes, especially if no other timers can fire during that time. So my original question is moot. We'll have to stick with a wake lock.
I would just like to plant the seed of a thought, though. Is it possible to imagine a protocol for connecting a service to Tor, such that the device running the service can sleep for long periods without losing connectivity?
This has two variants. In the easy variant, the device can wake up to handle network traffic. In the hard variant, the device can't wake up until its next alarm.
This list probably isn't the place to discuss solutions to that problem - I just mention it as food for thought.
Cheers, Michael
On 8 Dec. 2016, at 01:20, Michael Rogers michael@briarproject.org wrote:
...
I'll spare you a long rant about the quality of Android's documentation and just say that I looked into this, and in summary, an unprivileged process can't use native calls to schedule alarms that will wake the CPU.
(There may be a few devices where alarm timer support is enabled in the kernel, *and* timerfd_create() supports the relevant clocks, *and* it hasn't yet been patched to check the CAP_WAKE_ALARM capability like timer_create() does, but those devices will never be the majority.)
Unfortunately, I also found that in doze mode, which was introduced in Android M, alarms can't be scheduled via the Android API more frequently than once every nine minutes. I don't think we can realistically expect to refactor second_elapsed_callback() to be called once every nine minutes, especially if no other timers can fire during that time. So my original question is moot. We'll have to stick with a wake lock.
I would just like to plant the seed of a thought, though. Is it possible to imagine a protocol for connecting a service to Tor, such that the device running the service can sleep for long periods without losing connectivity?
This has two variants. In the easy variant, the device can wake up to handle network traffic. In the hard variant, the device can't wake up until its next alarm.
This list probably isn't the place to discuss solutions to that problem
- I just mention it as food for thought.
Please feel free to log tickets for these issues. We can consider them as part of our upcoming mobile device work.
T
-
Michael Rogers -
Nick Mathewson -
teor