Apple is battery-life obsessed. I wouldn't take their advice about anything that affects network performance.
BTW, don’t interpret this as an opinion on the DTIM interval. I have an opinion on that, but don’t know enough to share it publicly. It's just an ad hominem attack. Chuck Enfield Manager, Wireless Engineering Telecommunications & Networking Services The Pennsylvania State University 110H, USB2, UP, PA 16802 ph: 814.863.8715 fx: 814.865.3988 -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: Wednesday, August 03, 2016 10:13 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] How big are your wireless segments? But what's the penalty on non-Apple devices? -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jake Snyder Sent: Wednesday, August 03, 2016 8:56 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] How big are your wireless segments? There was some talk about this with IOS a while back. Something about Apple wanting a longer dtim value (3 seems to be working for a lot of folks). Dtim of 1 seemed to give some grief. http://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html?m=1 Thanks Jake Snyder Sent from my iPhone >> On Aug 2, 2016, at 9:04 PM, James Andrewartha >> <jandrewar...@ccgs.wa.edu.au> wrote: >> >> On 02/08/16 04:19, Peter P Morrissey wrote: >> Given my understanding of the way arp works, not sure I understand >> how it is possible for a large subnet to cause a client arp table to >> become exhausted unless that client for some reason is directly >> communicating with all of the other endpoints on the large subnet. >> >> My understanding is that the table is only populated in response to >> arp queries that the client has initiated, even though it can “hear” >> responses from other clients that are sent as a broadcast. It is easy >> enough to verify this on Windows with an arp –a. >> >> I also don’t believe that broadcast traffic can have a material >> impact on clients these days due to increases in CPU power at the >> magnitude of Moore’s Law. > > Sadly there is no Moore's Law for batteries. OS X since 10.10 will > aggressively sleep and miss broadcast ARP packets. I have seen this on > four different AP vendors and have the wireless captures to prove it. > Generally it doesn't cause user-visible problems, and it can be worked > around by enabling proxy ARP on the APs/controller (if the vendor > supports it). > > It will most likely present problems if the clients are trying to > access servers on the same subnet and it's the *server's* ARP cache > that gets exhausted (or simply expires the client). The client will > resolve the server's MAC address OK, send the SYN packet, then the > server will send a broadcast ARP request to resolve the client's MAC > address, which can be missed by the Mac laptop. Depending on the level > of broadcast traffic, it can take a minute or more with retries before > a connection is established. > > For wireless designs where all data goes through the gateway and > there's no client communication to other devices on the same subnet > you probably won't notice a problem as the gateway's ARP cache will always > be fresh. > We saw it because we have a campus-wide flat L2 network shared between > wired and wireless, and I also noticed a lot of ARP traffic from > laptops looking for Apple TV IP addresses. > > We have filed a ticket with Apple, radar://26488949 if anyone has any > contacts to escalate it. The fastest resolution we've had for any > Apple bug is 3 years, so I don't expect this to be fixed any time soon. > > -- > James Andrewartha > Network & Projects Engineer > Christ Church Grammar School > Claremont, Western Australia > Ph. (08) 9442 1757 > Mob. 0424 160 877 > > ********** > Participation and subscription information for this EDUCAUSE Constituent > Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
