tcp_conn_request_max merely sets the overall limit on the maximum size of a TCP listen queue - the actual minimum being the lesser of tcp_conn_request_max and what the application passes-in on its listen() calls.
The other one is a kludge timeout to deal with FIN_WAIT_2 connections.
The 0 and 1 are the array indicies, which in this context start at zero. The nddconf file will later be "sourced" to create shell arrays of ndd settings to be applied...
As NTP makes no use of TCP, neither tunable should have any bearing on NTP problems :)
As for the netstat stats, while the TCP stats do indeed look a little troubling, and imply there may be almost a 1% packet loss rate, which can be doubleplusungood for TCP performance (depending on the nature of the traffic), a 1% packet loss rate for NTP shouldn't be all that bad.
That the UDP stats for bad header and socket overflow are the same suggests there is a bug in the UDP stats.
For future reference, running pairs of netstat snapshots through beforeafter:
ftp://ftp.cup.hp.com/dist/networking/tools/
can be helpful - particularly if the snapshots are over an "interesting" interval.
*Is* there indeed something configured for NTPDATE_SERVER in the /etc/rc.config.d/netdaemons file? (might have some syntax errors there) My understanding is that an ntpdate -d command will not _actually_ adjust system time:
-d Enable the debugging mode, in which ntpdate will go through all the steps, but not adjust the local clock. information useful for general debugging will also be printed.
Picking your most reliable NTP server to put in the NTPDATE_SERVER entry is goodness - it will make sure that the system time is "close" to that of an ntp server at startup.
there is no rest for the wicked yet the virtuous have no pillows
