[Thali-talk] Interesting article on issues, quirks, etc. with Wi-Fi Direct on Android

[Michael Rogers]

Hi Jukka,

I'm sorry for taking so long to reply to this. I guess it's probably too
late now, but just in case...

On 13/04/15 10:02, Jukka Silvennoinen wrote:
> Would you have good suggestion on how to get the discovery working in
> a way that it would be always on, as well as it would consume as
> little battery as possible ?
> 
> I'm having some issue here, first when I started looking into the
> "normal" way, i.e. first discovering peers & then going for service
> discovery, I did notice that there are repeating patterns seen in
> discovery data (http://www.drjukka.com/blog/wordpress/?p=52),
> basically some time-periods we don't get any services.

Very interesting data - thanks for publishing it!

I'm afraid I don't understand the logic for starting and stopping peer
discovery and service discovery. From the description on the blog it
sounds like you're starting peer discovery more than once, but the docs
say that discovery remains active until a connection is initiated or a
P2P group is formed. (Ah! I've just realised why creating a legacy mode
AP seemed to interfere with peer discovery!) Also, I don't think you
need to use peer discovery at all if you just want to discover services.
Have you tried using service discovery without peer discovery?

> The behavior is similar with all my test devices, though different
> devices & firmware's have different timings on the behavior. All and
> all, they all stop receiving any service's on some point, and then on
> some point of time, they suddenly start getting them again.
> Interestingly the power consumption appears to be more-of-less same
> all times :)

Are the devices going into some kind of sleep state? Does your app
acquire a wake-lock? What's the value of Settings > Wi-Fi > Advanced >
Keep Wi-Fi On During Sleep?

I wonder whether the looser timings on Lollipop might indicate that
discovery uses some kind of background task that's been moved from an
exact alarm to an inexact alarm in Lollipop, perhaps to save power...

https://developer.android.com/training/scheduling/alarms.html

That's just speculation though.

> Then, I did test the power consumption without having Service
> discovery on, and just having Peer discovery done, and figured out
> that in my testing environment, its killing the batterylife even
> faster, thus giving me a feeling that maybe I could simply go doing
> the Service discovery strait away.

Going straight to service discovery sounds like a good move. I'm
surprised that peer discovery uses more power. In this test, were you
starting peer discovery more than once?

> Also the P2Feed did suggest that we should "Use service discovery
> (not peer discovery) to find nearby phones", anyways I suspect that
> their use case is, just like most of the use cases, loads simpler
> than mine. I.e. they don't really scan for services all times, but
> only when requested.
> 
> And the reason why I'm saying this, is my latest data I have been
> receiving from my tests over the last week or so. Which indicates
> similar issue as with the "normal" way, i.e. we do stop discovering
> any services after some time. Unfortunately, I have been unable to
> get back on receiving services, thus currently not really seeing this
> as an alternative.

Does this happen when you combine peer discovery with service discovery,
or when you use service discovery on its own, or both?

> See the attached picture for the data summery. - Blue line: started,
> is counter for event when we start requesting for services to be
> discovered - orange line: got, is counter of how many service
> discoveries we actually made (there is timer which prevent counting
> results multiple times for same requests), thus if got == started, we
> are working really excellently - Gray line, Reset counter, is counter
> which counts the times our time-out-timer has been triggered. Will be
> triggered is no services are discovered within a minute, will start
> new service request. - Yellow line, Peers requested, is a counter for
> event when we actually started peer-discovery (tried to kick-start
> the service discovery with this)
> 
> I tried also re-initializing the channel, and re-creating Service
> discovery as well as local service advertising each time the reset
> time-out timer is triggered. The peer discovery is only started only
> just before we start service discoveries, and then again once we get
> WIFI_P2P_DISCOVERY_STOPPED, event, basically meaning that it should
> be on all times.
> 
> Still as the data shows, I'm not getting service's discovered after
> some time, and the discovery is never started again. With N5 Kitkat
> versions, this happens before 2 hours, and with Lollipop it happens
> some time later.

That sucks - I hope it's not a bug in the API (but I wouldn't be at all
surprised, as the API seems pretty flaky on the devices I've tested).

We should put together a minimal test case for this problem.

> I'll be resetting my devices now, and will be re-running the test to
> see whether I have just gotten my devices on some funny state.. That
> of course can happen when pushing them to the limits with R&D work.

Looking forward to hearing more about your experiments.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 1748 bytes
Desc: not available
URL: <https://pairlist10.pair.net/pipermail/thali-talk/attachments/20150527/cc6af5c0/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <https://pairlist10.pair.net/pipermail/thali-talk/attachments/20150527/cc6af5c0/attachment.pgp>