March 2008 - Darwin-dev - lists.apple.com

Re: Troubleshooting a hang.
by stephen joseph butler 09 Mar '08

09 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=KPafd1YRpKZDz/StggcbQ471lGfKxT46KaNyDtrZD3E=; b=xyMoh4H2fXPfEdURalLkX+vmzKnLRQkFyvwydb0RuIKkz0p+MyPoO2zLccDaGvopkfhgrIOSTazW2oXsGiJhRiMTdaETT3bmLpAFPejy6qdtZJg3KQWHBVuDV0obkxka7v1u0Exx652JDtLfNNfz/GGwWZ166GA5fBFAP6ppy/s= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SpKPdAtQzh94hSu3sp0m8dorX/RQ+5VkM6+Nn+S6l44/oqW4GuICr0uTaacxZy2EakSgH4qUyMQauRBq2mfT1jl4IPEHxv64rZNbp4gdR8oxbR05Q4KW1veic0IHk7/K4Vy10ynSjXC4nmmMeNUKXexsm/ZANH3VHxBv5X+5egI= On Sun, Mar 9, 2008 at 4:36 PM, Terry Simons <galimore(a)mac.com> wrote: > I've discovered that a USB SD media reader that I have will cause my > Mac Pro to be unable to boot while plugged in. > > The system chime occurs, but the computer sits at the grey screen > forever and things like holding down option to choose the boot volume > and command-option-p-r to zap the PRAM do not work. > > After several reboots and attempts to figure out what might be causing > my system malfunction, I unplugged said USB device and the apple logo > appeared immediately. > > I'd like to file a radar, but I'm not exactly sure what information > might be needed to be collected or how I might need to go about > collecting the information. > > The reader works when plugged into the system after it has booted. > > Any thoughts here? This might not be a Darwin issue. Have you tried it on a Windows machine? I work for a university department that manages 1000 machines (~200 Macs and the rest PC). We frequently see this type of problem, usually with cheaper USB devices. In particular, a couple years ago we had some USB Zip drives and floppy drives. If the devices were connected when the computers restarted they would hang in the same way. Both the Macs and PC's. I always figured it was a problem initializing the USB device. Eventually we phased them out, so I didn't worry about it too much. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Troubleshooting a hang.
by Terry Simons 09 Mar '08

09 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, The reader works when plugged into the system after it has booted. Any thoughts here? Thanks, - Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I've discovered that a USB SD media reader that I have will cause my Mac Pro to be unable to boot while plugged in. The system chime occurs, but the computer sits at the grey screen forever and things like holding down option to choose the boot volume and command-option-p-r to zap the PRAM do not work. After several reboots and attempts to figure out what might be causing my system malfunction, I unplugged said USB device and the apple logo appeared immediately. I'd like to file a radar, but I'm not exactly sure what information might be needed to be collected or how I might need to go about collecting the information. This email sent to site_archiver(a)lists.apple.com

1 0

Re: [Fwd: Re: execv bug???]
by Jonas Maebe 09 Mar '08

09 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 09 Mar 2008, at 21:37, Jordan K. Hubbard wrote: Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I don't remember the conclusions from last time we discussed this, but was there are reason why posix_spawn(2) was also not under consideration for this? Clearly it's the inheritor of vfork()'s mantle, but there may be a reason why you are unable to use it on MacOSX that I'm forgetting. For production use: backwards compatibility (both regarding posix_spawn itself, and the dynamic linker functionality required to test at run time whether or not it's available). For testing purposes: I simply didn't get around yet to rewriting our "execute process" wrappers to run on top of posix_spawn. I'll post those benchmarks as well once I get around to doing that. This email sent to site_archiver(a)lists.apple.com

1 0

Re: [Fwd: Re: execv bug???]
by Jordan K. Hubbard 09 Mar '08

09 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks for re-running these numbers. It's quite helpful. - Jordan On Mar 9, 2008, at 10:31 AM, Jonas Maebe wrote: On 28 Jan 2008, at 04:23, Jordan K. Hubbard wrote: On Jan 27, 2008, at 2:46 PM, Jonas Maebe wrote: Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/jkh%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I don't remember the conclusions from last time we discussed this, but was there are reason why posix_spawn(2) was also not under consideration for this? Clearly it's the inheritor of vfork()'s mantle, but there may be a reason why you are unable to use it on MacOSX that I'm forgetting. That's more or less true for Linux, but not for Mac OS X at least up till 10.4.x (I haven't benchmarked on 10.5 yet). Compiling our compiler with itself, which involves about 173 (v)fork+execs from a single compiler run to assemble&link all the files, is 20% to 25% slower with fork instead of vfork on a G4, and 35% to 40% on a G5 (32 bit processes in both cases) on 10.4.x. And for clarity: this is relative to the entire time needed for compiling+assembling +linking everything (on the G5: 24 vs 15 seconds), not some academic mbench-like speed difference between the fork and vforks. It would be interesting to benchmark this in 10.5 as well, given a number of changes to the relevant code I finally got around to benchmarking this again. All tests below are under 10.5.2, compiling our compiler with itself. In all cases these are "native" compilations (i.e., an i386 compiler compiling an i386 compiler, an x86_64 compiler compiling an x86_64 compiler etc), and the assembler gets its input via a pipe. When the compiler is told not to assembler/link, it generates a shell script with a the necessary calls to the assembler and linker to assemble/link everything. The time needed to complete this script is what is timed in the second item for each case below. MacBook 2.2GHz, 1GB ram (November 2007): * 32 bit (200 invocations of the assembler + 1 of the linker, 216480 loc): - compile to assembler files without assembling or linking: 8.7 secs - assemble+link using shell script: 2.6 secs - compile + assemble + link (vfork): 10.6 secs - compile + assemble + link (fork): 13.2 secs -> fork makes the total 24.5% slower * 64 bit (179 invocations of the assembler + 1 of the linker, 201171 loc) - compile to assembler files without assembling or linking: 6.1 secs - assemble+link using shell script: 2.1 secs - compile + assemble + link (vfork): 8.2 secs - compile + assemble + link (fork): 11.4 secs -> fork makes the total 39% slower Dual G5 1.8 GHz, 3 GB ram: * 32 bit (171 invocations of the assembler + 1 of the linker, 177620 loc) - compile to assembler files without assembling or linking: 16.1 secs - assemble+link using shell script: 4.2 secs - compile + assemble + link (vfork): 19.7 secs - compile + assemble + link (fork): 28.4 secs -> fork makes the total 44.1% slower * 64 bit (164 invocations of the assembler + 1 of the linker, 172379 loc) - compile to assembler files without assembling or linking: 18 secs - assemble+link using shell script: 3.9 secs - compile + assemble + link (vfork): 21.1 secs - compile + assemble + link (fork): 33.4 secs -> fork makes the total 53.6% slower So at least for my use case, there doesn't appear to be much of an improvement (at least not for ppc; I don't have any numbers for x86 for 10.4.x). This email sent to jkh(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: [Fwd: Re: execv bug???]
by Jonas Maebe 09 Mar '08

09 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 28 Jan 2008, at 04:23, Jordan K. Hubbard wrote: On Jan 27, 2008, at 2:46 PM, Jonas Maebe wrote: Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… That's more or less true for Linux, but not for Mac OS X at least up till 10.4.x (I haven't benchmarked on 10.5 yet). Compiling our compiler with itself, which involves about 173 (v)fork+execs from a single compiler run to assemble&link all the files, is 20% to 25% slower with fork instead of vfork on a G4, and 35% to 40% on a G5 (32 bit processes in both cases) on 10.4.x. And for clarity: this is relative to the entire time needed for compiling+assembling +linking everything (on the G5: 24 vs 15 seconds), not some academic mbench-like speed difference between the fork and vforks. It would be interesting to benchmark this in 10.5 as well, given a number of changes to the relevant code I finally got around to benchmarking this again. All tests below are under 10.5.2, compiling our compiler with itself. In all cases these are "native" compilations (i.e., an i386 compiler compiling an i386 compiler, an x86_64 compiler compiling an x86_64 compiler etc), and the assembler gets its input via a pipe. When the compiler is told not to assembler/link, it generates a shell script with a the necessary calls to the assembler and linker to assemble/link everything. The time needed to complete this script is what is timed in the second item for each case below. MacBook 2.2GHz, 1GB ram (November 2007): * 32 bit (200 invocations of the assembler + 1 of the linker, 216480 loc): - compile to assembler files without assembling or linking: 8.7 secs - assemble+link using shell script: 2.6 secs - compile + assemble + link (vfork): 10.6 secs - compile + assemble + link (fork): 13.2 secs -> fork makes the total 24.5% slower * 64 bit (179 invocations of the assembler + 1 of the linker, 201171 loc) - compile to assembler files without assembling or linking: 6.1 secs - assemble+link using shell script: 2.1 secs - compile + assemble + link (vfork): 8.2 secs - compile + assemble + link (fork): 11.4 secs -> fork makes the total 39% slower Dual G5 1.8 GHz, 3 GB ram: * 32 bit (171 invocations of the assembler + 1 of the linker, 177620 loc) - compile to assembler files without assembling or linking: 16.1 secs - assemble+link using shell script: 4.2 secs - compile + assemble + link (vfork): 19.7 secs - compile + assemble + link (fork): 28.4 secs -> fork makes the total 44.1% slower * 64 bit (164 invocations of the assembler + 1 of the linker, 172379 loc) - compile to assembler files without assembling or linking: 18 secs - assemble+link using shell script: 3.9 secs - compile + assemble + link (vfork): 21.1 secs - compile + assemble + link (fork): 33.4 secs -> fork makes the total 53.6% slower So at least for my use case, there doesn't appear to be much of an improvement (at least not for ppc; I don't have any numbers for x86 for 10.4.x). This email sent to site_archiver(a)lists.apple.com

1 0

Re: net.inet.tcp.delayed_ack value?
by Andre-John Mas 09 Mar '08

09 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 8-Mar-08, at 21:22 , Greg Shenaut wrote: On Mar 8, 2008, at 4:22 PM, Andre-John Mas wrote: http://www.macosxhints.com/article.php?story=20080305053403936 Basically it suggests entering the following: sudo sysctl -w net.inet.tcp.delayed_ack=0 A responder to the MacOS X Hints article states: Andre _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I recently came across this hint at MacOS X hints, suggesting a solution to speed up Airport transfer speeds: >From what I have been told this current setting is based on Nagle's algorithm, but reading up on it at Wikipedia I see: "This algorithm interacts badly with TCP delayed acknowledgments, a feature introduced into TCP at roughly the same time in the early 1980s, but by a different group. With both algorithms enabled, applications which do two successive writes to a TCP connection, followed by a read, experience a constant delay of up to 500 milliseconds, the "ACK delay". For this reason, TCP implementations usually provide applications with an interface to disable the Nagle algorithm. This is typically called the TCP_NODELAY option." "This bug has been documented for quite some time now, and NetBSD fixed". Is the current approach indeed outdated, needing borrowing changes from the NetBSD stack, or are there particular scenarios the NetBSD implementation handles badly? I don't know if you've seen this: <http://www.stuartcheshire.org/papers/NagleDelayedAck/ > but it's a very interesting read, and it explains exactly what is going on with the delay. Thanks. If I understand this rightly using a double-buffering approach would be better and given this option this would suggest that Darwin doesn't use this as part of its network implementation? If this is indeed the case, has anyone looked at reworking this? This email sent to site_archiver(a)lists.apple.com

1 0

Re: C++ std::locale's ctor only accepts "C" and "POSIX"
by Patrick Rutkowski 09 Mar '08

09 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=+ZhZUvL/vrL5DlSBh18zom/rlFqRTU2RgJmiSQotmoc=; b=G34SWiMsslGtN6mki4qgQ1zs6bDHjuyoqcyOTTlufyW2jAfZwfSSRvNyYz9jksBwayDOw8awGys3IPq1FeTv9V4qGzvInlFJCrd0D6OtLVDhUwgrnbAaQdJNBmT03GFRnc+ypyX6ueBZ+tkVz3zlchlS5uZo90Mp5VztNN13hTY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=v/P3r3FeoDRtnVrTy8zkBTcp2WbhIxlWUgXO9RgaEsValPVMbude1iYiaTVSMFjYAxcLWcpOxDgCvFvup7xXEfMGXkX2viHiXHvkwKDHwf0tOa0Xbtr8bizUvsFp+/64WqZSEh5wXj2hAq+Bb8wxu+srrsi+Hoh2oY+cLBwQ9lw= I made a small mistake when writing my initial message. === BEGING TERMINAL OUTPUT === Trying c locales... Succeeded in calling setlocale(LC_ALL, "C") Succeeded in calling setlocale(LC_ALL, "POSIX") Succeeded in calling setlocale(LC_ALL, "en_US") Succeeded in calling setlocale(LC_ALL, "en_US.UTF-8") Succeeded in calling setlocale(LC_ALL, "pl_PL") Succeeded in calling setlocale(LC_ALL, "pl_PL.ISO8859-2") -Patrick On Mar 8, 2008, at 9:57 PM, Patrick Rutkowski wrote: === BEGING TERMINAL OUTPUT === Trying c locales... Succeeded in calling setlocale(LC_ALL, "C") Succeeded in calling setlocale(LC_ALL, "POSIX") Succeeded in calling setlocale(LC_ALL, "en_US") Succeeded in calling setlocale(LC_ALL, "en_US.UTF-8") Succeeded in calling setlocale(LC_ALL, "pl_PL") Succeeded in calling setlocale(LC_ALL, "pl_PL.ISO8859-2") Trying C++ locales... Succeeded ctor for std::locale with "C" Succeeded ctor for std::locale with "POSIX" Succeeded ctor for std::locale with "en_US" Succeeded ctor for std::locale with "en_US.UTF-8" Succeeded ctor for std::locale with "pl_PL" Succeeded ctor for std::locale with "pl_PL.ISO8859-2" === END TERMINAL OUTPUT === === BEGING TERMINAL OUTPUT === Trying c locales... Succeeded in calling setlocale(LC_ALL, "C") Succeeded in calling setlocale(LC_ALL, "POSIX") Succeeded in calling setlocale(LC_ALL, "en_US") Succeeded in calling setlocale(LC_ALL, "en_US.UTF-8") Succeeded in calling setlocale(LC_ALL, "pl_PL") Succeeded in calling setlocale(LC_ALL, "pl_PL.ISO8859-2") Trying C++ locales... Succeeded ctor for std::locale with "C" Succeeded ctor for std::locale with "POSIX" Failed ctor for std::locale with "en_US" Failed ctor for std::locale with "en_US.UTF-8" Failed ctor for std::locale with "pl_PL" Failed ctor for std::locale with "pl_PL.ISO8859-2" === END TERMINAL OUTPUT === _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I forgot to print the e.what() message when the std::locale ctor throws an exception. I've updated the code in the link to do that. Here's the new output on my OS X machine; as expected, it just says that the locale name is invalid: Trying C++ locales... Succeeded ctor for std::locale with "C" Succeeded ctor for std::locale with "POSIX" Failed ctor for std::locale with "en_US": locale::facet::_S_create_c_locale name not valid Failed ctor for std::locale with "en_US.UTF-8": locale::facet::_S_create_c_locale name not valid Failed ctor for std::locale with "pl_PL": locale::facet::_S_create_c_locale name not valid Failed ctor for std::locale with "pl_PL.ISO8859-2": locale::facet::_S_create_c_locale name not valid === END TERMINAL OUTPUT === I'm currently studying how locales work in C/C++, I'm using OS X machine and a Linux machine for testing. I wrote the following test program to make sure that I can successfully initialize a few locales on both my systems: http://www.rutski89.com:31597/upload/test.cpp Running this on my linux machine I get exactly the output I expected, all success: However, when running on my OS X machine with the stock g++ (running on 10.5.1) I get the following: It seems that the system is only able to create C++ locales for "C" and "POSIX", which is puzzling, and also very unsatisfactory. It would be unhappy, but at least settling, if I found a page that said something like "C++ locales on OS X only support "C" and "POSIX", tough luck!". However, such a page is nowhere to be found, and in fact I have found evidence to the contrary. Searching "site:apple.com std::locale" in google brings up various pages where people describe issues with the usage of std::locale. However, these pages pertain to issues with the usage of the locale after it has already been created, which implies that the people who made the posts were actually able to create the locale to begin with; so why am I not able to create them? I've been banging my head against the wall for a while now; any help would be much appreciated -Patrick This email sent to site_archiver(a)lists.apple.com

1 0

C++ std::locale's ctor only accepts "C" and "POSIX"
by Patrick Rutkowski 09 Mar '08

09 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:content-type:content-transfer-encoding:mime-version:subject:date:x-mailer; bh=zATei/U2pYaT3pXfs7z3sgMQVWQne6YNW/IZq6joCo4=; b=PWo7349y2B4v7IrZTnzfQegg7p7Na07O/j/3tm50YKqYLg929aycIbuE3uZuouC5tIgPNAkyjMp7cJ6Rh8FM9LynKoaX4n9ThozQ0bRfVvby6oh69LzYr2ZBmyP+O1Dwxu0RmiCmJBY5y7dkYavioV4K+WH6sUjSUphy7yGvgRc= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:mime-version:subject:date:x-mailer; b=ij6LgexvhHPGTBDzMZUNzoYU4DELyxcQ6YTg1oimDhghlZYQHIbC0kWR4MxorkQjxADh3+2A8Pw1wkKbxdvS097xzGq9gK3WVXs9okYDiD2pbdSLhQzwVrFtW1Qq9ZzeHI4PCTDXCPD5GbtzjqDirSXCYPGAqS+6fWgT0H5u9E0= === BEGING TERMINAL OUTPUT === Trying c locales... Succeeded in calling setlocale(LC_ALL, "C") Succeeded in calling setlocale(LC_ALL, "POSIX") Succeeded in calling setlocale(LC_ALL, "en_US") Succeeded in calling setlocale(LC_ALL, "en_US.UTF-8") Succeeded in calling setlocale(LC_ALL, "pl_PL") Succeeded in calling setlocale(LC_ALL, "pl_PL.ISO8859-2") Trying C++ locales... Succeeded ctor for std::locale with "C" Succeeded ctor for std::locale with "POSIX" Succeeded ctor for std::locale with "en_US" Succeeded ctor for std::locale with "en_US.UTF-8" Succeeded ctor for std::locale with "pl_PL" Succeeded ctor for std::locale with "pl_PL.ISO8859-2" === END TERMINAL OUTPUT === === BEGING TERMINAL OUTPUT === Trying c locales... Succeeded in calling setlocale(LC_ALL, "C") Succeeded in calling setlocale(LC_ALL, "POSIX") Succeeded in calling setlocale(LC_ALL, "en_US") Succeeded in calling setlocale(LC_ALL, "en_US.UTF-8") Succeeded in calling setlocale(LC_ALL, "pl_PL") Succeeded in calling setlocale(LC_ALL, "pl_PL.ISO8859-2") Trying C++ locales... Succeeded ctor for std::locale with "C" Succeeded ctor for std::locale with "POSIX" Failed ctor for std::locale with "en_US" Failed ctor for std::locale with "en_US.UTF-8" Failed ctor for std::locale with "pl_PL" Failed ctor for std::locale with "pl_PL.ISO8859-2" === END TERMINAL OUTPUT === _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I'm currently studying how locales work in C/C++, I'm using OS X machine and a Linux machine for testing. I wrote the following test program to make sure that I can successfully initialize a few locales on both my systems: http://www.rutski89.com:31597/upload/test.cpp Running this on my linux machine I get exactly the output I expected, all success: However, when running on my OS X machine with the stock g++ (running on 10.5.1) I get the following: It seems that the system is only able to create C++ locales for "C" and "POSIX", which is puzzling, and also very unsatisfactory. It would be unhappy, but at least settling, if I found a page that said something like "C++ locales on OS X only support "C" and "POSIX", tough luck!". However, such a page is nowhere to be found, and in fact I have found evidence to the contrary. Searching "site:apple.com std::locale" in google brings up various pages where people describe issues with the usage of std::locale. However, these pages pertain to issues with the usage of the locale after it has already been created, which implies that the people who made the posts were actually able to create the locale to begin with; so why am I not able to create them? I've been banging my head against the wall for a while now; any help would be much appreciated -Patrick This email sent to site_archiver(a)lists.apple.com

1 0

Re: net.inet.tcp.delayed_ack value?
by Greg Shenaut 09 Mar '08

09 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 8, 2008, at 4:22 PM, Andre-John Mas wrote: http://www.macosxhints.com/article.php?story=20080305053403936 Basically it suggests entering the following: sudo sysctl -w net.inet.tcp.delayed_ack=0 A responder to the MacOS X Hints article states: Greg Shenaut _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I recently came across this hint at MacOS X hints, suggesting a solution to speed up Airport transfer speeds: >From what I have been told this current setting is based on Nagle's algorithm, but reading up on it at Wikipedia I see: "This algorithm interacts badly with TCP delayed acknowledgments, a feature introduced into TCP at roughly the same time in the early 1980s, but by a different group. With both algorithms enabled, applications which do two successive writes to a TCP connection, followed by a read, experience a constant delay of up to 500 milliseconds, the "ACK delay". For this reason, TCP implementations usually provide applications with an interface to disable the Nagle algorithm. This is typically called the TCP_NODELAY option." "This bug has been documented for quite some time now, and NetBSD fixed". Is the current approach indeed outdated, needing borrowing changes from the NetBSD stack, or are there particular scenarios the NetBSD implementation handles badly? I don't know if you've seen this: <http://www.stuartcheshire.org/papers/NagleDelayedAck/ > but it's a very interesting read, and it explains exactly what is going on with the delay. This email sent to site_archiver(a)lists.apple.com

1 0

net.inet.tcp.delayed_ack value?
by Andre-John Mas 09 Mar '08

09 Mar '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com http://www.macosxhints.com/article.php?story=20080305053403936 Basically it suggests entering the following: sudo sysctl -w net.inet.tcp.delayed_ack=0 A responder to the MacOS X Hints article states: Andre _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I recently came across this hint at MacOS X hints, suggesting a solution to speed up Airport transfer speeds: >From what I have been told this current setting is based on Nagle's algorithm, but reading up on it at Wikipedia I see: "This algorithm interacts badly with TCP delayed acknowledgments, a feature introduced into TCP at roughly the same time in the early 1980s, but by a different group. With both algorithms enabled, applications which do two successive writes to a TCP connection, followed by a read, experience a constant delay of up to 500 milliseconds, the "ACK delay". For this reason, TCP implementations usually provide applications with an interface to disable the Nagle algorithm. This is typically called the TCP_NODELAY option." "This bug has been documented for quite some time now, and NetBSD fixed". Is the current approach indeed outdated, needing borrowing changes from the NetBSD stack, or are there particular scenarios the NetBSD implementation handles badly? This email sent to site_archiver(a)lists.apple.com

1 0