As of OS X 10.9 (and in many cases more importantly in OS X Server for 10.9 and higher), OS X now performs ARP cache validation when trying to pass traffic over a router. If you are double NAT’d/use redundant gateways then the traffic can be interpreted as network redirection and cause some pretty bad packet loss/latency. You can disable this feature by turning off net.link.ether.net.arp_unicast_lim using sysctl: sysctl -w net.link.ether.inet.arp_unicast_lim=0 That will only disable unicast arp validation until the next reboot. If it fixes a latency problem you’re having then you can go ahead and make it permanent by adding the following line into /etc/sysctl.conf: net.link.ether.inet.arp_unicast_lim=0 If you’re still…
-
-
Speed Up ScreenSharing
Screen Sharing over a WAN can be a bit slow. But you can send less data and receive a less latent connection. To do so, you are going to augment the controlObserveQuality key of the com.apple.ScreenSharing.plist property list. If you set the key to a 1, which I see commonly suggested then it will be black and white, which in todays world is another way of saying practically illegible. Instead try the number 2, which sets it to grey scale, which is pretty good (that’s what I use). To do so run: defaults write com.apple.ScreenSharing controlObserveQuality 2 You can also set the controlObserveQuality key to 3, 4 or 5 which…
-
Dealing with Xsan Latency
In Xsan, the PIO HiPriWr shows you how latent the connection to your LUNs is. If the connection to any of your LUNs is too high then it can cause instability and worse, potential volume integrity issues. If you run into issues with this kind of latency then you should fix it. But if you can’t, then you can deal with it programatically using the Buffer Cache Size. Increasing the buffer will allow for more caching, which will in turn allow for more latent LUNs to have less effect on the overall performance, health and viability of the SAN. Additionally, the iNode Cache should be increased for the same purpose…
-
Xsan: Tracking Down Latency Problems
Xsan stores the logs for a volume in /Library/Filesystems/Xsan/data/<Volume Name>/log/cvlog. When you’re trying to find whether there is too much latency you can look for the following in the logs: PIO HiPriWr SUMMARY <Storage Pool> sysavg This is updated every hour in the cvlog.