search

xbmc / vfs.sftp

SFTP VFS addon for Kodi
GNU General Public License v2.0
21 stars 28 forks source link

Old performance issues, new plan of action ? #22

Open swatgoss opened 5 years ago

swatgoss commented 5 years ago

Hi,

I've been using XBMC and Kodi for quite a long time and i'm sure im not the only one interested and affected by the old performances issues on SFTP remote sources.

As a personnal example, i frequently use a dedicated server that can push a little over 1Gbps on internet (filezilla, python simpleHTTPserver, nginx, rsync ...) to a client fiber that is also capable of receiving 1Gbps. Also the ping -seen on the client side- between the client and the dedicated server is typically around 13-16ms.

And when im browsing a BIG SFTP folder through Kodi (17.6, not tested 18.0 until now) on my Kodi "dedicated laptop" (win10 pro, i5 520m,, 8GB RAM and 1Gbps RJ45 network), Windows Task Manager network graph does not go over 8Mbps !

I think im not alone with this kind of problems -https://trac.kodi.tv/ticket/14038- (very low performance/usage relative to real capacity of the network and computers involved), there were numerous topics about HPN-SSH implementation for example ...

Now that there is an addon (independent of main app source code), could it be thinkable to look into solution for those kind of inefficiencies ? Or if the problems are already resolved, it would be a good -public- place to make it known loud and clear !

aluo-x commented 2 years ago

Performance on the latest Matrix 19.4 is still quite poor, I'm barely breaking 30MB/s on a 1Gbps capable network. On the same system using SSHFS-Win the speeds reach 90MB/s.

aluo-x commented 2 years ago

Tagging @AlwinEsch, not sure if there is any low hanging fruit in terms of optimization? I'm on Windows 10.

KyleSanderson commented 2 years ago

This is dog slow on a new firestick, and two other amlogic boxes. Running sshfs independently worked around the bug on those other boxes, but this is completely unusable on Android.

wonx commented 2 years ago

I can confirm this issue. On a 300mbps capable network, sftp transfer within kodi reaches 5-8mbps at most, nit enough to play HD videos. However, if I mount a folder using sshfs externally, the performance is more than 10 times faster. Sadly, on Android devices like a firetv stick, there's no option to externally add a sftp mountpoint.

sand-bit commented 2 years ago

Yeah, the sftp performance is pretty poor :(

seanmikhaels commented 1 year ago

Same issue on 20.2 using the VFS plugin. Not able to achieve anything over 20 megabits/s. Vanilla SSHFS using Debian on the same hardware target/ yields over 300 Megabits.

KyleSanderson commented 1 year ago

There's no prefetching which is the problem. They're not using the async API, and the video buffering code is just terrible.

so; latency + low throughput = bad news. It's very stupid and silly, but if you stream over http it'll improve the situation. The devs on a Shield use the native SMB functionality to the OS to work around the bug.

arnova commented 1 year ago

There's no prefetching which is the problem. They're not using the async API, and the video buffering code is just terrible.

so; latency + low throughput = bad news. It's very stupid and silly, but if you stream over http it'll improve the situation. The devs on a Shield use the native SMB functionality to the OS to work around the bug.

Why is the video buffering code "terrible" ? There's no argument to back that statement up (and I think it's not true either). It seems to work pretty well with other protocols, right?

seanmikhaels commented 1 year ago

There's no prefetching which is the problem. They're not using the async API, and the video buffering code is just terrible. so; latency + low throughput = bad news. It's very stupid and silly, but if you stream over http it'll improve the situation. The devs on a Shield use the native SMB functionality to the OS to work around the bug.

Why is the video buffering code "terrible" ? There's no argument to back that statement up (and I think it's not true either). It seems to work pretty well with other protocols, right?

Agreed here, does not seem to be effecting other protocols. UPNP, SMB, work seamlessly. HTTPS is an option, but when you're streaming over the internet, SSH is just such an easy and versatile protocol you can do so many things over a single port. Wonder what the effort would be to fix this.

KyleSanderson commented 1 year ago

There's no prefetching which is the problem. They're not using the async API, and the video buffering code is just terrible. so; latency + low throughput = bad news. It's very stupid and silly, but if you stream over http it'll improve the situation. The devs on a Shield use the native SMB functionality to the OS to work around the bug.

Why is the video buffering code "terrible" ? There's no argument to back that statement up (and I think it's not true either). It seems to work pretty well with other protocols, right?

Agreed here, does not seem to be effecting other protocols. UPNP, SMB, work seamlessly. HTTPS is an option, but when you're streaming over the internet, SSH is just such an easy and versatile protocol you can do so many things over a single port. Wonder what the effort would be to fix this.

Very small, just change the call-sites to async_read. Directory prefetching and caching will help with library import.

There's no prefetching which is the problem. They're not using the async API, and the video buffering code is just terrible. so; latency + low throughput = bad news. It's very stupid and silly, but if you stream over http it'll improve the situation. The devs on a Shield use the native SMB functionality to the OS to work around the bug.

Why is the video buffering code "terrible" ? There's no argument to back that statement up (and I think it's not true either). It seems to work pretty well with other protocols, right?

https://github.com/xbmc/xbmc/pull/22799 https://github.com/xbmc/xbmc/pull/22952 https://github.com/xbmc/xbmc/issues/21408 https://github.com/xbmc/xbmc/issues/22834

Not really sure where the breakdown here is.

Mynacol commented 5 months ago

I face the same issue, limiting download speeds (max. 30 Mbit/s) for links with ~20ms round trip time so I dug into it. This add-on essentially passes through the read call to libssh, which answers it blocking and synchronously. This means if Kodi requests a chunk of data, the request is passed to libssh -> the server and finally after the reply is received back to kodi. This means for each chunk one round trip time is spent waiting.

IDK if Kodi tries to use multiple threads, but this add-on uses a mutex on all reads, preventing such optimizations. Libssh says you shouldn't share sessions for thread safety, so this synchronization might be required. PR #114 tried to address this problem.

Besides this point I have two optimization ideas: 1. Increase the chunk size by implementing GetChunkSize to reduce the impact of the latency delay. The default seems to be 128KB. 2. Asynchronously read data. As Kodi doesn't seem to offer a native interface, we could add preloading in the add-on or use an even simpler approach: On each Read call (except the first) return the already preloaded chunk and start a new preload with sftp_async_read_begin(). This way the libssh library effectively preloads the next chunk before it is requested by Kodi. Care must be taken regarding the internal modification of the current offset and again thread safety.