[kio] [Bug 291835] KIO very slow when copying from network through smb

[Mark]

https://bugs.kde.org/show_bug.cgi?id=291835

--- Comment #44 from Mark <markg85 at gmail.com> ---
(In reply to oliver at openbrackets.net from comment #43)
> @Mark
> 
> one more thought...
> 
> if 1. above is OK, ie smbclient / smbc_read|write can support and FD
> streaming approach, then, eventhough we are getting rid of the problem of
> determining buffer size, is that going to solve the throughput issue?
> 
> I don't understand the problem in great detail yet, but it seems to me that
> because of the way the SMB protocol works, the way the libsmbclient API
> needs to be called and fed data, is quite critical, ref
> https://bugs.kde.org/show_bug.cgi?id=291835#c26 where wireshark forensics
> show that smbclient/cifs use clever strategy of pre-fetching "one block
> ahead" to get max throughput...
> 
> How can sendfile / splice ever understand these semantics?
> 
> Would we be getting rid of the "deciding what size buffer to use" problem,
> while failing to address the actual problem of achieving highly optimised
> throughput...?

For all your questions: i don't know :)

But i do know that sendfile/splice works marvelously on sockets. If i do an
iperf benchmark between my computer and my locak server i get around
990mbit/sec. That is very fast for a 1gbit connection. It's hitting the maximum
throughput, anything more is close to impossible due to TCP overhead.

Now if i use sendfile/splice to copy a file over the same network i get between
900 and 950 mbit/sec. Close enough for me :)

And that is with just those file descriptors and letting sendfile/splice handle
whatever they want to handle. I don't know how it internally does smart stuff,
but i do know it's blazingly fast.

If all of this works with samba around id.. We will just have to try it out i
guess.

-- 
You are receiving this mail because:
You are the assignee for the bug.