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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
