From: Johannes Berg <johannes@sipsolutions.net>
To: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
Date: Thu, 22 Apr 2010 10:45:39 +0200 [thread overview]
Message-ID: <1271925939.3605.7.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1271740120.6205.5733.camel@wimaxnb.nmp.nokia.com>
On Tue, 2010-04-20 at 08:08 +0300, Juuso Oikarinen wrote:
> On Mon, 2010-04-19 at 16:42 +0200, ext Johannes Berg wrote:
> > On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> > > Determine the dynamic PS timeout based on the configured ps-qos network
> > > latency. For backwards wext compatibility, allow the dynamic PS timeout
> > > configured by the cfg80211 to overrule the automatically determined value.
> >
> > This seems OK, but I fear that you'll write applications setting the
> > pm_qos network latency just to affect this parameter?
> >
>
> Well you have to see where I'm coming from - I must come up with a way
> to tune the dynamic ps timeout value from user-space in a way that is
> agreeable with others, and that is somewhat future-proof.
Well I personally think that's your first mistake ;)
Why does userspace care about the dynamic PS timeout value to start
with? All it should care about is the latency with which it can react to
network packets, no?
> That said, obviously the network latency should be tuned as, well, the
> expected network latency. In this phase though, there are no other
> parameters affected by the network latency, so the result is quite
> obvious - your fear will realise itself ;)
But there are, like the max sleep period in # of beacons.
johannes
next prev parent reply other threads:[~2010-04-22 8:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-16 9:14 [RFC PATCHv3 0/2] mac80211: cfg80211: dynamic ps timeout based on pm-qos Juuso Oikarinen
2010-04-16 9:14 ` [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency Juuso Oikarinen
2010-04-19 14:42 ` Johannes Berg
2010-04-20 5:08 ` Juuso Oikarinen
2010-04-22 8:45 ` Johannes Berg [this message]
2010-04-22 8:55 ` Juuso Oikarinen
2010-04-22 9:05 ` Johannes Berg
2010-04-22 9:07 ` Johannes Berg
2010-04-22 9:29 ` Juuso Oikarinen
2010-04-26 11:54 ` Johannes Berg
2010-04-26 12:04 ` Juuso Oikarinen
2010-04-26 12:11 ` Johannes Berg
2010-04-26 12:23 ` Juuso Oikarinen
2010-04-26 12:30 ` Johannes Berg
2010-04-27 4:27 ` Juuso Oikarinen
2010-04-16 9:14 ` [RFC PATCHv3 2/2] cfg80211: Remove default dynamic PS timeout value Juuso Oikarinen
2010-04-19 14:43 ` Johannes Berg
2010-04-20 4:58 ` Juuso Oikarinen
2010-04-22 8:46 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1271925939.3605.7.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=juuso.oikarinen@nokia.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).