[tor-dev] Timers in Arti?

[Michael Rogers]

It's hard to say what the battery impact would be because it depends on 
what else the device is doing.

The best case for battery savings would be when the device is stationary 
with the screen turned off, no apps exempted from doze mode except the 
one running the hidden service, and no incoming push notifications. In 
that situation there should be few things bringing the device out of 
suspension, including minimal network traffic except for the app running 
the hidden service, so being able to release the wake lock and let the 
device suspend should have a relatively big impact.

Conversely if the screen is turned on, or there are a bunch of other 
apps using the network or doing background work, or push notifications 
constantly waking the device, then there will be relatively little impact.

I can run experiments to measure the savings in the ideal case, but it's 
hard to say how often that's representative of what's happening on real 
devices.

Strongly agree that it would be good to think about what Tor would look 
like if built for mobile first!

Cheers,
Michael

On 13/01/2024 15:19, Holmes Wilson wrote:
> Michael, what kind of reduction in battery impact would you expect if 
> you were able to make these changes?
> 
> Also, is anyone aware of any work that has been done within this 
> community or in academia to consider from first principles what Tor 
> would look like if built for mobile first? (e.g. built to only run when 
> an app is in the foreground, or when a notification wakes up the app.) 
> This seems like a discussion worth having once Arti settles and it's 
> easier to build new things again!
> 
> On Wed Jan 10, 2024, 11:26 AM GMT, Michael Rogers 
> <mailto:michael at briarproject.org> wrote:
> 
>     On 10/01/2024 01:46, Nick Mathewson wrote:
> 
>         On Tue, Jan 9, 2024 at 12:58 PM Micah Elizabeth Scott
>         <beth at torproject.org> wrote:
> 
> 
>             Ah. If you want to run an onion service you'll need to keep
>             at least a
>             couple circuits open continuously for the introduction
>             points. I'm not
>             sure where you would meaningfully find time to deep sleep in
>             that
>             scenario. There will be ongoing obligations from the
>             wifi/wan and tcp
>             stacks. You need a continuous TCP connection to the guard,
>             and multiple
>             circuits that are not discarded as idle. Incoming traffic on
>             those
>             circuits need to be addressed quickly or clients won't be
>             able to connect.
> 
>             If we were really optimizing for a low power mobile onion
>             service
>             platform we'd have a different way to facilitate
>             introductions without a
>             continuously open set of circuits, but that would also be
>             much more
>             abuse-prone.
> 
>             -beth
> 
> 
>         Hm. Do you know, is it possible to make network-driven wakeup events
>         relatively prompt? (Like, within a second or so if a TCP stream
>         we're
>         waiting on wakes up). If so, then onion services have a decent
>         chance
>         of being made to work.
> 
> 
>     Fantastic! Yes, the response to network events should be reasonably
>     prompt. I'll try to get some measurements.
> 
>         As for the original question about timers, it would be good to
>         know if
>         the variance between scheduled wakeup and actual wakeup can be
>         bounded, or if there's any way to mark a timer as high-priority vs
>         low-priority or something.
> 
> 
>     This is unfortunately one of those things that's constantly changing on
>     Android and varies between manufacturers. In theory we should be
>     able to
>     set a periodic alarm that fires within fifteen minutes of the last
>     firing, although not all manufacturers honour this.
> 
>     When the alarm fires the device will come out of suspension and the app
>     will be able to grab a temporary wake lock, which we can hold for some
>     amount of time (say a minute, for the sake of argument) to let Tor do
>     whatever it needs to do.
> 
>     As far as I know these alarms can only be scheduled via a Java API, so
>     Tor would either need to signal to the controller that an alarm was
>     needed, or the controller could just assume this whenever hidden
>     services were published, and wake the device every fifteen minutes
>     without explicitly communicating with Tor about alarms.
> 
>     Cheers,
>     Michael
> 
>         _______________________________________________
>         tor-dev mailing list
>         tor-dev at lists.torproject.org
>         https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
>     _______________________________________________
>     tor-dev mailing list
>     tor-dev at lists.torproject.org
>     https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 12048 bytes
Desc: OpenPGP public key
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240115/bc47df03/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240115/bc47df03/attachment.sig>