September 2005 - Macnetworkprog

Re: What exactly is net.inet.tcp.sockthreshold?
by Chris McFarling 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: Macnetworkprog(a)lists.apple.com Is there a way to force AFP to use a specific window size? Long story short...when two Gb OS X clients send simultaneously to our XServe (via AFP), the transfer rate for each drops to about 6MB/s. (when either machine is sending by itself, the transfer rate is ~ 30-40MB/s). I've duplicated this behavior with iperf as well. Using iperf, I've found that by decreasing the window size, the performance is dramatically improved. I would love to be able to make AFP use a smaller window size as well, at least to test and see if it makes a difference. ----- Original Message ----- From: "Vincent Lubet" <vlubet(a)apple.com> To: "Chris McFarling" <cmcfarling_lists(a)pacificpremedia.com> Cc: <Macnetworkprog(a)lists.apple.com> Sent: Friday, September 30, 2005 4:35 PM Subject: Re: What exactly is net.inet.tcp.sockthreshold? > Chris, > > The sysctl variables net.inet.tcp.recvspace and > net.inet.tcp.sendspace are the default values for the TCP socket > buffers that are used to determine the window size. A program is free > to override those default values by using the socket options > SO_RCVBUF and SO_SNDBUF -- that's what the AFP does. > > Vincent > > On Sep 30, 2005, at 1:45 PM, Chris McFarling wrote: > > > **This is an addition to my previous post** > > > > I tried the same test as mentioned previously but mounted the > > volume on the > > client via SMB. This time the TCP window size that I had manually > > specified > > (18824) was used. So it appears that AFP has it's own way of > > dealing with > > window sizes. How can that be affected? > > > > > > SMB PACKET TRACE > > > > 13:36:20.014410 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 13579:15027(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014456 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack > > 15027 win > > 18824 <nop,nop,timestamp 3550899915 3574083461> > > 13:36:20.014905 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 15027:16475(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014907 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 16475:17923(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014910 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 17923:19371(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014912 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 19371:20819(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014915 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 20819:22267(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014917 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 22267:23715(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014920 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 23715:25163(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014923 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 25163:26611(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014925 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 26611:28059(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014927 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 28059:29507(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014930 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 29507:30955(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.014951 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack > > 30955 win > > 18824 <nop,nop,timestamp 3550899915 3574083461> > > 13:36:20.015119 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 30955:32403(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015121 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 32403:33851(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015124 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 33851:35299(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015177 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack > > 35299 win > > 18824 <nop,nop,timestamp 3550899915 3574083461> > > 13:36:20.015345 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 35299:36747(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015347 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 36747:38195(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015349 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 38195:39643(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015351 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 39643:41091(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015353 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 41091:42539(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015355 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 42539:43987(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015357 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 43987:45435(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015359 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 45435:46883(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015362 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 46883:48331(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015364 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 48331:49779(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015366 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 49779:51227(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015368 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 51227:52675(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > 13:36:20.015389 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack > > 52675 win > > 18824 <nop,nop,timestamp 3550899915 3574083461> > > 13:36:20.015557 IP 192.168.10.121.50119 > 192.168.10.13.139: . > > 52675:54123(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 > > 3550899915> NBT Packet > > > > _______________________________________________ > > Do not post admin requests to the list. They will be ignored. > > Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/macnetworkprog/vlubet% > > 40apple.com > > > > This email sent to vlubet(a)apple.com > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: What exactly is net.inet.tcp.sockthreshold?
by Vincent Lubet 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: Macnetworkprog(a)lists.apple.com Chris, Vincent On Sep 30, 2005, at 1:45 PM, Chris McFarling wrote: **This is an addition to my previous post** SMB PACKET TRACE _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… The sysctl variables net.inet.tcp.recvspace and net.inet.tcp.sendspace are the default values for the TCP socket buffers that are used to determine the window size. A program is free to override those default values by using the socket options SO_RCVBUF and SO_SNDBUF -- that's what the AFP does. I tried the same test as mentioned previously but mounted the volume on the client via SMB. This time the TCP window size that I had manually specified (18824) was used. So it appears that AFP has it's own way of dealing with window sizes. How can that be affected? 13:36:20.014410 IP 192.168.10.121.50119 > 192.168.10.13.139: . 13579:15027(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014456 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack 15027 win 18824 <nop,nop,timestamp 3550899915 3574083461> 13:36:20.014905 IP 192.168.10.121.50119 > 192.168.10.13.139: . 15027:16475(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014907 IP 192.168.10.121.50119 > 192.168.10.13.139: . 16475:17923(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014910 IP 192.168.10.121.50119 > 192.168.10.13.139: . 17923:19371(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014912 IP 192.168.10.121.50119 > 192.168.10.13.139: . 19371:20819(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014915 IP 192.168.10.121.50119 > 192.168.10.13.139: . 20819:22267(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014917 IP 192.168.10.121.50119 > 192.168.10.13.139: . 22267:23715(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014920 IP 192.168.10.121.50119 > 192.168.10.13.139: . 23715:25163(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014923 IP 192.168.10.121.50119 > 192.168.10.13.139: . 25163:26611(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014925 IP 192.168.10.121.50119 > 192.168.10.13.139: . 26611:28059(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014927 IP 192.168.10.121.50119 > 192.168.10.13.139: . 28059:29507(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014930 IP 192.168.10.121.50119 > 192.168.10.13.139: . 29507:30955(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014951 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack 30955 win 18824 <nop,nop,timestamp 3550899915 3574083461> 13:36:20.015119 IP 192.168.10.121.50119 > 192.168.10.13.139: . 30955:32403(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015121 IP 192.168.10.121.50119 > 192.168.10.13.139: . 32403:33851(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015124 IP 192.168.10.121.50119 > 192.168.10.13.139: . 33851:35299(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015177 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack 35299 win 18824 <nop,nop,timestamp 3550899915 3574083461> 13:36:20.015345 IP 192.168.10.121.50119 > 192.168.10.13.139: . 35299:36747(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015347 IP 192.168.10.121.50119 > 192.168.10.13.139: . 36747:38195(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015349 IP 192.168.10.121.50119 > 192.168.10.13.139: . 38195:39643(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015351 IP 192.168.10.121.50119 > 192.168.10.13.139: . 39643:41091(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015353 IP 192.168.10.121.50119 > 192.168.10.13.139: . 41091:42539(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015355 IP 192.168.10.121.50119 > 192.168.10.13.139: . 42539:43987(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015357 IP 192.168.10.121.50119 > 192.168.10.13.139: . 43987:45435(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015359 IP 192.168.10.121.50119 > 192.168.10.13.139: . 45435:46883(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015362 IP 192.168.10.121.50119 > 192.168.10.13.139: . 46883:48331(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015364 IP 192.168.10.121.50119 > 192.168.10.13.139: . 48331:49779(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015366 IP 192.168.10.121.50119 > 192.168.10.13.139: . 49779:51227(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015368 IP 192.168.10.121.50119 > 192.168.10.13.139: . 51227:52675(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015389 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack 52675 win 18824 <nop,nop,timestamp 3550899915 3574083461> 13:36:20.015557 IP 192.168.10.121.50119 > 192.168.10.13.139: . 52675:54123(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/vlubet% 40apple.com This email sent to vlubet(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: What exactly is net.inet.tcp.sockthreshold?
by Chris McFarling 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: Macnetworkprog(a)lists.apple.com **This is an addition to my previous post** I tried the same test as mentioned previously but mounted the volume on the client via SMB. This time the TCP window size that I had manually specified (18824) was used. So it appears that AFP has it's own way of dealing with window sizes. How can that be affected? SMB PACKET TRACE 13:36:20.014410 IP 192.168.10.121.50119 > 192.168.10.13.139: . 13579:15027(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014456 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack 15027 win 18824 <nop,nop,timestamp 3550899915 3574083461> 13:36:20.014905 IP 192.168.10.121.50119 > 192.168.10.13.139: . 15027:16475(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014907 IP 192.168.10.121.50119 > 192.168.10.13.139: . 16475:17923(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014910 IP 192.168.10.121.50119 > 192.168.10.13.139: . 17923:19371(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014912 IP 192.168.10.121.50119 > 192.168.10.13.139: . 19371:20819(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014915 IP 192.168.10.121.50119 > 192.168.10.13.139: . 20819:22267(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014917 IP 192.168.10.121.50119 > 192.168.10.13.139: . 22267:23715(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014920 IP 192.168.10.121.50119 > 192.168.10.13.139: . 23715:25163(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014923 IP 192.168.10.121.50119 > 192.168.10.13.139: . 25163:26611(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014925 IP 192.168.10.121.50119 > 192.168.10.13.139: . 26611:28059(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014927 IP 192.168.10.121.50119 > 192.168.10.13.139: . 28059:29507(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014930 IP 192.168.10.121.50119 > 192.168.10.13.139: . 29507:30955(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.014951 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack 30955 win 18824 <nop,nop,timestamp 3550899915 3574083461> 13:36:20.015119 IP 192.168.10.121.50119 > 192.168.10.13.139: . 30955:32403(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015121 IP 192.168.10.121.50119 > 192.168.10.13.139: . 32403:33851(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015124 IP 192.168.10.121.50119 > 192.168.10.13.139: . 33851:35299(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015177 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack 35299 win 18824 <nop,nop,timestamp 3550899915 3574083461> 13:36:20.015345 IP 192.168.10.121.50119 > 192.168.10.13.139: . 35299:36747(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015347 IP 192.168.10.121.50119 > 192.168.10.13.139: . 36747:38195(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015349 IP 192.168.10.121.50119 > 192.168.10.13.139: . 38195:39643(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015351 IP 192.168.10.121.50119 > 192.168.10.13.139: . 39643:41091(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015353 IP 192.168.10.121.50119 > 192.168.10.13.139: . 41091:42539(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015355 IP 192.168.10.121.50119 > 192.168.10.13.139: . 42539:43987(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015357 IP 192.168.10.121.50119 > 192.168.10.13.139: . 43987:45435(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015359 IP 192.168.10.121.50119 > 192.168.10.13.139: . 45435:46883(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015362 IP 192.168.10.121.50119 > 192.168.10.13.139: . 46883:48331(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015364 IP 192.168.10.121.50119 > 192.168.10.13.139: . 48331:49779(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015366 IP 192.168.10.121.50119 > 192.168.10.13.139: . 49779:51227(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015368 IP 192.168.10.121.50119 > 192.168.10.13.139: . 51227:52675(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet 13:36:20.015389 IP 192.168.10.13.139 > 192.168.10.121.50119: . ack 52675 win 18824 <nop,nop,timestamp 3550899915 3574083461> 13:36:20.015557 IP 192.168.10.121.50119 > 192.168.10.13.139: . 52675:54123(1448) ack 537 win 65535 <nop,nop,timestamp 3574083461 3550899915> NBT Packet _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: What exactly is net.inet.tcp.sockthreshold?
by Chris McFarling 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: Macnetworkprog(a)lists.apple.com ----- Original Message ----- From: "Vincent Lubet" <vlubet(a)apple.com> To: "Chris McFarling" <cmcfarling_lists(a)pacificpremedia.com> Cc: <Macnetworkprog(a)lists.apple.com> Sent: Friday, September 30, 2005 11:58 AM Subject: Re: What exactly is net.inet.tcp.sockthreshold? > Chris, > > On Sep 30, 2005, at 7:51 AM, Chris McFarling wrote: > > > /etc/sysctl-macosxserver.conf states the following: > > > > # Some sysctl variables administrators may consider setting in > > /etc/sysctl.conf: > > # > > # This sets a threshold that triggers increasing the send/recv > > windows for > > TCP > > # connection from 32K to 64K to improve some file downloads. > > # If your server has a lot of memory and serves only local traffic > > (like AFP > > cli > > ents > > # on local LAN) you may want to increase this value beyond its > > default of > > 256 pc > > bs. > > # > > # net.inet.tcp.sockthreshold=512 > > > > > > When it says"256 pcbs", what does that mean? > > That's the number of TCP control blocks, which is approximately the > number of active TCP connections. > > > Also, how does the triggering > > mechanism work...when does the OS use 32K windows and when does it > > use 64K > > windows? > > The OS uses 64 K windows as long as the number of TCP connections is > less than net.inet.tcp.sockthreshold. > > When the number of TCP connections is greater > net.inet.tcp.sockthreshold the stack will use the values of > net.inet.tcp.recvspace and net.inet.tcp.sendspace > > > The reason I ask is because I actually want to set the window size > > to 18K. > > I'm doing some testing and want to see if a smaller window size will > > increase performance on my network. In doing so I'm trying to > > understand OS > > X's behavior though. > > To disable this mechanism and force the stack to always use a 18K you > simply need to set net.inet.tcp.sockthreshold to zero > > Vincent Thanks Vincent. I had read that on a thread somewhere else but wasn't sure if it was accurate. Unfortunately, that procedure is not working in my case. It seems the server is determined to use a window size of 32768 no matter what. server02 is the machine that I'm editing the TCP parameters on. I created sysctl.conf and added the necessary parameters: server02:root# more /etc/sysctl.conf # Set TCP parameters net.inet.tcp.sendspace=18824 net.inet.tcp.recvspace=18824 net.inet.tcp.sockthreshold=0 After a restart, the system appears to be using the custom params: server02:root# sysctl -a --snip-- net.inet.tcp.sendspace: 18824 net.inet.tcp.recvspace: 18824 net.inet.tcp.sockthreshold: 0 --snip-- To test, I mounted a share from server02 on to a client machine (via AFP) and ran the following command while doing a tcpdump on the server. dd bs=1m count=10 if=/dev/zero of=/Volumes/VolumeOnServer02/ddtest_1 It appears that the server is still using a value of 32768 for the TCP receive window. The server IP is 192.168.10.13 and the client is 192.168.10.121. Note that all of the packets from .13 to .121 advertise a window size of 32768. This is just a small snippet of packets but the whole packet trace is the same. Does the AFP server possibly override the net.inet.tcp.recvspace setting somehow? 13:02:41.680547 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3978075:3979523(1448) ack 1233 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.680549 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3979523:3980971(1448) ack 1233 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.680583 IP 192.168.10.13.548 > 192.168.10.121.50109: P 1233:1257(24) ack 3980971 win 9050 <nop,nop,timestamp 3550895879 3574079424> 13:02:41.680643 IP 192.168.10.13.548 > 192.168.10.121.50109: . ack 3980971 win 32768 <nop,nop,timestamp 3550895879 3574079424> 13:02:41.680813 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3980971:3982419(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.680816 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3982419:3983867(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.680818 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3983867:3985315(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.680820 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3985315:3986763(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.680822 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3986763:3988211(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.680824 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3988211:3989659(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.680826 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3989659:3991107(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.680900 IP 192.168.10.13.548 > 192.168.10.121.50109: . ack 3991107 win 32768 <nop,nop,timestamp 3550895879 3574079424> 13:02:41.681036 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3991107:3992555(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681038 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3992555:3994003(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681040 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3994003:3995451(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681042 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3995451:3996899(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681044 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3996899:3998347(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681046 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3998347:3999795(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681048 IP 192.168.10.121.50109 > 192.168.10.13.548: . 3999795:4001243(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681050 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4001243:4002691(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681052 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4002691:4004139(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681054 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4004139:4005587(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681056 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4005587:4007035(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681058 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4007035:4008483(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681060 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4008483:4009931(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681062 IP 192.168.10.121.50109 > 192.168.10.13.548: P 4009931:4011379(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681064 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4011379:4012827(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681088 IP 192.168.10.13.548 > 192.168.10.121.50109: . ack 4012827 win 32768 <nop,nop,timestamp 3550895879 3574079424> 13:02:41.681252 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4012827:4014275(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681254 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4014275:4015723(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681256 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4015723:4017171(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681258 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4017171:4018619(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681260 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4018619:4020067(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681262 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4020067:4021515(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681264 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4021515:4022963(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681266 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4022963:4024411(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681268 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4024411:4025859(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681270 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4025859:4027307(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681272 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4027307:4028755(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681274 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4028755:4030203(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> 13:02:41.681295 IP 192.168.10.13.548 > 192.168.10.121.50109: . ack 4030203 win 32768 <nop,nop,timestamp 3550895879 3574079424> 13:02:41.681460 IP 192.168.10.121.50109 > 192.168.10.13.548: . 4030203:4031651(1448) ack 1257 win 65535 <nop,nop,timestamp 3574079424 3550895879> _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: What exactly is net.inet.tcp.sockthreshold?
by Vincent Lubet 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: Macnetworkprog(a)lists.apple.com Chris, On Sep 30, 2005, at 7:51 AM, Chris McFarling wrote: /etc/sysctl-macosxserver.conf states the following: Vincent _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… # Some sysctl variables administrators may consider setting in /etc/sysctl.conf: # # This sets a threshold that triggers increasing the send/recv windows for TCP # connection from 32K to 64K to improve some file downloads. # If your server has a lot of memory and serves only local traffic (like AFP cli ents # on local LAN) you may want to increase this value beyond its default of 256 pc bs. # # net.inet.tcp.sockthreshold=512 When it says"256 pcbs", what does that mean? That's the number of TCP control blocks, which is approximately the number of active TCP connections. Also, how does the triggering mechanism work...when does the OS use 32K windows and when does it use 64K windows? The OS uses 64 K windows as long as the number of TCP connections is less than net.inet.tcp.sockthreshold. When the number of TCP connections is greater net.inet.tcp.sockthreshold the stack will use the values of net.inet.tcp.recvspace and net.inet.tcp.sendspace The reason I ask is because I actually want to set the window size to 18K. I'm doing some testing and want to see if a smaller window size will increase performance on my network. In doing so I'm trying to understand OS X's behavior though. To disable this mechanism and force the stack to always use a 18K you simply need to set net.inet.tcp.sockthreshold to zero This email sent to site_archiver(a)lists.apple.com

1 0

Re: mDNS Packet storm help
by Marc Krochmal 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: Macnetworkprog(a)lists.apple.com On Sep 30, 2005, at 6:50 AM, Eric Dahlman wrote: Howdy, -Marc On Sep 29, 2005, at 8:43 PM, Marc Krochmal wrote: Hi Eric, <http://developer.apple.com/qa/qa2001/qa1176.html> Thanks. -Marc On Sep 29, 2005, at 6:19 PM, Eric Dahlman wrote: Howdy, Thanks, -Eric P.S. Both machines are running Tiger with the latest updates. This email sent to marc(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… I have sent the trace in a separate message. Just some extra information here. At present mDNSresponder is taking up about 50% of my CPU and is about 864 K in size. When I went home last night my powerbook did not show any of this traffic and when I came in to the office it also did not. I noticed it after about half an hour and switching users, sorry I cannot say exactly when it started or if fast user switching was a contributing factor. I also started a packet trace with Ethereal to watch http traffic during this time but alas it got too big to be manageable. I will describe those problems in my next installment as I think they have a different cause but still may be related ;-) The reason that mDNSResponder is using 50% CPU is not because it's sending these packets, it's because mDNSResponder is receiving and processing all these packets. Given you're having this problem and the "Slashdot" problem, I think this is happening somewhere in the kernel or in your Ethernet hardware. In the packet trace, every mDNS packet has the same IP identifier, meaning that this is the exact same packet being sent by the kernel over and over. Hopefully someone else on the list can provide more information about how to debug this. Could you capture a full packet trace in tcpdump format and then send it to me. In trying to track down another problem I have noticed that there is a huge amount of mdns generated by my machine. This is on the order of 1400 packets a second, that is kind of much I assume. I have included the details on one of these packets below. My machine is on a private net with IP 192.168.172.13 and the other machine (steinbit) is on the other side of a nat with a internet visible IP 204.72.xx.xx (to protect the innocent). If it matters my machine is a laptop that regularly moves between two different private networks natted to the internet (work and home). I would appreciate any idea about what is going on an what I can do to stop it. No. Time Source Destination Protocol Info 4 0.001356 192.168.172.1 224.0.0.251 MDNS Standard query response PTR steinbit._afpovertcp._tcp.local Frame 4 (191 bytes on wire, 191 bytes captured) Ethernet II, Src: Cisco-Li_20:09:1e (00:0f:66:20:09:1e), Dst: 01:00:5e:00:00:fb (01:00:5e:00:00:fb) Internet Protocol, Src: 192.168.172.1 (192.168.172.1), Dst: 224.0.0.251 (224.0.0.251) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x18 (DSCP 0x06: Unknown DSCP; ECN: 0x00) Total Length: 173 Identification: 0xa2a7 (41639) Flags: 0x00 Fragment offset: 0 Time to live: 254 Protocol: UDP (0x11) Header checksum: 0xcbda [correct] Source: 192.168.172.1 (192.168.172.1) Destination: 224.0.0.251 (224.0.0.251) User Datagram Protocol, Src Port: mdns (5353), Dst Port: mdns (5353) Source port: mdns (5353) Destination port: mdns (5353) Length: 153 Checksum: 0x0000 (none) Domain Name System (response) Transaction ID: 0x0000 Flags: 0x8400 (Standard query response, No error) Questions: 0 Answer RRs: 1 Authority RRs: 0 Additional RRs: 4 Answers _afpovertcp._tcp.local: type PTR, class IN, steinbit._afpovertcp._tcp.local Name: _afpovertcp._tcp.local Type: PTR (Domain name pointer) Class: IN (0x0001) Time to live: 1 hour, 15 minutes Data length: 11 Domain name: steinbit._afpovertcp._tcp.local Additional records steinbit-2.local: type AAAA, class FLUSH, addr fe80::20d: 93ff:fe65:a43e Name: steinbit-2.local Type: AAAA (IPv6 address) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 16 Addr: fe80::20d:93ff:fe65:a43e steinbit-2.local: type A, class FLUSH, addr 204.72.172.188 Name: steinbit-2.local Type: A (Host address) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 4 Addr: 204.72.172.188 steinbit._afpovertcp._tcp.local: type SRV, class FLUSH, priority 0, weight 0, port 548, target steinbit-2.local Name: steinbit._afpovertcp._tcp.local Type: SRV (Service location) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 8 Priority: 0 Weight: 0 Port: 548 Target: steinbit-2.local steinbit._afpovertcp._tcp.local: type TXT, class FLUSH Name: steinbit._afpovertcp._tcp.local Type: TXT (Text strings) Class: FLUSH (0x8001) Time to live: 1 hour, 15 minutes Data length: 1 Text: _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/marc% 40apple.com This email sent to site_archiver(a)lists.apple.com

1 0

What exactly is net.inet.tcp.sockthreshold?
by Chris McFarling 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: Macnetworkprog(a)lists.apple.com /etc/sysctl-macosxserver.conf states the following: # Some sysctl variables administrators may consider setting in /etc/sysctl.conf: # # This sets a threshold that triggers increasing the send/recv windows for TCP # connection from 32K to 64K to improve some file downloads. # If your server has a lot of memory and serves only local traffic (like AFP cli ents # on local LAN) you may want to increase this value beyond its default of 256 pc bs. # # net.inet.tcp.sockthreshold=512 When it says"256 pcbs", what does that mean? Also, how does the triggering mechanism work...when does the OS use 32K windows and when does it use 64K windows? The reason I ask is because I actually want to set the window size to 18K. I'm doing some testing and want to see if a smaller window size will increase performance on my network. In doing so I'm trying to understand OS X's behavior though. Thanks for any help. _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Safari-RSS is spidering Slashdot is lookupd to blame?
by Eric Dahlman 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: Macnetworkprog(a)lists.apple.com Howdy all, Thanks a bunch! -Eric /Library/Logs/lookupd.crash.log ********* Host Name: Omppu Date/Time: 2005-09-26 16:27:41.423 -0500 OS Version: 10.4.2 (Build 8C46) Report Version: 3 Command: lookupd Path: /usr/sbin/lookupd Parent: launchd [1] Version: ??? (???) PID: 10013 Thread: 5 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000001 Thread 0: 0 libSystem.B.dylib 0x9000a738 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000a67c mach_msg + 60 2 lookupd 0x00006b28 -[Controller serverLoop] + 116 3 lookupd 0x00021f2c main + 2132 4 lookupd 0x000027c4 _start + 348 5 lookupd 0x00002664 start + 60 Thread 2: 0 libSystem.B.dylib 0x9000a738 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000a67c mach_msg + 60 2 lookupd 0x0001b920 -[Thread usleep:] + 72 3 lookupd 0x00016574 -[LUServer gai_async] + 224 4 lookupd 0x0001ae34 launchpad + 132 5 libSystem.B.dylib 0x9002c3b4 _pthread_body + 96 Thread 3: 0 libSystem.B.dylib 0x9000a738 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000a67c mach_msg + 60 2 lookupd 0x00006b28 -[Controller serverLoop] + 116 3 lookupd 0x0001ae34 launchpad + 132 4 libSystem.B.dylib 0x9002c3b4 _pthread_body + 96 Thread 4: 0 libSystem.B.dylib 0x9000a738 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000a67c mach_msg + 60 2 lookupd 0x0001b920 -[Thread usleep:] + 72 3 lookupd 0x00016574 -[LUServer gai_async] + 224 4 lookupd 0x0001ae34 launchpad + 132 5 libSystem.B.dylib 0x9002c3b4 _pthread_body + 96 Thread 6: 0 libSystem.B.dylib 0x9000a738 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000a67c mach_msg + 60 2 lookupd 0x0001b920 -[Thread usleep:] + 72 3 lookupd 0x00016574 -[LUServer gai_async] + 224 4 lookupd 0x0001ae34 launchpad + 132 5 libSystem.B.dylib 0x9002c3b4 _pthread_body + 96 Thread 7: 0 libSystem.B.dylib 0x9000a738 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000a67c mach_msg + 60 2 lookupd 0x00006b28 -[Controller serverLoop] + 116 3 lookupd 0x0001ae34 launchpad + 132 4 libSystem.B.dylib 0x9002c3b4 _pthread_body + 96 _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… I think that this is related to lookupd and is therefor on topic here but I may be wrong so any diagnostic help would be helpful. The short of it is that a huge amount of my http traffic is getting routed to slashdot's IP when it should not be. I will try to be succinct but I don't really know what is relevant so I can only cut so much. This all started about two weeks ago on Sunday when our office was banned from Slashdot (there are lots of geeks here and it did cause some distress.) After contacting them they said that we were banned for using a bot or spidering the site, there were 3000 hits in an hour's time. So we went about trying to figure out what windows box had a virus or linux box had been rooted, well we attached a packet sniffer right before the NAT box to find the culprit. Lo an behold it was my mac. The wacky thing is that it looks like in Safari when loading the RSS view (I have like 15 rss feeds I read in the combined view) the http traffic was all going to slashdot and not where it belonged. For instance an image obviously belonging to the boingboing.net feed was requested from slashdot's http server. Later in analyzing this I used dig to look up the IPs and they were not at all similar (so it is not a case of the same machine hosting different sites). Now I have always thought the web was kind of flakey and so I don't even blink when an image link is broken or the like. So I cannot say if this is a common or recurring thing, although I don't think my surfing experience is what it should be on this T1. Now I have read about problems with lookupd having its cache messed up, could that have the effect of returing the wrong IP for an address request. Looking in my crash logs lookupd has gone south three times in the last couple of weeks is that telling or not? I have attached the most recent crash log in case it might help. Any suggestions or do I just have to firewall off my machine from the rest of the company so Slashdot will turn us back on and I won't get burned at the stake? Productivity is up but moral is hurting a bit... Thread 1: 0 libSystem.B.dylib 0x9000a738 mach_msg_trap + 8 1 libSystem.B.dylib 0x9000a67c mach_msg + 60 2 lookupd 0x0001b920 -[Thread usleep:] + 72 3 lookupd 0x00016bc8 -[LUServer gai_parallel:] + 680 4 lookupd 0x00018464 -[MachRPC process:inData:inLength:outData:outLength:] + 3480 5 lookupd 0x0001feec __lookup_all + 208 6 lookupd 0x00022b74 _X_lookup_all_secure + 152 7 lookupd 0x00022a08 lookup_server + 168 8 lookupd 0x0001758c -[MachRPC process] + 92 9 lookupd 0x00006c58 -[Controller serverLoop] + 420 10 lookupd 0x0001ae34 launchpad + 132 11 libSystem.B.dylib 0x9002c3b4 _pthread_body + 96 Thread 5 Crashed: 0 libSystem.B.dylib 0x90003324 strcmp + 132 1 com.apple.NetInfo 0x94949438 cache_insert_ttl_time + 116 2 lookupd 0x00003c44 -[CacheAgent addObject:category:key:] + 568 3 lookupd 0x000040f4 -[CacheAgent addObject:key:category:] + 512 4 lookupd 0x00010ce8 -[LUServer stamp:key:agent:category:] + 480 5 lookupd 0x00013020 -[LUServer findItemWithKey:value:category:] + 1424 6 lookupd 0x00013304 -[LUServer itemWithKey:value:category:] + 248 7 lookupd 0x00014e6c -[LUServer gai_node:port:info:] + 1232 8 lookupd 0x00016528 -[LUServer gai_async] + 148 9 lookupd 0x0001ae34 launchpad + 132 10 libSystem.B.dylib 0x9002c3b4 _pthread_body + 96 Thread 5 crashed with PPC Thread State 64: srr0: 0x0000000090003324 srr1: 0x000000000200f030 vrsave: 0x0000000000000000 cr: 0x42002224 xer: 0x0000000020000004 lr: 0x0000000094949438 ctr: 0x00000000000003ff r0: 0x00000000000003ff r1: 0x00000000f060b950 r2: 0x000000000004d000 r3: 0x0000000000328b30 r4: 0x00000000fffffffd r5: 0x00000000fefefeff r6: 0x0000000080808080 r7: 0x00000000686e3a6a r8: 0x0000000000650000 r9: 0x0000000000000fff r10: 0x0000000000002e00 r11: 0x00000000a49421d8 r12: 0x00000000900032a0 r13: 0x0000000000032a90 r14: 0x0000000000000000 r15: 0x0000000000000000 r16: 0x0000000000000005 r17: 0x0000000000032a90 r18: 0x0000000000000002 r19: 0x0000000000000002 r20: 0x000000000002513c r21: 0x0000000000000000 r22: 0x00000000433867cd r23: 0x000000000000a8c0 r24: 0x0000000000000000 r25: 0x0000000000331de0 r26: 0x0000000000328b30 r27: 0x0000000000000d35 r28: 0x00000000000034d4 r29: 0x00000000003035c0 r30: 0x000000000031edf0 r31: 0x0000000000003a0c Binary Images Description: 0x1000 - 0x2afff lookupd /usr/sbin/lookupd 0x65000 - 0x67fff com.apple.NetInfo.agent.FF 1.1.0 (???) / System/Library/PrivateFrameworks/NetInfo.framework/Resources/lookupd/ Agents/FF.bundle/FF 0x6a000 - 0x6cfff com.apple.NetInfo.agent.NI 1.1.0 (???) / System/Library/PrivateFrameworks/NetInfo.framework/Resources/lookupd/ Agents/NI.bundle/NI 0x6f000 - 0x72fff com.apple.NetInfo.agent.DS 1.1.1 /System/ Library/PrivateFrameworks/NetInfo.framework/Resources/lookupd/Agents/ DS.bundle/DS 0x8fe00000 - 0x8fe51fff dyld 43.1 /usr/lib/dyld 0x90000000 - 0x901a6fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x901fe000 - 0x90202fff libmathCommon.A.dylib /usr/lib/system/ libmathCommon.A.dylib 0x90728000 - 0x90801fff com.apple.CoreFoundation 6.4.3 (368.12) / System/Library/Frameworks/CoreFoundation.framework/Versions/A/ CoreFoundation 0x9084c000 - 0x9094efff libicucore.A.dylib /usr/lib/ libicucore.A.dylib 0x909a8000 - 0x90a2cfff libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x90ae4000 - 0x90af6fff libauto.dylib /usr/lib/libauto.dylib 0x91077000 - 0x91239fff com.apple.security 4.0.1 (223) /System/ Library/Frameworks/Security.framework/Versions/A/Security 0x9134b000 - 0x91372fff com.apple.SystemConfiguration 1.8.0 / System/Library/Frameworks/SystemConfiguration.framework/Versions/A/ SystemConfiguration 0x9358d000 - 0x935affff com.apple.DirectoryService.Framework 2.0 / System/Library/Frameworks/DirectoryService.framework/Versions/A/ DirectoryService 0x94942000 - 0x94962fff com.apple.NetInfo 1.0.0 (???) /System/ Library/PrivateFrameworks/NetInfo.framework/Versions/A/NetInfo 0x94c98000 - 0x94cb5fff libresolv.9.dylib /usr/lib/libresolv.9.dylib This email sent to site_archiver(a)lists.apple.com

1 0

Re: mDNS Packet storm help
by Eric Dahlman 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: Macnetworkprog(a)lists.apple.com Howdy, Thanks, -Eric On Sep 29, 2005, at 8:43 PM, Marc Krochmal wrote: Hi Eric, <http://developer.apple.com/qa/qa2001/qa1176.html> Thanks. -Marc On Sep 29, 2005, at 6:19 PM, Eric Dahlman wrote: Howdy, Thanks, -Eric P.S. Both machines are running Tiger with the latest updates. This email sent to marc(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… I have sent the trace in a separate message. Just some extra information here. At present mDNSresponder is taking up about 50% of my CPU and is about 864 K in size. When I went home last night my powerbook did not show any of this traffic and when I came in to the office it also did not. I noticed it after about half an hour and switching users, sorry I cannot say exactly when it started or if fast user switching was a contributing factor. I also started a packet trace with Ethereal to watch http traffic during this time but alas it got too big to be manageable. I will describe those problems in my next installment as I think they have a different cause but still may be related ;-) Could you capture a full packet trace in tcpdump format and then send it to me. In trying to track down another problem I have noticed that there is a huge amount of mdns generated by my machine. This is on the order of 1400 packets a second, that is kind of much I assume. I have included the details on one of these packets below. My machine is on a private net with IP 192.168.172.13 and the other machine (steinbit) is on the other side of a nat with a internet visible IP 204.72.xx.xx (to protect the innocent). If it matters my machine is a laptop that regularly moves between two different private networks natted to the internet (work and home). I would appreciate any idea about what is going on an what I can do to stop it. No. Time Source Destination Protocol Info 4 0.001356 192.168.172.1 224.0.0.251 MDNS Standard query response PTR steinbit._afpovertcp._tcp.local Frame 4 (191 bytes on wire, 191 bytes captured) Ethernet II, Src: Cisco-Li_20:09:1e (00:0f:66:20:09:1e), Dst: 01:00:5e:00:00:fb (01:00:5e:00:00:fb) Internet Protocol, Src: 192.168.172.1 (192.168.172.1), Dst: 224.0.0.251 (224.0.0.251) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x18 (DSCP 0x06: Unknown DSCP; ECN: 0x00) Total Length: 173 Identification: 0xa2a7 (41639) Flags: 0x00 Fragment offset: 0 Time to live: 254 Protocol: UDP (0x11) Header checksum: 0xcbda [correct] Source: 192.168.172.1 (192.168.172.1) Destination: 224.0.0.251 (224.0.0.251) User Datagram Protocol, Src Port: mdns (5353), Dst Port: mdns (5353) Source port: mdns (5353) Destination port: mdns (5353) Length: 153 Checksum: 0x0000 (none) Domain Name System (response) Transaction ID: 0x0000 Flags: 0x8400 (Standard query response, No error) Questions: 0 Answer RRs: 1 Authority RRs: 0 Additional RRs: 4 Answers _afpovertcp._tcp.local: type PTR, class IN, steinbit._afpovertcp._tcp.local Name: _afpovertcp._tcp.local Type: PTR (Domain name pointer) Class: IN (0x0001) Time to live: 1 hour, 15 minutes Data length: 11 Domain name: steinbit._afpovertcp._tcp.local Additional records steinbit-2.local: type AAAA, class FLUSH, addr fe80::20d: 93ff:fe65:a43e Name: steinbit-2.local Type: AAAA (IPv6 address) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 16 Addr: fe80::20d:93ff:fe65:a43e steinbit-2.local: type A, class FLUSH, addr 204.72.172.188 Name: steinbit-2.local Type: A (Host address) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 4 Addr: 204.72.172.188 steinbit._afpovertcp._tcp.local: type SRV, class FLUSH, priority 0, weight 0, port 548, target steinbit-2.local Name: steinbit._afpovertcp._tcp.local Type: SRV (Service location) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 8 Priority: 0 Weight: 0 Port: 548 Target: steinbit-2.local steinbit._afpovertcp._tcp.local: type TXT, class FLUSH Name: steinbit._afpovertcp._tcp.local Type: TXT (Text strings) Class: FLUSH (0x8001) Time to live: 1 hour, 15 minutes Data length: 1 Text: _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/marc% 40apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: mDNS Packet storm help
by Marc Krochmal 30 Sep '05

30 Sep '05

site_archiver(a)lists.apple.com Delivered-To: Macnetworkprog(a)lists.apple.com Hi Eric, <http://developer.apple.com/qa/qa2001/qa1176.html> Thanks. -Marc On Sep 29, 2005, at 6:19 PM, Eric Dahlman wrote: Howdy, Thanks, -Eric P.S. Both machines are running Tiger with the latest updates. _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/marc%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists… Could you capture a full packet trace in tcpdump format and then send it to me. In trying to track down another problem I have noticed that there is a huge amount of mdns generated by my machine. This is on the order of 1400 packets a second, that is kind of much I assume. I have included the details on one of these packets below. My machine is on a private net with IP 192.168.172.13 and the other machine (steinbit) is on the other side of a nat with a internet visible IP 204.72.xx.xx (to protect the innocent). If it matters my machine is a laptop that regularly moves between two different private networks natted to the internet (work and home). I would appreciate any idea about what is going on an what I can do to stop it. No. Time Source Destination Protocol Info 4 0.001356 192.168.172.1 224.0.0.251 MDNS Standard query response PTR steinbit._afpovertcp._tcp.local Frame 4 (191 bytes on wire, 191 bytes captured) Ethernet II, Src: Cisco-Li_20:09:1e (00:0f:66:20:09:1e), Dst: 01:00:5e:00:00:fb (01:00:5e:00:00:fb) Internet Protocol, Src: 192.168.172.1 (192.168.172.1), Dst: 224.0.0.251 (224.0.0.251) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x18 (DSCP 0x06: Unknown DSCP; ECN: 0x00) Total Length: 173 Identification: 0xa2a7 (41639) Flags: 0x00 Fragment offset: 0 Time to live: 254 Protocol: UDP (0x11) Header checksum: 0xcbda [correct] Source: 192.168.172.1 (192.168.172.1) Destination: 224.0.0.251 (224.0.0.251) User Datagram Protocol, Src Port: mdns (5353), Dst Port: mdns (5353) Source port: mdns (5353) Destination port: mdns (5353) Length: 153 Checksum: 0x0000 (none) Domain Name System (response) Transaction ID: 0x0000 Flags: 0x8400 (Standard query response, No error) Questions: 0 Answer RRs: 1 Authority RRs: 0 Additional RRs: 4 Answers _afpovertcp._tcp.local: type PTR, class IN, steinbit._afpovertcp._tcp.local Name: _afpovertcp._tcp.local Type: PTR (Domain name pointer) Class: IN (0x0001) Time to live: 1 hour, 15 minutes Data length: 11 Domain name: steinbit._afpovertcp._tcp.local Additional records steinbit-2.local: type AAAA, class FLUSH, addr fe80::20d: 93ff:fe65:a43e Name: steinbit-2.local Type: AAAA (IPv6 address) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 16 Addr: fe80::20d:93ff:fe65:a43e steinbit-2.local: type A, class FLUSH, addr 204.72.172.188 Name: steinbit-2.local Type: A (Host address) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 4 Addr: 204.72.172.188 steinbit._afpovertcp._tcp.local: type SRV, class FLUSH, priority 0, weight 0, port 548, target steinbit-2.local Name: steinbit._afpovertcp._tcp.local Type: SRV (Service location) Class: FLUSH (0x8001) Time to live: 2 minutes Data length: 8 Priority: 0 Weight: 0 Port: 548 Target: steinbit-2.local steinbit._afpovertcp._tcp.local: type TXT, class FLUSH Name: steinbit._afpovertcp._tcp.local Type: TXT (Text strings) Class: FLUSH (0x8001) Time to live: 1 hour, 15 minutes Data length: 1 Text: This email sent to marc(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0