Tunable TCP Parameters

Hello,
A couple of questions on the tunable TCP parameters:
1. How "dynamic" are the dynamic parameters? Will a change (via ndd) affect existing connections, new connections from that point on, etc? Would a server process (servicing connection requests) need to be re-started? Is a re-boot required (assuming persistence of the settings in a service init file)?
2. I'm seeing differing opinions between the web server crowd and the Sun documentation with regard to the various abort, keepalive and rexmit settings. Most of postings I see from server side folks have something close to the following:
/usr/sbin/ndd -set /dev/tcp tcp_ip_abort_cinterval 60000
/usr/sbin/ndd -set /dev/tcp tcp_ip_abort_interval 60000
/usr/sbin/ndd -set /dev/tcp tcp_keepalive_interval 90000
/usr/sbin/ndd -set /dev/tcp tcp_rexmit_interval_max 10000
/usr/sbin/ndd -set /dev/tcp tcp_rexmit_interval_min 3000
Sun recommends:
Set tcp_rexmit_interval_max to at least eight times the value of tcp_rexmit_interval_min
Set tcp_ip_abort_interval to at least four times the value of tcp_rexmit_interval_max.
tcp_keepalive_interval should not be set below 15 minutes.
Our particular environment is Solaris 10 running Weblogic Server 9.2.2. Machines are typically sun4u with 32GB of memory.
Any insight is appreciated.
Thanks,
Bob

Many web server recommendations are very aggressive. The Sun recommendations are more conservative. If your server is only talking to LAN clients, then many of the TCP settings which are necessary for the internet can be tweaked quite a bit and will probably never cause a problem. If you're communicating with internet clients, then I would be careful moving things too far from default.
Darren

Similar Messages

TCP parameters

Hello all. I have been given a list of tcp parameters of which I can't find an equivalent for Solaris. The paramers are as follow..
inet     tcp_keepalive_default=1
inet     tcp_keepinit=60
inet     tcp_keepidle=360
inet     tcp_keepcnt=4
inet     tcp_keepintvl=60
These comes from HP Tru64, on the internet module (inet). I have found the equivalent of the parameters tcp_keepinit, which is tcp_ip_abort_cinterval under the /dev/tcp module of ndd and tcp_keepidle, with tcp_keepalive_interval as its equivalent. I can't seem to find equivalents for tcp_keepcnt and tcp_keepintvl though.
Here are the description for both parameters..
The TCP_KEEPINTVL option specifies the number of seconds to wait before retransmitting a keepalive probe.
The TCP_KEEPCNT option specifies the maximum number of keepalive probes to be sent.
If anyone have a clue as of which parameters correspond to those ones I would be greattly appreciate it to know. I have been looking closely at tcp_time_wait_interval but I am not sure.
Thanks!

Hi ,
Run the following command in command prompt:
netsh int sh int
you will get the Interface ID for the adapters you have connected, once you have that run the following command:
netsh int ipv4 sh int "interface id"
interface id will be a number digit.
For Eg: netsh int ipv4 sh int 11
Hope this helps.
Regards.
Sandeep Suman

Changing tcp parameters

hi,
I have changed the tcp parameters as per the idsktune output. After restarting the server and directory server application, I get the following message.
[14/Apr/2005:19:00:36 +0000] config - Unknown attribute modify will be ignored
Any body knows what this means ??
Thanks in advance

Which config file should i check for this?The directory server config file - slapd-instance/config/dse.ldif
we noticed
this after changing the tcp parameters and rebooting
the system.Which tcp parameters? How did you change them?
>
Does this mean some error or warning or it is just
information?? pls suggest.It is an error. It probably means that the directory server cannot read its config file.
>
Thanks

How to extract the TCP Parameters?

How do i extract the TCP/IP parameters set on a solaris 8 system?

To get names of available tcp kernel parameter run the following:
ndd -get /dev/tcp \?
To get the value of a tcp kernel parameter:
ndd -get /dev/tcp <parameter name>
such as
ndd -get /dev/tcp tcp_time_wait_interval
For the meaning of different parameter consult Solaris kernel tuning reference (look on docs.sun.com)

Solaris Kernel and TCP/IP Tuning Parameters (Continued)

This page describes some configuration optimizations for Solaris hosts running ATG Page Serving instances (application servers) that will increase server efficiency.
Note that these changes are specific to Solaris systems running ATG application servers (+page serving+ instances). Do not use these on a web server or database server. Those systems require entirely different settings.
h3. Solaris 10 Kernel
Adjust /etc/system (parameters below) and reboot the system.
set rlim_fd_cur=4096
set rlim_fd_max=4096
set tcp:tcp_conn_hash_size=32768
set shmsys:shminfo_shmmax=4294967295
set autoup=900
set tune_t_fsflushr=1h4. Set limits on file descriptors
{color:blue}set rlim_fd_max = 4096{color}
{color:blue}set rlim_fd_cur = 4096{color}
Raise the file-descriptor limits to a maximum of 4096. Note that this tuning option was not mentioned in the "Sun Performance And Tuning" book.
[http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-32/index.html]
h4. Increase the connection hash table size
{color:blue}set tcp:tcp_conn_hash_size=8192{color}
Increase the connection hash table size to make look-up's more efficient. The connection hash table size can be set only once, at boot time.
[http://download.oracle.com/docs/cd/E19455-01/816-0607/chapter4-63/index.html]
h4. Increase maximum shared memory segment size
{color:blue}set shmsys:shminfo_shmmax=4294967295{color}
Increase the maximum size of a system V shared memory segment that can be created from roughly 8MB to 4GB.
This provides an adequate ceiling; it does not imply that shared memory segments of this size will be created.
[http://download.oracle.com/docs/cd/E19683-01/816-7137/chapter2-74/index.html]
h4. Increase memory allocated for dirty pages
{color:blue}set autoup=900{color}
Increase the amount of memory examined for dirty pages in each invocation and frequency of file system synchronizing operations.
The value of autoup is also used to control whether a buffer is written out from the free list. Buffers marked with the B_DELWRI flag (which identifies file content pages that have changed) are written out whenever the buffer has been on the list for longer than autoup seconds. Increasing the value of autoup keeps the buffers in memory for a longer time.
[http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-16/index.html]
h4. Specify the time between fsflush invocations
Specifies the number of seconds between fsflush invocations.
{color:blue}set tune_t_fsflushr=1{color}
[http://download.oracle.com/docs/cd/E19082-01/819-2724/chapter2-105/index.html]
Again, note that after adjusting any of the preceding kernel parameters you will need to reboot the Solaris server.
h3. TCP
ndd -set /dev/tcp tcp_time_wait_interval 60000
ndd -set /dev/tcp tcp_conn_req_max_q 16384
ndd -set /dev/tcp tcp_conn_req_max_q0 16384
ndd -set /dev/tcp tcp_ip_abort_interval 60000
ndd -set /dev/tcp tcp_keepalive_interval 7200000
ndd -set /dev/tcp tcp_rexmit_interval_initial 4000
ndd -set /dev/tcp tcp_rexmit_interval_max 10000
ndd -set /dev/tcp tcp_rexmit_interval_min 3000
ndd -set /dev/tcp tcp_smallest_anon_port 32768
ndd -set /dev/tcp tcp_xmit_hiwat 131072
ndd -set /dev/tcp tcp_recv_hiwat 131072
ndd -set /dev/tcp tcp_naglim_def 1h4. Tuning the Time Wait Interval and TCP Connection Hash Table Size
{color:blue}/usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000{color}
The tcp_time_wait_interval is how long a connection stays in the TIME_WAIT state after it has been closed (default value 240000 ms or 4 minutes). With the default setting, this socket will remain for 4 minutes after you have closed the FTP connection. This is normal operating behavior. It is done to ensure that any slow packets on the network will arrive before the socket is completely shutdown. As a result, a future program that uses the same socket number won't get confused upon receipt of packets that were intended for the previous program.
On a busy Web server a large backlog of connections waiting to close could build up and the kernel can become inefficient in locating an available TCP data structure. Therefore it is recommended to change this value to 60000 ms or 1 minute.
h4. Tuning the maximum number of requests per IP address per port
{color:blue}ndd -set /dev/tcp tcp_conn_req_max_q 16384{color}
{color:blue}ndd -set /dev/tcp tcp_conn_req_max_q0 16384{color}
The {color:blue}tcp_conn_req_max_q{color} and {color:blue}tcp_conn_req_max_q0{color} parameters are associated with the maximum number of requests that can be accepted per IP address per port. tcp_conn_req_max_q is the maximum number of incoming connections that can be accepted on a port. tcp_conn_req_max_q0 is the maximum number of “half-open” TCP connections that can exist for a port. The parameters are separated in order to allow the administrator to have a mechanism to block SYN segment denial of service attacks on Solaris.
The default values are be too low for a non-trivial web server, messaging server or directory server installation or any server that expects more than 128 concurrent accepts or 4096 concurrent half-opens. Since the ATG application servers are behind a DMZ firewall, we needn't starve these values to ensure against DOS attack.
h4. Tuning the total retransmission timeout value
{color:blue}ndd -set /dev/tcp tcp_ip_abort_interval 60000{color}
{color:blue}tcp_ip_abort_interval{color} specifies the default total retransmission timeout value for a TCP connection. For a given TCP connection, if TCP has been retransmitting for tcp_ip_abort_interval period of time and it has not received any acknowledgment from the other endpoint during this period, TCP closes this connection.
h4. Tuning the Keep Alive interval value
{color:blue}ndd -set /dev/tcp tcp_keepalive_interval 7200000{color}
{color:blue}tcp_keepalive_interval{color} sets a probe interval that is first sent out after a TCP connection is idle on a system-wide basis.
If SO_KEEPALIVE is enabled for a socket, the first keep-alive probe is sent out after a TCP connection is idle for two hours, the default value of the {color:blue}tcp_keepalive_interval{color} parameter. If the peer does not respond to the probe after eight minutes, the TCP connection is aborted.
The {color:blue}tcp_rexmit_interval_*{color} values set the initial, minimum, and maximum retransmission timeout (RTO) values for a TCP connections, in milliseconds.
h4. Tuning the TCP Window Size
{color:blue}/usr/sbin/ndd -set /dev/tcp tcp_xmit_hiwat 65535{color}
{color:blue}/usr/sbin/ndd -set /dev/tcp tcp_recv_hiwat 65535{color}
Setting these two parameters controls the transmit buffer and receive window. We are tuning the kernel to set each window to 65535 bytes. If you set it to 65536 bytes (64K bytes) or more with Solaris 2.6, you trigger the TCP window scale option (RFC1323).
h4. Tuning TCP Slow Start
{color:blue}/usr/sinb/ndd -set /dev/tcp tcp_slow_start_initial 4{color}
tcp_slow_start_initial is the number of packets initially sent until acknowledgment, the congestion window limit.
h4. Tuning the default bytes to buffer
{color:blue}ndd -set /dev/tcp tcp_naglim_def 1{color}
{color:blue}tcp_naglim_def{color} is the default number of bytes to buffer. Each connection has its own copy of this value, which is set to the minimum of the MSS for the connection and the default value. When the application sets the TCP_NODELAY socket option, it changes the connection's copy of this value to 1. The idea behind this algorithm is to reduce the number of small packets transmitted across the wire by introducing a short (100ms) delay for packets smaller than some minimum.
Changing the value of tcp_naglim_def to 1 will have the same effect (on connections established after the change) as if each application set the TCP_NODELAY option.
{note}
The current value of any of the TCP parameters can be displayed with the command ndd get. So to retrieve the current setting of the {color:blue}tcp_naglim_def parameter{color}, simply execute the command:\\
{color:blue}ndd -get /dev/tcp tcp_naglim_def{color}
{note}
h3. References
Solaris Tunable Parameters Reference Manual
[http://download.oracle.com/docs/cd/E19455-01/816-0607/index.html]
WebLogic Server Performance and Tuning
[http://download.oracle.com/docs/cd/E11035_01/wls100/perform/OSTuning.html]

For example,
Socket.setSoTimeout() sets SO_TIMEOUT option and I
want to what TCP parameter this option corresponds in
the underlying TCP connection.This doesn't correspond to anything in the connection, it is an attribute of the API.
The same questions
arises fro other options from SocketOptions class.setTcpNoDelay() controls the Nagle algorithm. set{Send,Receive}BufferSize() controls the local socket buffers.
Most of this is quite adequately described in the javadoc actually.

Kernel parameters in solaris 9

Can some one list some important tunable kernel parameters in solaris 9. Or a document to go through
Thanks
Naras

have a look at : - http://docs.sun.com/db/doc/816-7137?q=tunable&s=t
you can alaways come back to us if you have any questions about a specific tunable.
- Saurabh Mishra

TCP tuning for system recovery

Hello everyone,
I'm involved in a DRP exercise, and I'm trying to improve the performance of the restores from tape. I've got side-by-side Windows and Solaris 9/10 servers and the Solaris boxes are seeing about half the bandwidth of the Windows boxes.
The systems are Gbe everywhere, including the backup server. The Solaris boxes are booted from CD/DVD and we then run the recovery software off an NFS share. My restores are maxing out at about 16Mbps on Gbe links. My enemy Windows servers are running at about 25-30Mbps, also rather slow, but better.
I'm not looking for miraculous solutions, but if I can bring the data rate up a bit with some simple changes, that would be great. I was wondering whether any TCP parameters might help.
Any pointers/tips would be appreciated.
Thanks,
Mark
Edited by: MarkDrummond on 4-Jun-2009 9:01 PM

Robert,
Good point, I should be looking at disk performance. The recovery software takes over the console so I have no way to get back to the CLI. I'll have to investigate that.
We did have some luck with one server, a V440. Hardcoding the switch port and the server port to 1000fdx, and setting a few TCP parameters did get this one server up to ~115Mbps, a dramatic improvement over previous results.
tcp_max_buf
tcp_cwnd_buf
tcp_xmit_hiwat
tcp_recv_hiwat
In our data centre, we are copper Gbe everywhere, on Cisco gear, we leave all ports to autoconfig, don't do any TCP tuning, and I get about 700Mbps between servers. But our DRP partner insists that we should hardcode everything here at our DRP site. It's all Gbe and Cisco here too. Very strange, but auto causes a lot of grief around here.
Thanks again,
Mark

TCP delay on same host

Hi there. I have two TCP applications running on the same host and one app needs to periodically send messages to the other at very short intervals. I am noticing an 80 to 100 millisecond delay from when the sender does a send() and the receiver's select() indicates the message has been received. It is very important for our application that there be as little latency as possible so 80-100ms is way too much. I cannot understand why this is so because as I said both processes are on the same host.
Do I need to tune some TCP parameters or do something special in setting up the sockets to avoid this delay? Any help or hints would be greatly appreciated!
[In case it helps: 1) if a message is transmitted after a gap of 1 second or greater, the receiver gets the message immediately without the latency mentioned above 2) the two processes are binding to the IP address of their host and not "localhost" or INADDR_ANY].
Thanks a lot in advance.
Sam.

hi gp and thank you very much for responding to this unusual problem.
- switch ports to the PCs are configured as portfast.
- switch ports between two catalyst switches are not configured (default)
- i didnt use the 'switchport access' command since they are default layer 2 interfaces. would 'switchport access vlan 1' command make any difference?
- i looked at the port status and confirmed connection is 100 mbps full duplex.
unusual issue is; ping, udp, multicast shows up in a very short time after I re-plug the uplink. that proves all ports are in forwarding state. only TCP shows up with delay, which doesnt occur on 200 $ unmanaged switch??
thanks in advance for any suggestions

How To Increase TCP Connections in Windows 2012 Server

We have installed our Java application in Windows 2012 Server. After running for some time application started showing Connection Time out. We have set TCP Parameters MaxUserPort = 65534 and TcpTimedWaitDelay = 30.
We are facing the same issue, even after setting the parameters in windows registry. We have verified in our application, "There is no connection pool issue and no thread issue".
We are using JDK v6.0.29, Tomcat 7, MYSQL 5.5.
Apart from MaxUserPort and TcpTimedWaitDelay is there any other TCP parameters in Windows 2012 to improve performance of the server and our application.
2) At the same time we have found that ‘There is sluggishness in I/O process’. Is there any registry parameters to improve I/O performance in the system.
Thank You.

Hi,
You can refer the following article “Tuning TCP” part.
Windows Server 2012 Performance
Tuning Guidelines
Hope this helps.
We
are trying to better understand customer views on social support experience, so your participation in this
interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place.

ASIP dumps TCP stack nightly

We have been running ASIP 6.3 since 2001, migrating it through several servers. For the past 8 months, it has resided on an early-edition G4 (ID 106, ROM 7.5.1) with 1.5GB RAM and two ATA drives supporting a small school (100 user accounts, rarely > 30 logged on at once). The server provides only AFS services, using both TCP/IP and AppleTalk. The underlying system is OS 9.1.1 (we found it would not install on 9.2). Until 3 weeks ago we'd never had a real problem we hadn't caused ourselves.
For the last 3 weeks, every morning when we arrive at school the server is hung, requiring a hard restart. There is usually (but not always) an error message: "TCP stack was dumped." We tried turning off TCP/IP service from Server Manager, but that didn't change the problem. This ONLY happens overnight -- otherwise, all services run smoothly. The machine is on a UPS which tests OK, and is set to restart if it loses power.
We can't tell if this is an ASIP error or an OS 9.1.1 error. We've never seen this error before (between us we have over 2 decades of Appleshare server management experience behind us).
Ideas?

Look at this site for getting 9.2.2 and 6.3.3 up on your Server:
http://os9forever.com
Click the link on the left labeled ASIP patch. Print out and read the documents. I tried to install the patch, and could not quite get it to work, but in reading the discussion and examining the files in question, I realized a drag-and-drop install of the crucial parts was all that was needed. It worked fine.
One possibility on dumping the TCP/IP stack may be lurking in the TCP/IP Control Panel. If the "load only when needed" box is checked, when things get very quiet, it may just unload it.
I am not certain whether that parameter is one of the several AppleTalk/ TCP parameters stored in Parameter RAM, but a PRAM reset at a minimum, and replacing the battery at the extreme may be in order anyway.

Broken TCP stack in latest kernel when under heavy load

I'm running an Arch box with a decent amount of HTTP traffic. After upgrading to the latest kernel I've seen that packets are send from the wrong source and destination address. This only applies during heavy load (100+ requests per second). tcpdump shows the following:
18:52:58.512573 IP 0.0.0.0.80 > 0.0.0.0.4316: Flags [FP.], seq 0, ack 1, win 14400, length 0
18:52:58.512600 IP 0.0.0.0.80 > 0.0.0.0.56546: Flags [FP.], seq 0, ack 1, win 14400, length 0
18:52:58.512621 IP 0.0.0.0.80 > 0.0.0.0.4535: Flags [FP.], seq 0, ack 1, win 14600, length 0
18:52:58.512641 IP 0.0.0.0.80 > 0.0.0.0.3528: Flags [FP.], seq 0, ack 1, win 14600, length 0
18:52:58.512662 IP 0.0.0.0.80 > 0.0.0.0.4509: Flags [FP.], seq 0, ack 1, win 14400, length 0
18:52:58.512682 IP 0.0.0.0.80 > 0.0.0.0.65040: Flags [FP.], seq 0, ack 1, win 14600, length 0
18:52:58.512702 IP 0.0.0.0.80 > 0.0.0.0.2455: Flags [FP.], seq 0, ack 1, win 10240, length 0
18:52:58.512722 IP 0.0.0.0.80 > 0.0.0.0.16545: Flags [FP.], seq 0:268, ack 1, win 15008, length 268
18:52:58.519258 IP 0.0.0.0.80 > 0.0.0.0.29802: Flags [FP.], seq 0:268, ack 1, win 980, options [nop,nop,TS val 745514 ecr 1317559555], length 268
18:52:58.565907 IP 0.0.0.0.80 > 0.0.0.0.32376: Flags [FP.], seq 0, ack 1, win 14400, length 0
18:52:58.619241 IP 0.0.0.0.80 > 0.0.0.0.50493: Flags [FP.], seq 0:268, ack 1, win 11256, options [nop,nop,TS val 745544 ecr 9539361], length 268
18:52:58.805927 IP 0.0.0.0.80 > 0.0.0.0.20852: Flags [FP.], seq 3025419976:3025420244, ack 3037671074, win 967, options [nop,nop,TS val 745600 ecr 6445640], length 268
18:52:58.805953 IP 0.0.0.0.80 > 0.0.0.0.65025: Flags [FP.], seq 1663827778:1663828046, ack 2127675352, win 707, options [nop,nop,TS val 745600 ecr 457812708], length 268
18:52:58.845918 IP 0.0.0.0.80 > 0.0.0.0.2217: Flags [FP.], seq 0:268, ack 1, win 707, options [nop,nop,TS val 745612 ecr 546643], length 268
18:52:59.099245 IP 0.0.0.0.80 > 0.0.0.0.5112: Flags [FP.], seq 0:268, ack 1, win 15008, length 268
18:52:59.152582 IP 0.0.0.0.80 > 0.0.0.0.1175: Flags [FP.], seq 0:268, ack 1, win 15008, length 268
18:52:59.232612 IP 0.0.0.0.80 > 0.0.0.0.47217: Flags [FP.], seq 684621876:684622144, ack 3544859356, win 11256, length 268
18:52:59.659258 IP 0.0.0.0.80 > 0.0.0.0.3098: Flags [FP.], seq 2105858244:2105858512, ack 3896053916, win 980, options [nop,nop,TS val 745856 ecr 52041], length 268
18:52:59.659290 IP 0.0.0.0.80 > 0.0.0.0.3099: Flags [FP.], seq 18772067:18772335, ack 2568646283, win 980, options [nop,nop,TS val 745856 ecr 52041], length 268
18:52:59.759244 IP 0.0.0.0.80 > 0.0.0.0.18780: Flags [FP.], seq 0:268, ack 1, win 707, options [nop,nop,TS val 745886 ecr 168876], length 268
18:52:59.845907 IP 0.0.0.0.80 > 0.0.0.0.58449: Flags [FP.], seq 0, ack 1, win 980, options [nop,nop,TS val 745912 ecr 528058426], length 0
18:52:59.925936 IP 0.0.0.0.80 > 0.0.0.0.65137: Flags [FP.], seq 0:268, ack 1, win 15008, length 268
18:52:59.979497 IP 0.0.0.0.80 > 0.0.0.0.2920: Flags [FP.], seq 0:268, ack 1, win 980, options [nop,nop,TS val 745952 ecr 18879], length 268
18:52:59.979527 IP 0.0.0.0.80 > 0.0.0.0.2922: Flags [FP.], seq 0:268, ack 1, win 980, options [nop,nop,TS val 745952 ecr 18879], length 268
18:52:59.979553 IP 0.0.0.0.80 > 0.0.0.0.2940: Flags [FP.], seq 0:268, ack 1, win 980, options [nop,nop,TS val 745952 ecr 18879], length 268
Source and destination ports are correctly set. Wireshark shows the correct HTML inside the packets that are returned to 0.0.0.0. The web server log also looks normal; the correct IP address is displayed and logged as a successful request.
When dropping incomming traffic on port 80 on eth0 everything works as expected (when requesting the server on eth1, which otherwise fails).
I'm running on "Linux srv 3.0-ARCH #1 SMP PREEMPT Wed Oct 19 12:14:48 UTC 2011 i686" which is the latest kernel in the repos. When booting the fallback image this problem does not exist, all packets are correctly addressed no matter how much load I put on the server.
Does anyone else have this problem?
Edit:
Running lighttpd 1.4.29. No tweaked kernel/TCP parameters whatsoever.
Last edited by nullvoid (2011-10-29 17:19:57)

Did a full reinstall of Arch on another machine and the problem still persist. Tried with Apache and Nginx, same behaviour as with Lighttpd. Could anyone else using an arch box under heavy load see if there's activity from 0.0.0.0?
Hint:
# tcpdump -n host 0.0.0.0
I'll do a bug report upstream later today.

Equivalent of Linux's sysctl

Is there an equivalent command of linux's /sbin/sysctl on solaris 10? This command is used in setting and retrieving the TCP buffers on Linux.
Also what is the equivalent on solaris 10 for the tcp buffers tcp_rmem and tcp_wmem of linux.
Thanks for your time and response
Chakra

To modify kernel parameters at runtime you may use "mdb" and "ndd"
commands. To modify kernel parameters statically use /etc/system file
(man -s4 system).
To modify tcp parameters use "ndd". Type
# ndd /dev/tcp \?
to obtain parameters list. See "Solaris Tunable Parameters Reference
Manual" http://docs.sun.com/app/docs/coll/47.16 for details.
Vitaly Filatov,
Moscow Russia

Unreliable reading from AFP server (NAS)

Following on from some earlier problems, I've started encountering a new, and much worse, problem. After I successfully connect to the AFP share, I can look at the contents of various remote folders in Finder. But, some of the folders are just showing as empty, even though I know they aren't. I tried waiting several minutes, nothing showing up (and there doesn't seem to be any way to tell if Finder is waiting for a response or not - with other folders you may get the same result, but the files usually show up after a few seconds).
There doesn't seem to be any particular pattern to it. Certain folders show all their contents, others just appear to be empty. Also, if I try to list the contents of these folders from the command line (ls -la /Volumes/Share/Folder) then once again it works for the same ones that work in Finder, but it otherwise it just hangs. I am getting similar problems sometimes trying to unmount certain shares from the command line with diskutil: again, it just hangs.
This wasn't happening when I tried it recently (as suggested in the thread referenced at the top of this post) and the only thing to have changed about my system since then is this update:
http://support.apple.com/kb/HT6207
I'm not sure if that's likely to have anything to do with it, or if it's just because I've not been using the NAS from the Mac so much lately (mostly been working on Windows stuff the last couple of weeks). Maybe it's just coincidence that this is the first time I've noticed it.
I've tried restarting the Mac and the NAS and the same thing is happening even from that completely clean state (so no chance anything has gone into sleep mode or similar). I can access the same folders with no problems from a Windows PC over SMB. For some reason when I try to connect to the SMB share from Mavericks it completely fails to read the contents of any shared volume, so I have to use AFP (or possibly figure out what's wrong with SMB, but that could be a much harder problem to solve).
I couldn't find much about this issue by googling, although I did find a recommendation to clear the Finder cache. However, on my system, ~/Library/Caches/com.apple.finder doesn't exist. Has this been removed from Mavericks?
There's always a chance this could be a problem with the AFP implementation on the NAS, whch is an Asustor AS-202T, running the latest software (ADM 2.1.1.R3B2). Is anyone else on here using an Asustor NAS?

hi,
any luck resolving this?
I am investigating the slow large directory reading problem between macbook OS X Mavericks 10.9.5 and NAS Asustor 202TE ADM 2.2.1.R863
Basically, reading a large directory (c. 2,000 files) is very slow.
Then, deleting a file is fast the first time, then any subsequent delete, in same session, seems to cause a file list refresh, and slow again.
This is very painful to review sets of files created daily from my garden cam, where most need to be deleted.
I really don't want to boot up a windows machine for this task.
Potential solutions / areas to investigate:
1. mac tcp parameters: delayed_ack, packet size, frames etc
     found a good resource here for this, but I haven't found any combination that makes a difference for me
2. turning off icon previews etc
     done this, no change
3. directory list cache: client side vs server side
     cannot find any info relating to the Asustor or mac implementation
4. finder replacement
     not sure this has any benefit
5. smb vs afp
     I haven't noticed any performance difference, so doubt this is significant
Any help would be appreciated.

HTTP connectivity error while using Blackberry MDS and JDE 5.0.0

Hello,
I am using BB MDS simulator 4.1.2 and BB JDE 5.0.0 for testing sample Oracle ADF Mobile client apps that I have developed.
My app tries to access webservices via HTTP.
Here is where I am encountering a HTTP connectivity issue.
1. For instance, while trying to test HTTP using Blackberry browser, I see the error : "Unknown host mobile.blackberry.com:80"
2. The sample I tried to run to test webservices - accepts a word from the user and gets it translated in to a desired language, using a webservice provided on the internet.
Here, I have tried to translate the word 'madam' from English to French.
I have encountered a HTTP/1.0 400 Bad Request.
Kindly have a look at the MDS Trace as below (related entries in bold) and suggest if I am missing something from the configuration perspective.
PS : I have tried various options from the blackberry forums but they were not very helpful.
<2010-05-24 17:48:16.000 IST>:[215]:<MDS-CS_MDS>:<DEBUG>:<LAYER = SCM, EVENT = Device connections: AVG latency (msecs)0>
<2010-05-24 17:48:16.000 IST>:[216]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = RemovedReceivingQueue, DEVICEPIN:CONNECT
IONID = 2100000a:771975383, ReceivingQueueSize = 0>
<2010-05-24 17:48:16.343 IST>:[217]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = Notification, TAG = 36110347, STATE = DE
LIVERED>
<2010-05-24 17:48:19.046 IST>:[218]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = RemovedSendingQueue, DEVICEPIN = 2100000
a>
<2010-05-24 17:49:57.437 IST>:[219]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = Receiving, TAG = 371769629, DEVICEPIN =
2100000a, VERSION = 16, CONNECTIONID = 771975384, SEQUENCE = 0, TYPE = CONNECTION-REQUEST, CONNECTIONHANDLER = httpc, PR
OTOCOL = TCP, PARAMETERS = [www.webservicex.net:80], SIZE = 121>
<2010-05-24 17:49:57.437 IST>:[220]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = CreatedReceivingQueue, DEVICEPIN:CONNECT
IONID = 2100000a:771975384, ReceivingQueueSize = 1>
<2010-05-24 17:49:57.437 IST>:[221]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = StartExecuting, TAG = 371769629, DEVICEP
IN = 2100000a, VERSION = 16, CONNECTIONID = 771975384, SEQUENCE = 0, TYPE = CONNECTION-REQUEST, CONNECTIONHANDLER = http
c, PROTOCOL = TCP, PARAMETERS = [www.webservicex.net:80], SIZE = 121>
<2010-05-24 17:49:57.437 IST>:[222]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = EndExecuting, TAG = 371769629, DEVICEPIN
= 2100000a, VERSION = 16, CONNECTIONID = 771975384, SEQUENCE = 0, TYPE = CONNECTION-REQUEST, CONNECTIONHANDLER = httpc,
PROTOCOL = TCP, PARAMETERS = [www.webservicex.net:80], SIZE = 121>
<2010-05-24 17:49:57.437 IST>:[223]:<MDS-CS_MDS>:<DEBUG>:<LAYER = SCM, EVENT = Available threads in DefaultJobPool = 9 r
unning JobRunner: DefaultJobRunner-3>
<2010-05-24 17:49:57.453 IST>:[224]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: DefaultJobRunner-3 started>
<2010-05-24 17:49:57.453 IST>:[225]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVI
CEPIN = 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION =>
<2010-05-24 17:49:57.453 IST>:[225]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVI
CEPIN = 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = [Transmission Line Section]:>
*<2010-05-24 17:49:57.453 IST>:[225]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVI*
CEPIN = 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = GET /TranslateService.asmx/Translate?LanguageMode=English
TOFrench&Text=madam HTTP/1.1>
<2010-05-24 17:49:57.453 IST>:[225]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVI
CEPIN = 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = [Headers Section]: 2 headers>
<2010-05-24 17:49:57.453 IST>:[225]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVI
CEPIN = 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = x-rim-conttime:10000>
<2010-05-24 17:49:57.453 IST>:[225]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVI
CEPIN = 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = Host:www.webservicex.net>
<2010-05-24 17:49:57.453 IST>:[225]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVI
CEPIN = 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = [Parameters Section]: 2 parameters>
*<2010-05-24 17:49:57.453 IST>:[225]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVI*
CEPIN = 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = LanguageMode=EnglishTOFrench>
*<2010-05-24 17:49:57.453 IST>:[225]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = ReceivedFromDevice, DEVI*
CEPIN = 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = Text=madam>
<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION =>
<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = [Transmission Line Section]:>
*<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN*
*= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = GET /TranslateService.asmx/Translate?LanguageMode=EnglishTOFren*
ch&Text=madam HTTP/1.1>
<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = [Headers Section]: 6 headers>
<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = Connection:close>
<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = Via:MDS_4.1.2.17>
<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = Accept:*/*>
<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = x-rim-original-accept:*/*>
<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = x-rim-conttime:10000>
<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = Host:www.webservicex.net>
<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = [Parameters Section]: 2 parameters>
*<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN*
*= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = LanguageMode=EnglishTOFrench>*
*<2010-05-24 17:49:57.453 IST>:[226]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToServer, DEVICEPIN*
*= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = Text=madam>*
<2010-05-24 17:49:57.515 IST>:[227]:<MDS-CS_MDS>:<DEBUG>:<LAYER = SCM, EVENT = Statistics save task started>
<2010-05-24 17:49:57.625 IST>:[228]:<MDS-CS_MDS>:<DEBUG>:<LAYER = SCM, EVENT = Statistics save task finished -- number o
f rows inserted:5>
<2010-05-24 17:50:18.453 IST>:[229]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION =>
<2010-05-24 17:50:18.453 IST>:[229]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = [Transmission Line Section]:>
*<2010-05-24 17:50:18.453 IST>:[229]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN*
*= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = HTTP/1.0 400 Bad Request>*
<2010-05-24 17:50:18.453 IST>:[229]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = [Headers Section]: 2 headers>
<2010-05-24 17:50:18.453 IST>:[229]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = Content-Type:text/plain>
<2010-05-24 17:50:18.453 IST>:[229]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = Content-Length:35>
<2010-05-24 17:50:18.453 IST>:[229]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HANDLER = HTTP, EVENT = SentToDevice, DEVICEPIN
= 2100000a, CONNECTIONID = 771975384, HTTPTRANSMISSION = [Parameters Section]: 0 parameters>
<2010-05-24 17:50:18.468 IST>:[230]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = CreatedSendingQueue, DEVICEPIN = 2100000
a>
<2010-05-24 17:50:18.468 IST>:[231]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: DefaultJobRunner-3 stopping>
<2010-05-24 17:50:18.468 IST>:[234]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = Sending, TAG = 36110349, DEVICEPIN = 210
0000a, VERSION = 16, CONNECTIONID = 771975384, SEQUENCE = 0, TYPE = DATA, SIZE = 48>
<2010-05-24 17:50:18.468 IST>:[235]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: DefaultJobRunner-3 stopped>
<2010-05-24 17:50:18.484 IST>:[236]:<MDS-CS_MDS>:<DEBUG>:<LAYER = SCM, EVENT = Finished JobRunner: DefaultJobRunner-3, a
vailable threads in DefaultJobPool = 10, time spent = 21047ms>
<2010-05-24 17:50:18.500 IST>:[239]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = Sending, TAG = 36110350, DEVICEPIN = 210
0000a, VERSION = 16, CONNECTIONID = 771975384, SEQUENCE = 1, TYPE = DISCONNECT-ORDER, SIZE = 0>
<2010-05-24 17:50:18.500 IST>:[240]:<MDS-CS_MDS>:<DEBUG>:<LAYER = SCM, EVENT = Device connections: AVG latency (msecs)32>
<2010-05-24 17:50:18.500 IST>:[241]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: ConnectionsInputStreamesReader0-Def
aultJobRunner-3 stopping>
<2010-05-24 17:50:18.500 IST>:[242]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, HTTP Thread: ConnectionsInputStreamesReader0-Def
aultJobRunner-3 stopped>
<2010-05-24 17:50:18.500 IST>:[243]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = RemovedReceivingQueue, DEVICEPIN:CONNECT
IONID = 2100000a:771975384, ReceivingQueueSize = 0>
<2010-05-24 17:50:18.531 IST>:[244]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = Notification, TAG = 36110349, STATE = DE
LIVERED>
<2010-05-24 17:50:18.562 IST>:[245]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = Notification, TAG = 36110350, STATE = DE
LIVERED>
<2010-05-24 17:50:19.046 IST>:[246]:<MDS-CS_MDS>:<DEBUG>:<LAYER = IPPP, EVENT = RemovedSendingQueue, DEVICEPIN = 2100000
a>

Hi, there:
A couple of things to try and check:
- Does your network connection goes through proxy server? If you are behind a proxy server, then you would need to set up proxy server in MDS by open the file <MDS simulator install>/config/rimpublic.property, go to the [HTTP Handler] section, and add the following line:
application.handler.http.proxyEnabled = true
application.handler.http.proxyHost=<your proxy server host name>
application.handler.http.proxyPort=<your proxy server port>
- Try BlackBerry MDS simulator that came with JDE 5.0. MDS 4.1.2 should still work with 5.0 device simulators, but it's worth a shot
Can you hit the web service from the browser in your Blackberry simulator? Feel free to directly contact me at [email protected] - if necessary we can also pull in BlackBerry/RIM resources to help diagnose this.
Thanks,
Joe Huang

Networking changes between Solaris 10 x86 10/08 (u6) and previous versions?

Solaris Community:
We have a J2SE CORBA-based application (that uses the default Sun ORB) that has run without problems on Solaris 8, 9, and 10 on both SPARC and, more recently, X86 platforms. Upgrading our client side machine (X4100 M2 Opteron platform) from Solaris 10 x86 5/08 (u5) to Solaris 10 x86 10/08 (u6) has resulted in threading or socket contention issues that we have not experienced previously. Using Live Upgrade, we can quickly go back to the u5 install on the client machine .... and the problems go away .... going back to u6, however, and the problems begin to show almost immediately. Our Java code base is identical as is the version of the JDK (1.5.0_16), so it would appear that there must be an underlying change to socket, networking, or threading behavior between these two versions of Solaris.
Thus far, I've not been unable to find details of changes either in the networking support or the threading model that might explain this .... or course, I don't have great expertise in these areas.
I've tried to use 'ndd /dev/tcp SOME_PARAMETER' for all of the /dev/tcp parameters returned by 'ndd /dev/tcp \?' to try to see if there are underlying changes in the /dev/tcp parameters .... but have not found any differences between Solaris 10 u5 and u6.
Can anyone point me to resources that would discuss changes between Solaris 10 u5 or u6 that might explain the problems that we've encountered? Or, alternatively, other system parameters that I could check that might explain changes in either TCP socket or threading behavior?
Thanks for your input,
John

I have a vague memory of someone reporting something similar which turned out to be due to a solaris feature called tcp_fusion.
To check whether thats your problem or not try the following.
Add following line in the /etc/system file.
set ip:do_tcp_fusion = 0
Once the /etc/system file is updated, it will be necessary to restart the system before the workaround will take effect.

Tunable TCP Parameters

Similar Messages

Maybe you are looking for