I have no idea why, but I've got only a few replies. Suggestions were like
"don't forget to use 'bi' to transfer binary files". Well, after spending
some time on solving the problem, finally I got a some sort of solution.
First of all, I checked cables, adapters errors and 100mb ports settings
in our Cisco Catalyst 5000 switch. Cisco displayed half duplex connection
to the one of our servers. I tried to manually set it to full duplex and
disabled auto-negation-mode for the network card of the server.
Next, I verified several tcp/hme settings for both servers:
/usr/sbin/ndd /dev/hme adv_100fdx_cap 1
/usr/sbin/ndd /dev/hme adv_autoneg_cap 0
/usr/sbin/ndd /dev/tcp tcp_xmit_hiwat 65535
/usr/sbin/ndd /dev/tcp tcp_recv_hiwat 65535
/usr/sbin/ndd /dev/tcp tcp_cwnd_max 65534
/usr/sbin/ndd /dev/tcp tcp_deferred_ack_interval 10
/usr/sbin/ndd /dev/tcp tcp_rexmit_interval_min 1500
Then I snooped FTP transfer in both directions. I found that when you issue
'get' command, then you get 11th packet being delivered with pretty big
delay that was around 3.9 sec, while other packets have been delivered in a
0.00012 sec, just in a flash!
So that 11th packet seems to be the main reason which garbles the actual
transfer speed rate. Now I will do my own investigations on this problem. I
suppose it may be a bug in Sun's ftp implementation. Possibly new ftp
damon/utility will be able to solve the problem, but who knows.
I am grateful to the following people, who have found free time to give
me a hint and a bit of information:
Jeff Wasilko <email@example.com>
Mark Spooner mark.spooner@Central.Sun.COM
Eddy Fafard firstname.lastname@example.org
David L. Markowitz <David.Markowitz@litronic.com>
Vitaly Beliaev Unix Systems Administration JSC MISW, Magnitogorsk, Russian Federation
voice: +7 (3511) 335639 mailto://email@example.com http://www.mmk.ru -=======================================================-
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:33 CDT