#tcp_sendspace

if you're suspecting your network to be the bottleneck for some of your jobs, you can try to run your job and then on the source LPAR, do a:

$ netstat -an | grep [port]

you can see if your send queue (typically 3rd column) is filling up or how much it fills up.  compare this value with the global tcp_sendspace parameter or from your virtual network interface (if you're not using network options to define your parameters).  if you notice that it's filling the buffer everytime, maybe it's time to increase said buffer.

if you're using "no", then change the global network option settings with:

# no -F -p -o tcp_sendspace=[new_buffer_size]

test your job again and rinse/repeat until you've found something optimal.

NOTE #1: you can do something similar to the tcp_recvspace on the client side as well.

NOTE #2: your tcp_sendspace and tcp_recvspace values should not add up to more than "thewall":

no -a | grep thewall

"thewall" is memory reserved for network and is typically about 50% if your system memory (i know, it would be really hard to exceed this, but still..i have to mention it)

-----------------------------

here's how to change the TCP send and receive buffers on the virtual network interface (i.e. en0) ***WARNING*** this procedure is disruptive:

# chdev -l en0 -a tcp_sendspace=[new_buffer_size] -P

you will then have to unload and reload the devices and start it back up again via smit:

# rmdev -l en0 # rmdev -l ent0 # mkdev -l ent0 # mkdev -l en0