Small operation performance regression #4
Comments
|
|
Try with CACHE=1024 in your smbfs line. (That will set the "Buffers" to 1024 and you'll get your i/o speed back) v2.1 uses all the bandwidth it can get and i found that this setting is a very good compromise between wasting cache space and speed gain. The speed went down for me too while testing the different version, but that is because smbfs2.1 is using far more complex i/o operations (and error proof) than 1.74. DiskSpeed 4.4, OS4 version CPU: 68020 AmigaOS Version: 53.89 Normal Video DMA Testing directory manipulation speed. Seek/Read: 1591 seeks/sec Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer. Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer. Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer. Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer. |
|
What are your results with standard CACHE settings? |
|
hehe, they are actually faster, guess i was wrong;-) DiskSpeed 4.4, OS4 version CPU: 68020 AmigaOS Version: 53.89 Normal Video DMA Testing directory manipulation speed. Seek/Read: 1866 seeks/sec Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer. Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer. Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer. Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer. |
|
Yes, it seems it does not help, "Directory Scan" is twice as fast, but otherwise more or less the same - comparison between std and CACHE=1024: |
|
I'm not sure about the real life potential of those benchmark figures anyway. I did a lot of speed comparision with diskspeed 1.3 and 4.4 ( to have another program for cross comparision) during development and there were two significant speed jumps. The first was when Olaf introduced a new and polished i/o access method with the (now fixed) correct access and error handling and the second one when my hardware developer rolled out a new firmware for the NAS device. So, it's depending on more factors than only smbfs, i believe. I know that you checked the same line with 1.74 and 2.1, so something is draining your access rate, what that is i can only imagine. Then again, did you check with "real life" tests? I did that too extensively during development by copying a dir with lots of .flac files from the nas to ram: and back to the nas while measuring the time. I post the figures, but it's not to be taken for any comparision for other hardware, because while i did those testing a lot of stuff changed (firmware, cables etc.)...but as you can see the speed isn't really going up or down. I get 6.5 MBit max from my LAN based Amiga hardware Plus, it's not all about speed, i'd rather have an error prone and (i/o) secure smbfs i can work with than something really fast that trashes my data. 1.74 1.160 1.170 1.181 2.1 |
|
I have no complaint with say the top read speed with large buffers. The A3000 I tested on with its 030@25MHz manages just under 700kB/sec of raw TCP receive and this result is not far from that. What I find interesting with most of the small operation tests with smbfs 2.1 is that there is a very high CPU availabilty percentage, indicating that during those tests the Amiga is mostly spending time waiting and adding a really fast CPU would not make a difference - which explains why I got no better score at those test when I tested on my A1200 with 060@50Mhz. To get some real life comparison, I did a test with smbfs 1.74 and 2.1 copying a collection of files (~4.3MB with mixed file sizes, but a lot of small ones). With smbfs 2.1, more than 4 times the time was required to copy to the SMBFS: volume compared to 1.74 and more than 2.5 times was required to copy from the SMBFS: volume: |
|
I have an idea on what may be responsible for the small-sized read/write operations having taken a performance hit. One of the changes in smbfs 2.1 was to reduce the amount of unnecessary data copying to/from memory, as well as trying to limit unnecessary path name comparisons and length recalculations. To this effect the file read/write operations were broken up into two subsequent read and write operations, respectively, rather than receiving a single lump of data/combining data into a single lump. This saves at least one big memory copying operation, but it has side-effects. These side-effects turned out to be complex and subtle at the same time, because depending upon volume and throughput, the TCP/IP stack may not choose to send small amounts of data just yet, and an internal timeout has to elapse before this data is finally transmitted. This may explain why there is less CPU load involved than in version 1.74, for example. To get an idea of the impact of these side-effects, smbfs 2.8 adds the READTHRESHOLD and WRITETHRESHOLD options. Both settings default to 0, but it may be interesting to know if values of 1000-1500, or higher, will improve performance for the small-size read/write operations. |
|
I was searching high and low for those options until i realized 2.8 is an upcoming version :-) |
|
Did some tests with the 2.11 version, but cut down on the variables by limiting the test to 512B create/write/read. 1.74 baseline: 2.11 with no extra options: These results are consistent with 2.1. 2.11 with several WRITETHRESHOLD and READTHRESHOLD combinations: Neither WRITETHRESHOLD or READTHRESHOLD affects the results of this test. 2.11 with TCPNODELAY option: TCPNODELAY does not affect the results for this test. 2.11 with SCATTHERGATHER=yes: SCATTERGATHER=yes gives a huge improvement. Still not at 1.74 levels, but a huge improvement from 1/10 to 1/2 of the 1.74 performance. |
|
Did a run of the earlier real-life example copy-test with the new 2.11 options 1.74 baseline: 2.11 with all the options from the previous comment: The only option which made a difference here, as in the previous test with diskspeed, was the SCATTERGATHER=yes option. However, the improvement was quite small (~4%). |
|
With SMBFS 2.12: |
When upgrading from the old SMBFS 1.74 to the current 2.1 version, I ran diskspeed on both to see if anything had changed. Noticed that the ratings for small create and open file had dropped significantly.
Some examples: 50 -> 9 create file/sec, 147 -> 19 open file/sec, 102720Bytes/sec -> 9488Bytes/sec create file with 512B block.
An interesting detail is that for the ratings that has regressed, the CPU % availability is very high for 2.1, so it is not an inefficiency, but it seems like in those cases, the Amiga is spending most of the time idle, waiting for something to happen.
Tests results in issue are from an A3000-030@25MHz, X-Surf-100 and Roadshow 1.13 against a Debian 9.5 server with Samba 4.5.12. Also tested on an A2000-030@40MHz, A2065 and Roadshow 1.13 where I the issue could be replicated.
Test result where SMBFS 1.74 is run first, then 2.1:
The text was updated successfully, but these errors were encountered: