I am using SSHFS to transfer files under Linux between my notebook and my desktop machine. It's easier then NFS because one doesn't have to configure mount points and permissions a priori.
Now, using SSHFS is slower than I would expect from a 100MBit Ethernet connection (sadly, the notebook has no Gigabit Ethernet). I get about 10MiB/sec, instead of 12.5MiB/sec. Can the overhead of protocols "steel" the "rest" (which would be 2.5MiB/sec)?
Switching from IPv4 to IPv6 didn't improved the speed. Using -C for compression made the process even slower.
SSHFS allows to pass parameters to underlying SSH (using -o SSHOPT=VAL). Well, there are a lot of SSH parameters there.
From experience, which of these parameters could improve speed of an SSHFS connection?
You're getting about 80 Mb/s out of your 100 Mb/s link. That's pretty close to the theoretical limit of the link (you'll rarely get anything like the nominal link speed) and is an entirely reasonable figure to achieve.
Beyond that, on top of the overheads of running an encrypted tunnel (SSH) you've also got the TCP overheads, and any other traffic using the connection. I'd say that practically speaking you're unlikely to achieve any better throughput without changing to a protocol with a lower overhead.
compression slows on pack/unpack
arcfour is blazing fast !!!WHILE!!!! not 100% safe. LAN ONLY
auto_cache allows you to store file localy in temp somewhere so its not accessed via network second time.
with this 1GB connection to server is twice as fast for me.
you can "limit" the encryption Overhead by using "arcfour" as cipher. The SSH option is "-c arcfour"
The fact that compression slowed down the transfer could indicate a high processor usage.
What are the respecting configurations and processor usage when transferring using sshfs ?
regarding the fact that you use a 100Mb/s lan, you can test your speed with other protocols/overhead, like FTP.
Iperf can also be used in that case to test the bandwidth, disregarding any disk slowdowns.