NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Poor Mac os x performance
We have ridiculously slow read/write speeds from the only Mac on our network. Every windows machine runs fine. I've done a bunch of research indicating that I need to correct my tcp.delayed_ack se...
Scroll down a bit if you want to skip straight to the answers. Otherwise, you have to wade through my rant first.
I'm having the same problem with abysmal performance on MacOS (like 4 hours to move a few TENS of megabytes), with perfectly reasonable performance under Windows. I read another forum post about a hack to improve throughput by accessing the share over a manually-provided AFP or SMB address in Finder instead of using the devices that are automatically discovered via Bonjour. That helped a bit for AFP, but doesn't do a thing for Time Machine. And anyway, that kind of workaround is a joke. If Bonjour is enabled and the device advertises itself, then it should "just work." Otherwise, take out the feature and make everyone hack it together on their own so they know what they're in for.
It's maddening that I should have to tweak the settings of my computers to work around problems caused by the ReadyNAS unit (Bonjour vs. manual address, TCP ACK delay, etc.). After all, I use two of my Macs both at work and at home, over wired and wireless Ethernet and I never have the slightest bit of trouble with any of the NAS or other network devices at my office, so other manufacturers have obviously figured out something that Netgear needs to learn. (My guess is that this little write-up would shed some light on things: http://www.stuartcheshire.org/papers/NagleDelayedAck/).
In any case, if reasonable performance across several platforms is something Netgear really cares about, they need to be sure their feature sets truly do support all platforms and not just in a minimal enough way to let them sleep at night after stamping it on the marketing pamphlets. One way to do that (beyond implementing better software in the unit itself) is to release an improved driver or an application for the target platform that manages the settings appropriately so that it works for everyone who installs via RAIDar, not just those who have the patience to dig through the forums and tweak and test ad infinitum. Besides, who's to say that if I start messing with default network settings in order to get the ReadyNAS working properly that it won't disrupt communications with other devices (especially given that I switch between home and the office)? It's a slippery slope and while I'm not a network engineer, I shouldn't need to be to get this to work.
Bear in mind that I am however a seasoned software engineer who's done a fair bit of software development, including embedded systems engineering and usability/design engineering, so while I recognize I have high standards, I believe my criticisms are fair.
Now that I've gotten that off of my chest, let's move on and answer your questions...
The reason you are seeing the error about the operation not being permitted is that in order to execute that statement, you need to run it in a context in which the permissions are elevated. The setting affects all TCP/IP traffic on the machine, so it can't be modified by just a standard user; you need admin privileges. To run the command with elevated permissions, use the "sudo" command, which says, "do this as the super user (administrator)".
EDIT: I fat-fingered this in the original post, but it's fixed now.
It's going to ask you for a password, at which time you need to provide the password for the account under which you are running. This prevents you from surreptitiously running a privileged command while sitting at someone else's terminal when that person is unaware. Also, the user in question needs to have been granted administrative access in order to use sudo. When the local account is created (Apple Menu...System Preferences...Accounts), there's a checkbox about whether to allow the user administrative privileges. If that box is not checked, the sudo command will not be allowed to complete and you will continue to get failures. You'd then need to either log into the machine as a user who has admin privileges, or you would need an administrator to change the account settings for the user account that is failing.
That all might seem a bit complicated, but I'll take that any day over the Windows Vista UAC approach of popping up a modal dialog box without a password prompt whenever admin privileges are required. :) All this talk about sudo reminds me of one of my favorite xkcd comics. (You'll have to copy and paste this, since [url] tags are not alowed here.) http://xkcd.com/149/
Putting that command into sysctl.conf sounds like a great idea.
On MacOS, the sysctl.conf file doesn't exist by default, so you won't be able to find it. You need to create your own. The file needs to live at /etc/sysctl.conf and you should use the "sudo" command when you create/edit it so that it'll have proper permissions. Within that file, the pound (#) character is used to denote a comment and the values are stored in the format "key=value", with one item per line. In your case, there's just one value, so your new /etc/sysctl.conf file would look like this:
It's been a long time since I had to play with the sysctl.conf file, so I hope I'm not leading you astray, but this should do the trick for you. If you want more information about sysctl.conf, open a Terminal window and type 'man sysctl.conf' to pull up the manual.
Rant aside, I hope this helps.
And if anyone out there can provide some other workable suggestions that will keep me from spending an entire day to do a few-hundred-megabyte Time Machine backup, I'll be very much obliged.
Andrew
I'm having the same problem with abysmal performance on MacOS (like 4 hours to move a few TENS of megabytes), with perfectly reasonable performance under Windows. I read another forum post about a hack to improve throughput by accessing the share over a manually-provided AFP or SMB address in Finder instead of using the devices that are automatically discovered via Bonjour. That helped a bit for AFP, but doesn't do a thing for Time Machine. And anyway, that kind of workaround is a joke. If Bonjour is enabled and the device advertises itself, then it should "just work." Otherwise, take out the feature and make everyone hack it together on their own so they know what they're in for.
It's maddening that I should have to tweak the settings of my computers to work around problems caused by the ReadyNAS unit (Bonjour vs. manual address, TCP ACK delay, etc.). After all, I use two of my Macs both at work and at home, over wired and wireless Ethernet and I never have the slightest bit of trouble with any of the NAS or other network devices at my office, so other manufacturers have obviously figured out something that Netgear needs to learn. (My guess is that this little write-up would shed some light on things: http://www.stuartcheshire.org/papers/NagleDelayedAck/).
In any case, if reasonable performance across several platforms is something Netgear really cares about, they need to be sure their feature sets truly do support all platforms and not just in a minimal enough way to let them sleep at night after stamping it on the marketing pamphlets. One way to do that (beyond implementing better software in the unit itself) is to release an improved driver or an application for the target platform that manages the settings appropriately so that it works for everyone who installs via RAIDar, not just those who have the patience to dig through the forums and tweak and test ad infinitum. Besides, who's to say that if I start messing with default network settings in order to get the ReadyNAS working properly that it won't disrupt communications with other devices (especially given that I switch between home and the office)? It's a slippery slope and while I'm not a network engineer, I shouldn't need to be to get this to work.
Bear in mind that I am however a seasoned software engineer who's done a fair bit of software development, including embedded systems engineering and usability/design engineering, so while I recognize I have high standards, I believe my criticisms are fair.
Now that I've gotten that off of my chest, let's move on and answer your questions...
I have attempted to execute the suggested command (sysctl -w net.inet.tcp.delayed_ack=0) in terminal and get a message "operation not permitted"
The reason you are seeing the error about the operation not being permitted is that in order to execute that statement, you need to run it in a context in which the permissions are elevated. The setting affects all TCP/IP traffic on the machine, so it can't be modified by just a standard user; you need admin privileges. To run the command with elevated permissions, use the "sudo" command, which says, "do this as the super user (administrator)".
EDIT: I fat-fingered this in the original post, but it's fixed now.
sudo sysctl -w net.inet.tcp.delayed_ack=0
It's going to ask you for a password, at which time you need to provide the password for the account under which you are running. This prevents you from surreptitiously running a privileged command while sitting at someone else's terminal when that person is unaware. Also, the user in question needs to have been granted administrative access in order to use sudo. When the local account is created (Apple Menu...System Preferences...Accounts), there's a checkbox about whether to allow the user administrative privileges. If that box is not checked, the sudo command will not be allowed to complete and you will continue to get failures. You'd then need to either log into the machine as a user who has admin privileges, or you would need an administrator to change the account settings for the user account that is failing.
That all might seem a bit complicated, but I'll take that any day over the Windows Vista UAC approach of popping up a modal dialog box without a password prompt whenever admin privileges are required. :) All this talk about sudo reminds me of one of my favorite xkcd comics. (You'll have to copy and paste this, since [url] tags are not alowed here.) http://xkcd.com/149/
I've been told that this command needs to be copied into the file sysctl.conf so that it will execute on boot, but no matter how I search I can't find such a file.
Putting that command into sysctl.conf sounds like a great idea.
On MacOS, the sysctl.conf file doesn't exist by default, so you won't be able to find it. You need to create your own. The file needs to live at /etc/sysctl.conf and you should use the "sudo" command when you create/edit it so that it'll have proper permissions. Within that file, the pound (#) character is used to denote a comment and the values are stored in the format "key=value", with one item per line. In your case, there's just one value, so your new /etc/sysctl.conf file would look like this:
# Disable delayed ACK over TCP to improve ReadyNAS performance
net.inet.tcp.delayed_ack=0
It's been a long time since I had to play with the sysctl.conf file, so I hope I'm not leading you astray, but this should do the trick for you. If you want more information about sysctl.conf, open a Terminal window and type 'man sysctl.conf' to pull up the manual.
Rant aside, I hope this helps.
And if anyone out there can provide some other workable suggestions that will keep me from spending an entire day to do a few-hundred-megabyte Time Machine backup, I'll be very much obliged.
Andrew
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
