Very slow file copy speed over network with LAN plugin

[bugmenot2]

A few years ago, Christian Ghisler already said on the forum that:
"Unfortunately the Java implementation of SMB protocol isn't very fast indeed. If you can, try using a different protocol."

(proof: https://www.ghisler.ch/board/viewtopic.php?t=39502)

But several years have passed since then, phones and tablets have become many times more powerful and productive, many software solutions have appeared, but the situation has not changed.
I decided to test on a tablet with a Snapdragon 888 processor (8 Gb RAM) with support for the ''ax" protocol for wi-fi (but the lower "ac" protocol was used)
The real speed of copying files on my network share is 32-40 megabytes per second (exactly megabytes, not megabits!)
I started copying exactly 1Gb file, located on my network share, in Total Commander for Android via wi-fi to my tablet.
The file was completely copied in 2 minutes 31 seconds, at an average speed of 6.3 megabytes per second.

After that, I ran exactly the same test, but copied the file over the network using the X-plore file manager.
This time the file was completely copied in just 30 seconds, at an average speed of 32-34 megabytes per second (!).

There is a huge difference in network copy speed between Total Commander and X-plore.

It seems to me that it is high time for Christian Ghisler to do something about this problem in Total Commander for Android (or in the LAN plugin).

UPD:
For clarity, I have added two video files with tests for Total Commander and for X-plore
Test with Total Commander
Test with X-plore

[ghisler(Author)]

Sorry, I have no idea what library X-Plore uses. If you need to transfer such large files, then just use it.

[j4r0l]

hi,
i know this is pretty old post, but i recently went through the same, except i had better speeds with DS file app, since i use synology NAS.
After many hours spent trying various settings, even swapping mikrotik ap for ubiquiti one, i found one reddit post (i can look for link, if you want), that in short suggested to try webdav instead of smb. I only had to install and configure one plugin in NAS, install plugin in total commander and voila, instead of about 7MB/s i am uploading about 50MB/s.

[CoolWater]

Yesterday, I tried Cx File Explorer App. It uses smbj as well. I copied a 15GB file over a WiFi connection (Phone->PC) with 50 MB/s. The Operation lasted round about 5 minutes. In the same time, TC only copied 25%.

The speed of Cx File Explorer App is reproducable. So it IS possible to archive higher copy rates with smbj...

@ghisler: Is there any chance for you to re-check your implementation?

[ghisler(Author)]

Try disabling encryption, it should bring a big improvement. Otherwise I don't know what else I should change.

[CoolWater]

Encryption is and was disabled.

I'm not familiar with smbj but as far as I can see it uses a default buffer size of 1 MB. Maybe this is a good point to adjust/increase the buffer size depending on the connection speed? We did the same in your SFTP plugin.

[ghisler(Author)]

It's possible that it's slower because the data is provided by Total Commander via content provider, but uploaded by the plugin. You're probably better off with a program where everything is in one big executable.

[CoolWater]

Ok, that sounds reasonable. Why did you go the plugin way? You probably mentioned it somewhere before, sorry for asking again...

[ghisler(Author)]

Most people don't need all the access methods provided by the various plugins, so it makes the main program smaller and faster to start. It's also much easier to maintain and to release updates.

[CoolWater]

Thanks Christian! Of course, I don't want to use another file manager. But at least for large files, it will make sense then.

[ghisler(Author)]

I have tested with a 1MB instead of 256kB buffer, and it is indeed faster, but only a little bit:
a 630MB file takes about 35 seconds to upload via Ethernet instead of 51 seconds,
and 33 seconds to download via Ethernet instead of 50 seconds.

[CoolWater]

Well, that's already an improvement. But why not choose an even higher buffer size?

[ghisler(Author)]

I tried with 2MB, and there was no further improvement. Also the larger the buffer is, the longer it takes until the user can abort a transfer. That's not a problem when the speed is several MB/s, but not everyone has such high speeds - transfers via GSM are much slower.

[CoolWater]

That's true. That's why we implemented dynamic buffer sizes in your SFTP plugin. But ok, if there is no big improvement over larger buffers, then 1MB should be good to go.

[ghisler(Author)]

I have now implemented dynamic buffer sizes in the LAN plugin. At first it didn't have a big effect, until I changed the connection buffer sizes to a large value too (8 MB). I'm checking first that the app can allocate enough memory. With this I get 25MB/s for downloads and uploads.
Please test it:
https://www.totalcommander.ch/beta/lanbetapre3.htm