cyberduck
cyberduck copied to clipboard
SMB protocol way slower since > 8.7.2
Describe the bug The last version I've had a good smb connection speed with was 8.7.2. I believe I've tried to update to 8.8 which killed the performance. Before: 50 MB/s (limited by the hardware at the smb sever), everything after 8.7.2. => ~5-8 MB/s.
I've seen that you've changed the encryption to be on by default between the versions, which i thought was the problem, so i rolled back and it was fast again.
Today I'v seen a major version update and noticed in the changelog that you've reverted the changes to the SMB connection, so I tried updating again. But sadly, the speed is still droppping to around 5 MB/s.
Any idea whats going on? I've checked again with the old version (8.7.2), and with this, the speed is at the old level ~50 MBs again.
The smb server is a fairly vanilla samba on ubuntu 22.04.
Best, Michael
Relates to #15817
Probably blocked by upstream issue ^1.
Depends on ^1.
i can report that smb transfers are still slow as f in 9.0.2 (and need a good amount of CPU resources).
Maybe its the wrong place/time/setting, but what was the issue with "the old" implementation for smb (pre smbj)? (implying to roll it back ;) as @dkocher is astonished on the PR on their side too. maybe its not a very activly maintained project and thus not a good choice from the beginning?)
I guess there are many people expieriencing this bug, but just don't recognize it could be an issue in a software ("huh, my wifi is probabaly bad today 🤷♂️")
Best, Michael
Has anyone experienced a pick up of speeds since this update?
I'm still getting incredibly slow speeds when using cyberduck (340KBps) vs finder (270MBps) [GLOBAL: vfs objects = fruit streams_xattr]
In my Debug logs I'm getting a never ending loop of:
2025-01-27 12:02:50,082 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Open share p1 in thread xir6PKIV-transfer-2
2025-01-27 12:02:50,082 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Obtain lock for share DiskShareWrapper{share=DiskShare[\\19...20\p1]}
2025-01-27 12:02:50,082 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Obtained lock for share DiskShareWrapper{share=DiskShare[\\19...20\p1]}
2025-01-27 12:02:50,082 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Validate share DiskShareWrapper{share=DiskShare[\\19...20\p1]}
2025-01-27 12:02:50,082 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Opened share DiskShareWrapper{share=DiskShare[\\19...20\p1]} in thread xir6PKIV-transfer-2
2025-01-27 12:02:50,082 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Release share DiskShareWrapper{share=DiskShare[\\19...20\p1]} in thread xir6PKIV-transfer-2
2025-01-27 12:02:50,082 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Passivate share DiskShareWrapper{share=DiskShare[\\19...20\p1]}
2025-01-27 12:02:50,082 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Released share DiskShareWrapper{share=DiskShare[\\19...20\p1]} in thread xir6PKIV-transfer-2
with random instances of:
2025-01-27 12:03:13,498 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Opened share DiskShareWrapper{share=DiskShare[\\1...20\p1]} in thread xir6PKIV-transfer-2
2025-01-27 12:03:13,498 [xir6PKIV-transfer-2] DEBUG com.hierynomus.smbj.share.SMB2Writer - Writing to \\1...20\p1\sm...ah\proxmox-ve_8.3-1.iso from offset 36700160
2025-01-27 12:03:13,499 [xir6PKIV-transfer-2] DEBUG com.hierynomus.smbj.connection.Connection - Granted 16 (out of 1915) credits to Encrypted[SMB2_WRITE with message id << 733 >>]
2025-01-27 12:03:13,509 [xir6PKIV-transfer-2] DEBUG com.hierynomus.protocol.commons.concurrent.Promise - Awaiting << 733 >>
2025-01-27 12:03:13,516 [Thread-138] DEBUG com.hierynomus.smbj.connection.packet.SMB3DecryptingPacketHandler - Decrypting packet Encrypted for session id << 3770882592 >>
2025-01-27 12:03:13,517 [Thread-138] DEBUG com.hierynomus.smbj.connection.packet.SMB3DecryptingPacketHandler - Decrypted packet Encrypted for session id << 3770882592 >> is packet SMB2_WRITE with message id << 733 >>.
2025-01-27 12:03:13,517 [Thread-138] DEBUG com.hierynomus.smbj.connection.packet.SMB2SignatureVerificationPacketHandler - Passthrough Signature Verification as packet is decrypted
2025-01-27 12:03:13,517 [Thread-138] DEBUG com.hierynomus.smbj.connection.packet.SMB2CreditGrantingPacketHandler - Server granted us 47 credits for SMB2_WRITE with message id << 733 >>, now available: 1946 credits
2025-01-27 12:03:13,517 [Thread-138] DEBUG com.hierynomus.protocol.commons.concurrent.Promise - Setting << 733 >> to `SMB2_WRITE with message id << 733 >>`
2025-01-27 12:03:13,517 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Release share DiskShareWrapper{share=DiskShare[\\1...20\p1]} in thread xir6PKIV-transfer-2
2025-01-27 12:03:13,517 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Passivate share DiskShareWrapper{share=DiskShare[\\1...20\p1]}
2025-01-27 12:03:13,517 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Released share DiskShareWrapper{share=DiskShare[\\1...20\p1]} in thread xir6PKIV-transfer-2
2025-01-27 12:03:13,571 [xir6PKIV-transfer-2] DEBUG ch.cyberduck.core.smb.SMBSession - Open share p1 in thread xir6PKIV-transfer-2
on v9.1.2
Ok on v.9.1.3 it is a bit quicker at 7MB/s
Can cyberduck ever saturate my network and reach the speeds of finder or is that just not possible?
Ok on v.9.1.3 it is a bit quicker at 7MB/s
Can cyberduck ever saturate my network and reach the speeds of finder or is that just not possible?
I have opened ^1 to provide a profile with encryption disabled that will allow for better throughput when the server does not require encrypted connections.
@smashah Let me know if you can test the SMB (No Encryption) connection profile now available from Preferences → Profiles.
I can reproduce this problem using MBP M2 with Ethernet Adapter and Ubuntu SMB Server.
Link Speed:1Gbps Finder SMB:~110MiB/s
v8.7.2 SMB:~25MiB/s SMB (No Encryption):~50MiB/s
v9.1.3 SMB:~3MiB/s SMB (No Encryption):~8MiB/s
I've just tried again on 9.1.3 with a fresh bookmark and the mentioned unencrypted profile. The speed is still dropping quickly to an unbearable speed (here 2.2 MB/s, but it will drop even more the longer it transfers), see the attached screenshots. Finder SMB is still fast (~80 MB/s throughout the whole transfer).
Sorry for testing on Wifi, but I've observed the same on Ethernet a month ago or so but didn't screenshot it at the time.
Maybe we can reopen this if you don't mind @dkocher, because I think it's sadly not yet resolved :(
For anyone thats having this problem as well, it's maybe worth to use the workaround to transfer files over sftp (ssh) instead, but it's (for me) around 50% slower then smb was <= 8.7.2 or via finder.
Regression from 0655747f.