All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 26 Apr 2010 13:54:05 +0200	[thread overview]
Message-ID: <1272282845.3619.25.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1271928576.6205.8919.camel@wimaxnb.nmp.nokia.com>

On Thu, 2010-04-22 at 12:29 +0300, Juuso Oikarinen wrote:

> > Still I think you should say why you need to actually tune the PS
> > timeout value directly? I can't see how your high-level design says "set
> > dynamic PS timeout to 100ms" rather than "make sure that while the user
> > is operating the device, there's no delay of more than 50ms" or
> > something like that?
> 
> You're partly right asking this. The high-level design obviously does
> not know about dynamic PS timeouts. It seems you're mainly looking at
> this from the angle of the network latency itself - i.e. network
> performance. My primary angle currently is power consumption.
> 
> IMHO both angles are correct. The if the user sets a tight
> network-latency requirement, the value can be used to tune things so
> that the requirement can be met. If they set a loose requirement, it can
> be used as a signal to do more aggressive power saving, which often
> means reduced latency.

Well I would argue that if the user requires a certain network latency,
that should take precedence. The user is unlikely to be thinking in
terms of "I want my battery to last that long"; rather they want to last
it as long as possible given their quality of service demand
constraints?

> While the mechanism I'm proposing here is rather crude, it does save
> power when the user-space loosens their latency requirement. The values
> chosen for the dynamic ps-timeout bear no direct relation to user space
> requirements. They are simply values that we have found to give decent
> results in typical AP configurations.
> 
> The ps_timeout could be calculated based on the latency too, I guess.
> I'm just not aware of any simple formula to do this.

But you did just base it on that?

It just seems to me that you're putting the power consumption
requirements after the quality of service demands, which would seem
wrong?

johannes


  reply	other threads:[~2010-04-26 11:54 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
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 [this message]
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=1272282845.3619.25.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.