From: Ben Greear <greearb@candelatech.com>
To: Dan Williams <dcbw@redhat.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Arend van Spriel <arend@broadcom.com>,
Adrian Chadd <adrian@freebsd.org>,
Felix Fietkau <nbd@openwrt.org>,
linux-wireless@vger.kernel.org
Subject: Re: [RFC V2] cfg80211: introduce critical protocol indication from user-space
Date: Thu, 28 Mar 2013 15:51:26 -0700 [thread overview]
Message-ID: <5154C96E.9060806@candelatech.com> (raw)
In-Reply-To: <1364510577.3226.7.camel@dcbw.foobar.com>
On 03/28/2013 03:42 PM, Dan Williams wrote:
> On Thu, 2013-03-28 at 22:28 +0100, Johannes Berg wrote:
>> On Thu, 2013-03-28 at 22:16 +0100, Arend van Spriel wrote:
>>>> That seems pretty long? Why have such a long *minimum* duration? At 2.5
>>>> seconds, it's way long, and then disabling most of the
>>>> protections/powersave/whatever no longer makes sense for this period of
>>>> time since really mostly what this does will be reducing the wifi
>>>> latency.
>>
>>> Ok, so what minimum do you (or someone else can chime in here) think a
>>> DHCP exchange takes as that was considered a likely protocol that can
>>> benefit from this API.
>>
>> Well, you can do DHCP a second or so, I'd think? And EAPOL much quicker,
>> of course. I don't really see any reasonable minimum time? We might want
>> to enforce a max though, maybe.
>
> Not quite. A lot is dependent on the server itself, and I've had users
> on university and corporate networks report it sometimes takes 30 to 60
> seconds for the whole DHCP transaction to complete (DISCOVER, REQUEST,
> OFFER, ACK). Sometimes there's a NAK in there if the server doesn't
> like your lease, which means you need another round-trip. So in many
> cases, it's a couple round-trips and each of these packets may or may
> not get lost in noisy environments.
Anyone know if DHCP requests and responses go to the high-priority
queue in the NIC by default? Seems like that might be a big help if not...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2013-03-28 22:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 12:11 [RFC V2] cfg80211: introduce critical protocol indication from user-space Arend van Spriel
2013-03-28 16:17 ` Johannes Berg
2013-03-28 16:30 ` Ben Greear
2013-03-28 21:16 ` Arend van Spriel
2013-03-28 21:28 ` Johannes Berg
2013-03-28 22:42 ` Dan Williams
2013-03-28 22:44 ` Johannes Berg
2013-03-28 23:01 ` Dan Williams
2013-03-28 23:30 ` Ben Greear
2013-03-29 13:42 ` Arend van Spriel
2013-04-01 14:52 ` Dan Williams
2013-03-29 11:38 ` Arend van Spriel
2013-03-28 22:51 ` Ben Greear [this message]
2013-03-28 22:58 ` Dan Williams
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=5154C96E.9060806@candelatech.com \
--to=greearb@candelatech.com \
--cc=adrian@freebsd.org \
--cc=arend@broadcom.com \
--cc=dcbw@redhat.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@openwrt.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.