@jPV

Quote:

NetFS Revised pretty much does that already. You can mount remote shares whenever you want (for example at boot), and if the remote machine isn't on you get standard "no disk in drive" for the mounted device and no icon on the desktop, but when you start the remote machine, icon appears on the desktop and volume name is assigned for it and it's accessible without any user activity. And same way if you turn remote machine off, icon and volume name disappears, and the device is left to "no disk in drive" state.

Well almost. It lacks an easy installer or any installer and drives must be set up by hand. So a bit more fiddly than my idea. And it lacks native drivers for OS4 and AROS. I used the original NetFS in my 68K days. I don't know if it uses compression internally as I had an idea for that as well. After setup it would provide most of the functionality I was looking for. Thanks for the tip on the revised one. I'm sure I read about that somewhere.

@olsen

Quote:

First things first: in this test smbfs was about exactly as fast when doing read/write operations with the local "Windows 7" file server as when doing the same with the Samba 3.0.25 server connected via Ethernet. By rights the "Windows 7" system should have been much, much faster since the data would have been copied from/to memory inside the virtual machine. That isn't the case, which means that Samba is significantly faster than the "Windows 7" file server because data had to leave the virtual machine, travel across the wire to the Samba server, get processed there and return over the wire into the virtual machine.

Well this is interesting. Something is certainly up with that. Can a packet sniffer/debugger give any clue between the two? Such as average packet size and amount for the external server compared to TCP packets to the virtual machine?

Quote:

I also tested if write performance improves if smbfs is configured to use "raw write" commands instead of the normal "write" commands. The answer is no, because most of the time "raw write" requires two packets to be sent to the server, and that exchange causes a major performance hit. What works better is to let smbfs choose either the normal or the "raw" write command, depending upon how much data needs to be written. In so many words: write performance with Windows file server software is going to be poor for smbfs, probably until I can find a replacement set of read/write commands that make a difference. If you can, choose Samba.

Well it's always nice to let the software choose the best way to do something.

Quote:

Finally, I tested if it makes a difference to enable "write behind" mode for "raw write" commands. By default smbfs uses "write through" which requires that the Samba server (I only tested this with Samba; "Windows 7" does not offer "raw write" operations) concludes the entire write operation before reporting back to smbfs. Enabling "write behind" mode permits the file server to acknowledge the write operation immediately, carrying out the actual writing in the background. This is a bit risky because if a write error occurs, it will be reported by the server upon receipt of the next command, and by then the error could be out of context. Anyway, in my tests I found that enabling "write behind" mode for "raw write" commands would yield an improvement of about 10%, which isn't much, but it might make a difference on 10 MBit/s Ethernet.

Well I suppose a tenth increase in performance doesn't seem like much but it could be a nice little increase.

@Hypex

Quote:

Thanks for the tip on the revised one. I'm sure I read about that somewhere.

The revised one is really nice compared to the original one. Simple password protection and easy configuration file instead of using clumsy .nomount files for access control, speed is much better, that "dynamic" mounting, etc.

If you have some ideas for it, author is willing to improve it even further.

_________________
- The wiki based MorphOS Library - Your starting point for MorphOS
- Software made by jPV^RNO

@Hypex

Quote:

Hypex wrote: @olsen Quote: First things first: in this test smbfs was about exactly as fast when doing read/write operations with the local "Windows 7" file server as when doing the same with the Samba 3.0.25 server connected via Ethernet. By rights the "Windows 7" system should have been much, much faster since the data would have been copied from/to memory inside the virtual machine. That isn't the case, which means that Samba is significantly faster than the "Windows 7" file server because data had to leave the virtual machine, travel across the wire to the Samba server, get processed there and return over the wire into the virtual machine. Well this is interesting. Something is certainly up with that. Can a packet sniffer/debugger give any clue between the two? Such as average packet size and amount for the external server compared to TCP packets to the virtual machine

What happens here is quite straightforward: the "Windows 7" file server does not support the more efficient raw read/wite commands and limits the message size to 4356 bytes. This is possibly the worst combination of options for smbfs to work with in terms of performance.

I found out about these options through the SMB message decoder which I wrote and then bolted onto smbfs before I began to update the file system. It's sad to see how little "Windows 7" does with the means available, compared to Samba.

Samba does support the raw read/write commands and the maximum message size is in fact the highest value possible under the rules of the SMB file sharing protocol (65535 bytes). Combining these options allows smbfs to spend a minimum of effort on protocol overhead, as opposed to "Window 7" which requires as many as 30 packets to be sent/received to transmit what Samba can cover with merely three packets.

Last edited by olsen on 27-Apr-2016 at 02:47 PM.
Last edited by olsen on 27-Apr-2016 at 01:01 PM.

@olsen

I take it that one cannot change these limits by changing values through Windows "Powershell" (see Get-SmbClientConfiguration)?

@olsen

Quote:

What happens here is quite straightforward: the "Windows 7" file server does not support the more efficient raw read/wite commands and limits the message size to 4356 bytes. This is possibly the worst combination of options for smbfs to work with in terms of performance.

Certainly looks like a double banger on the performance there.

Quote:

I found out about these options through the SMB message decoder which I wrote and then bolted onto smbfs before I began to update the file system. It's sad to see how little "Windows 7" does with the means available, compared to Samba.

I was at my Amiga club committee meeting tonight and brought this up at the end. The answer I got was that Windows had to limit the packet size (to about 4K) because it may have to deal with simultaneous network traffic accessing the drives and so has to limit packet size to deal with any bottle necks. And ensure QoS.

Well to me it sounded like a ToS. And that Windows didn't adjust it to account for client size or the pool size of clients using the networked drives. Or so I thought.

Last edited by Hypex on 28-Apr-2016 at 03:51 PM.

@Raziel

Quote:

Raziel wrote: @olsen I take it that one cannot change these limits by changing values through Windows "Powershell" (see Get-SmbClientConfiguration)?

It's possible, I'm just not enough of a Windows user to know about such technical aspects.

However, it says in the Microsoft "Common Internet File System (CIFS) protocol" documentation that the maximum buffer size can be configured through the registry setting "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SizReqBuf".

Please note that this setting is mentioned in the context of Windows NT Server. The current SMB file server implementation may no longer support it.

@Hypex

Quote:

Hypex wrote: @olsen Quote: I found out about these options through the SMB message decoder which I wrote and then bolted onto smbfs before I began to update the file system. It's sad to see how little "Windows 7" does with the means available, compared to Samba. I was at my Amiga club committee meeting tonight and brought this up at the end. The answer I got was that Windows had to limit the packet size (to about 4K) because it may have to deal with simultaneous network traffic accessing the drives and so has to limit packet size to deal with any bottle necks. And ensure QoS. Well to me it sounded like a ToS. And that Windows didn't adjust it to account for client size or the pool size of clients using the networked drives. Or so I thought.

I reckon that this is a limitation of the file server implementation of the time. Or maybe it was reimplemented and the authors used the existing documentation to make it behave like it used to.

It says in the Microsoft "Common Internet File System (CIFS) protocol" documentation that the default maximum buffer size on Windows NT Server is 4356 bytes (4 KBytes + 260 bytes) if the server has 512 MBytes of memory or less. If it has more than 512 MBytes of memory, the default is 16644 (16 KBytes + 260 bytes).

I expect that your Windows machine today may have much more than 512 MBytes of memory installed (perhaps 8-64 times as much), which makes this modest buffer size all the more puzzling.

But then maybe this is just to show that architectural differences matter. Samba can "burn" 65535 bytes of memory and work very well with that, on a more than 10 year old laptop running BSD Unix. "Windows 7" sticks to the rules and limitations of old and fails to perform even close to the older machine with Samba installed.

@olsen

Nice hint, thanks

I just did a quick test and it doesn't change anything speed-wise adding this parameter to windows. As you said it's either not used/supported in samba anymore or Windows10 doesn't pick it up.