Will network stack wake up device in deep sleep on incoming packet?
852 views
Skip to first unread message
Jin Chiu
Feb 15, 2011, 1:14:45 PM2/15/11
to android-platform
Say that the device is in deep sleep and the network stack receives an
incoming packet. Will that wake the device up?
incoming packet. Will that wake the device up?
Dianne Hackborn
Feb 15, 2011, 3:55:42 PM2/15/11
to android-...@googlegroups.com
It should.
--
Dianne Hackborn
Android framework engineer
hac...@android.com
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
On Tue, Feb 15, 2011 at 10:14 AM, Jin Chiu <live2d...@gmail.com> wrote:
Say that the device is in deep sleep and the network stack receives an
incoming packet. Will that wake the device up?
--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
--
Dianne Hackborn
Android framework engineer
hac...@android.com
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
erdal
Mar 20, 2011, 1:46:20 AM3/20/11
to android-platform
thank you for your answer! I have a couple more detailed questions:
how long will the device stay awake? how much of the code will execute
after the incoming packet arrives? when should we aquire a partial cpu
lock to make sure we execute everything we wanted to?
I have a tcp socket open in a background service. I am asking these
questions because I am not sure when I should aquire a cpu wake lock.
how long will the device stay awake? how much of the code will execute
after the incoming packet arrives? when should we aquire a partial cpu
lock to make sure we execute everything we wanted to?
I have a tcp socket open in a background service. I am asking these
questions because I am not sure when I should aquire a cpu wake lock.
> On Tue, Feb 15, 2011 at 10:14 AM, Jin Chiu <live2drea...@gmail.com> wrote:
> > Say that the device is in deep sleep and the network stack receives an
> > incoming packet. Will that wake the device up?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-platform" group.
> > To post to this group, send email to android-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-platfo...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
> > Say that the device is in deep sleep and the network stack receives an
> > incoming packet. Will that wake the device up?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-platform" group.
> > To post to this group, send email to android-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-platfo...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
>
> --
> Dianne Hackborn
> Android framework engineer
Paul Gardner-Stephen
Mar 22, 2011, 1:05:57 PM3/22/11
to android-platform
What if the packet is a broadcast ethernet frame?
My quick empirical tests here suggest that they (at least in my case)
fail to wake the device.
Paul.
My quick empirical tests here suggest that they (at least in my case)
fail to wake the device.
Paul.
> On Tue, Feb 15, 2011 at 10:14 AM, Jin Chiu <live2drea...@gmail.com> wrote:
> > Say that the device is in deep sleep and the network stack receives an
> > incoming packet. Will that wake the device up?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-platform" group.
> > To post to this group, send email to android-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-platfo...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
> > Say that the device is in deep sleep and the network stack receives an
> > incoming packet. Will that wake the device up?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-platform" group.
> > To post to this group, send email to android-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-platfo...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
>
> --
> Dianne Hackborn
> Android framework engineer
Dianne Hackborn
Mar 22, 2011, 2:16:34 PM3/22/11
to android-...@googlegroups.com, Paul Gardner-Stephen
On Tue, Mar 22, 2011 at 10:05 AM, Paul Gardner-Stephen <paul.gardn...@gmail.com> wrote:
What if the packet is a broadcast ethernet frame?
My quick empirical tests here suggest that they (at least in my case)
fail to wake the device.
Sorry, I can't help you with that.
--
Dianne Hackborn
Android framework engineer
hac...@android.comDianne Hackborn
Android framework engineer
Dianne Hackborn
Mar 22, 2011, 2:16:15 PM3/22/11
to android-...@googlegroups.com, erdal
You should acquire a wake lock to ensure the device stays awake while you are processing the data.hac...@android.com
John Michelau
Mar 23, 2011, 11:05:39 PM3/23/11
to android-platform
Perhaps this could be better answered over in the kernel forum? My
understanding is that you must chain your wakelocks together from the
hardware interrupt all the way up to the app layer to ensure the
device does not go to sleep. Basically at each point the lower layer
is holding one as it hands off the data, and then it's up to the upper
layer to grab one. In some cases I think timeouts are used instead,
though, which can be risky. If you want to figure out why it's not
waking up, the best way may be to start at the hardware/kernel and
work your way up; including verifying that the bus your device is on
is capable of waking the host from deep sleep in the first place.
understanding is that you must chain your wakelocks together from the
hardware interrupt all the way up to the app layer to ensure the
device does not go to sleep. Basically at each point the lower layer
is holding one as it hands off the data, and then it's up to the upper
layer to grab one. In some cases I think timeouts are used instead,
though, which can be risky. If you want to figure out why it's not
waking up, the best way may be to start at the hardware/kernel and
work your way up; including verifying that the bus your device is on
is capable of waking the host from deep sleep in the first place.
Horace
Mar 25, 2011, 6:06:09 AM3/25/11
to android-platform
Hello,
For broadcast packets, Wifi chip should wake CPU up.
But in my background, the default of filtering broadcast is disabed,
so WiFi chip won't wake CPU.
Horace.
On 3월23일, 오전2시05분, Paul Gardner-Stephen
For broadcast packets, Wifi chip should wake CPU up.
But in my background, the default of filtering broadcast is disabed,
so WiFi chip won't wake CPU.
Horace.
On 3월23일, 오전2시05분, Paul Gardner-Stephen
Horace
Mar 25, 2011, 6:10:34 AM3/25/11
to android-platform
Hello,
I think you don't need to acquire a wake lock to process the data
after incoming packets from the sleep state.
Because we can have enough time to process the packets.
If CPU wakes up from incoming packet, its state becomes idle state.
At least CPU have 15 seconds until going to sleep state again. But it
depends on the Android device.
I think you don't need to acquire a wake lock to process the data
after incoming packets from the sleep state.
Because we can have enough time to process the packets.
If CPU wakes up from incoming packet, its state becomes idle state.
At least CPU have 15 seconds until going to sleep state again. But it
depends on the Android device.
Paul Gardner-Stephen
Mar 26, 2011, 5:45:31 AM3/26/11
to android-platform
Hello,
On Mar 25, 8:06 pm, Horace <nice...@gmail.com> wrote:
> Hello,
>
> For broadcast packets, Wifi chip should wake CPU up.
> But in my background, the default of filtering broadcast is disabed,
> so WiFi chip won't wake CPU.
Okay, this agrees with my experience so far.
I will find out how to enable wake-on-lan for broadcast packets.
Paul.
On Mar 25, 8:06 pm, Horace <nice...@gmail.com> wrote:
> Hello,
>
> For broadcast packets, Wifi chip should wake CPU up.
> But in my background, the default of filtering broadcast is disabed,
> so WiFi chip won't wake CPU.
I will find out how to enable wake-on-lan for broadcast packets.
Paul.
Dianne Hackborn
Mar 26, 2011, 3:11:39 PM3/26/11
to android-...@googlegroups.com, Horace
You should acquire a wake lock while you are doing work during which you don't want the CPU to sleep.
hac...@android.com
2011/3/25 Horace <nic...@gmail.com>
Reply all
Reply to author
Forward
0 new messages