hierynomus
commented
6 years ago @jansohn There is a new initiave from one of our core contributors to also add SMBv1 support to smbj. I don't know yet when that will be delivered, but it is coming.
Open jansohn opened 6 years ago
hierynomus
commented
6 years ago @jansohn There is a new initiave from one of our core contributors to also add SMBv1 support to smbj. I don't know yet when that will be delivered, but it is coming.
mbechler
commented
6 years ago Thanks for the benchmarks.
There definitely was a bug regarding the write buffer size with CAP_LARGE_WRITEX limiting that to 16k, that however does not affect the SMB2 buffer sizes (I get the expected ~64k).
Looking at the write behavior I think I see an general issue there: We still write the full input buffer which can lead to misalignment, e.g. a full 64k write results in two write requests of 64904 and 561 bytes sizes. This is not easily fixed with the OutputStream interface, but I guess we could add a method that reports back the optimal write size so that user code can do it right.
Not sure whether smbj currently uses multi-credit requests, which jcifs-ng currently has not implemented. That would likely allow pushing the throughput quite a bit further, however I also got the feeling that this does not mix well with the multiplexing on a single connection we have.
mbechler
commented
6 years ago Btw: I would suspect something being wrong with the smbj SMB2 (Upload 1 MB) numbers
3c71
commented
6 years ago From my own testing with jcifs-ng vs smbj, I found out smbj supports SMB 2.1, which allows for much bigger read/write buffers, while jcifs-ng only supports SMB2.0 (or I couldn't activate 2.1?).
I get twice the performance with smbj SMB2.1 (8MB/s) compared to jcifs-ng (4MB/s), be it with SMB1 or SMB2, both with large buffers. Still 5 times slower than a simple FTP (>40MB/s) protocol over the same network (WiFi 5G) between the same devices (Android and NetGear NAS)!
In my view, there's no particular bug, it's a protocol overhead/latency issue. There is so much going on when using SMB, performance gets very quickly impacted when network latency increases.
For example, considering a network with 50MB/s bandwidth, eg 20ms to send a 1MB buffer and 1.25ms to send a 64K buffer and 2 messages (COMMAND/RESPONSE) to receive a buffer:.
A 1ms latency, results in maximum throughput of 19MB/s using 64K buffers (SMB<=2.0) and 45MB/s using 1M buffers (SMB2.1).
Now, a 7ms latency results in 4MB/s on SMB<=2.0 and 29MB/s on SMB2.1.
It seems there are more messages in SMB, so the figures would get even worse.
hierynomus
commented
6 years ago Smbj does indeed support multi credit requests, but not compounding yet.
Op zo 30 sep. 2018 13:11 schreef 3C notifications@github.com:
From my own testing with jcifs-ng vs smbj, I found out smbj supports SMB 2.1, which allows for much bigger read/write buffers, while jcifs-ng only supports SMB2.0 (or I couldn't activate 2.1?).
I get twice the performance with smbj SMB2.1 (8MB/s) compared to jcifs-ng (4MB/s), be it with SMB1 or SMB2, both with large buffers. Still 5 times slower than a simple FTP (>40MB/s) protocol over the same network (WiFi 5G) between the same devices (Android and NetGear NAS)!
In my view, there's no particular bug, it's a protocol overhead/latency issue. There is so much going on when using SMB, performance gets very quickly impacted when network latency increases.
For example, considering a network with 50MB/s bandwidth, eg 20ms to send a 1MB buffer and 1.25ms to send a 64K buffer and 2 messages (COMMAND/RESPONSE) to receive a buffer:.
A 1ms latency, results in maximum throughput of 19MB/s using 64K buffers (SMB<=2.0) and 45MB/s using 1M buffers (SMB2.1).
Now, a 7ms latency results in 4MB/s on SMB<=2.0 and 29MB/s on SMB2.1.
It seems there are more messages in SMB, so the figures would get even worse.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AgNO3/jcifs-ng/issues/106#issuecomment-425713135, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHLo1JqoaGaroX_Eci2AYu6XeVoM5sVks5ugKbLgaJpZM4W8NtH .
jansohn
commented
6 years ago Btw: I would suspect something being wrong with the smbj SMB2 (Upload 1 MB) numbers
The upload numbers for smaller files with smbj indeed seem to be very low (and therefore fast). I'm always just measuring the while-copy-loop like this:
long time = System.nanoTime();
while ((len = is.read(buf)) > 0) {
os.write(buf, 0, len);
}
totaltime = System.nanoTime() - time;I just tested with the latest master and now SMB1 write speed is as expected!
I can also confirm that the fix did not affect SMB2 performance. I'm still curious though why there is such a big difference between read/write speeds with SMB2 (37 MB/s vs 28 MB/s). I don't think SMB2.0 vs SMB2.1 is the explanation in this case.
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ jcifs-ng SMB1 (Upload 1 KB) │
├───────────────────────┬───────────────────────┬───────────────────────┬───────────────────────┬──────────────────────┤
│0.001302724s │0.00127795s │0.001388015s │0.001277243s │0.001539486s │
├───────────────────────┴───────────────────────┴───────────────────────┴───────────────────────┴──────────────────────┤
│ jcifs-ng SMB1 (Download 1 KB) │
├───────────────────────┬───────────────────────┬───────────────────────┬───────────────────────┬──────────────────────┤
│0.002575366s │0.001165055s │0.001116216s │0.001242206s │0.001191952s │
├───────────────────────┴───────────────────────┴───────────────────────┴───────────────────────┴──────────────────────┤
│ jcifs-ng SMB1 (Upload 1 MB) │
├───────────────────────┬───────────────────────┬───────────────────────┬───────────────────────┬──────────────────────┤
│0.024149407s │0.024774757s │0.024708577s │0.024618331s │0.026830237s │
├───────────────────────┴───────────────────────┴───────────────────────┴───────────────────────┴──────────────────────┤
│ jcifs-ng SMB1 (Download 1 MB) │
├───────────────────────┬───────────────────────┬───────────────────────┬───────────────────────┬──────────────────────┤
│0.023415763s │0.023347459s │0.026191792s │0.026192146s │0.02485474s │
├───────────────────────┴───────────────────────┴───────────────────────┴───────────────────────┴──────────────────────┤
│ jcifs-ng SMB1 (Upload 100 MB) │
├───────────────────────┬───────────────────────┬───────────────────────┬───────────────────────┬──────────────────────┤
│2.264355621s │2.220328438s │2.356165624s │2.218068755s │2.292424171s │
├───────────────────────┴───────────────────────┴───────────────────────┴───────────────────────┴──────────────────────┤
│ jcifs-ng SMB1 (Download 100 MB) │
├───────────────────────┬───────────────────────┬───────────────────────┬───────────────────────┬──────────────────────┤
│2.133456115s │2.074735863s │2.070384956s │2.115985954s │2.064406795s │
├───────────────────────┴───────────────────────┴───────────────────────┴───────────────────────┴──────────────────────┤
│ jcifs-ng SMB1 (Upload 1 GB) │
├───────────────────────┬───────────────────────┬───────────────────────┬───────────────────────┬──────────────────────┤
│22.402391619s │23.167508488s │22.573993017s │23.405259664s │23.339227384s │
├───────────────────────┴───────────────────────┴───────────────────────┴───────────────────────┴──────────────────────┤
│ jcifs-ng SMB1 (Download 1 GB) │
├───────────────────────┬───────────────────────┬───────────────────────┬───────────────────────┬──────────────────────┤
│21.799407776s │21.96411263s │21.641193891s │21.651990467s │21.97879862s │
└───────────────────────┴───────────────────────┴───────────────────────┴───────────────────────┴──────────────────────┘@3c71 jcifs-ng by now even supports up to SMB 3.1 (need to configure that though), just not every feature that comes with each of the revisions. That includes 2.1's multi-credit feature that is required to increase the buffer sizes beyond 64k.
Maybe smbj is waiting for the data to be flushed, that could explain why the smaller uploads are so much faster than the downloads of the same size.
I'm too curious about the SMB2 upload performance (download is not consistently that much off). While I believe that 2.1/multi-credit should make a noticable difference, only seeing that bottleneck for uploads would be strange. And I don't believe that processing overhead can make that much of a difference either. Would be interesting to compare network traffic patterns.
3c71
commented
6 years ago @mbechler, I read it supports up-to 3.1, however when I set minimum to 2.1, it failed to connect. I'll try again but IMO it work up-to 2.0 (tested) at best.
In my tests, download only, smbj 2.1 was twice as fast than ng 2.0.
jansohn
commented
6 years ago @mbechler is there something I can do to help you analyze the problem?
master255
commented
5 years ago According to my calculations, the speed is lost twice. I tested via wifi 5G 300MBit. The transfer speed via http protocol 150MBIT, FTP is the same. Speed through jcifs-ng 55Mbit max. I changed all the data buffers to 2,000,000 bytes. Compiled library and it did not help. I tried to copy the file through windows computer and I had the same speed! So far I have not included in the register setting "Tcp1323Opts". As soon as I turned it on, the speed went up to 130MBIT. Perhaps, in this library, it must also be somehow included on the server side?
master255
commented
5 years ago Sorry. That's my fault. These settings did not affect the windows computer. Now I have removed them all, and the speed on windows 8.1 to windows 8.1 190MBit through 5g wifi. And jcifs-ng 55Mbit max. The real loss in speed is 3 times.
I'd like to switch from jcifs (with large read write patch) to another library with SMB2 support. I've decided to test
jcifs-ngandsmbj. I've compared the libraries against each other (see below for results) using equal buffer size (1MB) for all of them.The results vary quite a lot. Especially there seems to be an issue when uploading with
jcifs-ngfor both SMB1 and SMB2 connections. The negotiated file write size seems to be too low:Overall SMB2 seems to perform lower than SMB1 and
smbjachieves better results thanjcifs-ngwith SMB2 connections. Would be great ifjcifs-ngcould catch up tosmbjbecause I like the API better and I prefer having both SMB1 and SMB2/3 support in one library.Results: