I have seen some "interesting" results with NetBSD to a Sun over 
to ethernets with a router in between them.

The following is with the local machine being a 486 running NetBSD and
the remote machine being a SPARC 5 running SUNOS 4.1.3_U1.  This IS
repeatable and the lower number appears to always be about a factor
of 100 slower than the other direction. 

ftp> get musictex.zip
local: musictex.zip remote: musictex.zip
200 PORT command successful.
150 Binary data connection for musictex.zip (140.160.164.6,1224) (596480 bytes).
226 Binary Transfer complete.
596480 bytes received in 191 seconds (3130 bytes/s)
ftp> put musictex.zip junk
local: musictex.zip remote: junk
200 PORT command successful.
150 Binary data connection for junk (140.160.164.6,1225).
226 Binary Transfer complete.
596480 bytes sent in 1.52 seconds (391176 bytes/s)
ftp> 


But, notice, it is not only ftp ....  So there is something wrong .....

bashful[8]$ time rcp fawn:musictex.zip .
       61.89 real         0.04 user         0.66 sys

bashful[9]$ time rcp musictex.zip fawn:junk
        7.14 real         0.02 user         0.63 sys


And now for another interesting point ... between a 486 NetBSD machine
and the same SPARC 5  connected over the same ether .....


nooksack[67]$ time rcp fawn:musictex.zip .
        2.38 real         0.02 user         0.65 sys

nooksack[68]$ time rcp musictex.zip fawn:junk
        2.34 real         0.01 user         0.73 sys

AND

ftp> get musictex.zip
local: musictex.zip remote: musictex.zip
200 PORT command successful.
150 Binary data connection for musictex.zip (140.160.140.251,1489) (596480 bytes).
226 Binary Transfer complete.
596480 bytes received in 1.94 seconds (307965 bytes/s)
ftp> put musictex.zip junk
local: musictex.zip remote: junk
200 PORT command successful.
150 Binary data connection for junk (140.160.140.251,1490).
226 Binary Transfer complete.
596480 bytes sent in 2.49 seconds (239844 bytes/s)


SO, my only conclusion here must be that the router between the NetBSD
machine and the SPARC 5 is the problem or is part of the problem.

-- 
Phil Nelson
e-mail: phil@cs.wwu.edu
http://www.cs.wwu.edu/~phil