Re: [RFC V2] cfg80211: introduce critical protocol indication from user-space

[Dan Williams <dcbw@redhat.com>]

On Thu, 2013-03-28 at 15:51 -0700, Ben Greear wrote:
> 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...

Depends on the DHCP client I suppose, but probably doubtful for dhclient
and dhcpcd at least.  That would be a good patch.

Dan