Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Questions and Answers for AMIGA Workbench or Coffin

ATTN CoffinOS Guys, the SMBFS On R51 Is Buggy/oldpage  1 2 3 

Niclas A
(Apollo Team Member)
Posts 219
22 Apr 2018 18:34


Renaud Schweingruber wrote:

  I did nothing, I just compiled it from available sources. Seems binaries have never been available until today.
 
  ChangeLog is missing since 1.106 :
 

 
 

smbfs 1.103 (14.4.2016)

- Added DUMPSMBLEVEL option which controls how much raw
  data output is produced. By default (level 0) no raw
  data output is produced at all. Level 1 will print the
  contents of the command data area. Level 2 will print
  the raw data used by the respective commands, with any
  management/control information stripped off.

smbfs 1.104 (16.4.2016)

- For smb_request_write_raw() return values of 0 now indicate success.

- Simplified the raw read portion of smba_read() by removing the test
  that avoids dropping into a read loop below. The loop handles the
  special case well.
 
- Recalculated the overhead for SMB_COM_READ. It's still 52 bytes,
  but now the documentation states how this number comes about.
 
- Recalculated the overhead for SMB_COM_WRITE. It's 52 bytes and
  not 56 bytes.

- Recalculated the overhead for the SMB_COM_WRITE_RAW command, and
  it's 63 bytes, not 4.

- Unless smb_proc_write_raw() finds that sending the packet results
  in a transmission error, it will try to pick up the server responses.
  Previously, it would not even try that, which could deadlock the
  client<->server message exchange.

smbfs 1.105 (16.4.2016)

- Fixed decoding of maximum buffer size; this used to come out
  as 0, which made smbfs switch back to the default minimum
  supported (1024 bytes).

- Corrected use of the maximum raw write size as the size used
  by the client to perform raw reads with. The maximum allowed
  are 65535 bytes for a raw read request. Likewise, the
  maximum raw write size is 65535 bytes, too.

smbfs 1.106 (17.4.2016)

- More detailed error class/code translation information now
  shows up in the debug log.

- The SMB dump output can now be stored in a file, rather than
  having to be redirected to one. When storing it in a file,
  the output will be appended to an existing file, otherwise
  a new file will be created.

- The raw read/write functions now respect the upper limit
  for the amount of data to be written, as given by the server.

smbfs 1.107 (20.4.2016)

- Added WRITEBEHIND and PREFERWRITERAW options. WRITEBEHIND will
  allow SMB_COM_WRITE_RAW commands to complete asynchronously.
  PREFERWRITERAW will make the file system use SMB_COM_WRITE_RAW
  over SMB_COM_WRITE when it has a choice.

smbfs 1.108 (23.4.2016)

- Now properly handles the error code returned when Samba
  is asked to remove a non-empty directory. The error is
  translated to ENOTEMPTY.

smbfs 1.109 (23.4.2016)

- Activated the PREFERWRITERAW option which had not been wired
  up yet. Oops :-(  Turns out that with this option enabled
  write operations are indeed slower than the with the
  adaptive SMB_COM_WRITE/SMB_COM_WRITE_RAW code, on account that
  that SMB_COM_WRITE_RAW transmits the data in two packets, plus
  overhead for the server response.

- Recalculated the threshold below which a write operation will
  be performed using SMB_COM_WRITE instead of SMB_COM_WRITE_RAW.

- Fixed how the WRITEBEHIND option for the SMB_COM_WRITE_RAW
  command is implemented: the client must not wait for the
  server to acknowledge the command.

- Investigated the performance difference between SMB_COM_WRITE_RAW
  using the "write behind" and "write through" modes. In my tests
  the difference came down to about 10% performance gain for
  the "write behind" mode.

- Compared the performance of plain SMB_COM_WRITE (Windows 7) and
  the adaptive SMB_COM_WRITE/SMB_COM_WRITE_RAW (Samba 3.0.25).
  The adaptive SMB_COM_WRITE/SMB_COM_WRITE_RAW is about as fast
  as the plain SMB_COM_WRITE, with "Windows 7" running on the
  same machine as WinUAE (with AmigaOS 3.9) and Samba running
  on a local server connected via GBit Ethernet. This means that
  SMB_COM_WRITE is significantly slower with Windows 7.

smbfs 1.110 (1.5.2016)

- Added the DEBUGFILE/K option. Not everybody has Sashimi or
  a tool like it running in the background, which makes sharing
  file system level debug information difficult.

smbfs 1.111 (11.5.2016)

- You can now identify smbfs by checking the DosList->dol_misc.dol_volume.dol_DiskType
  field. It will read back as 0x534D4200, which is equivalent to the signature
  "SMB\0". This change was suggested by Chris Handley and Chris Young.
  Thank you very much!

smbfs 1.112 (26.9.2016)

- The negotiation in smb_proc_reconnect() picked up the server's
  maximum buffer size and then always added 4 bytes on top of it.
  From the looks of it, this was intended to account for the
  4 byte NetBIOS session header to be prepended to each SMB
  command block. In practice it could push the size of a
  write operation beyond what the server would accept.

smbfs 1.113 (29.9.2016)

- Removed the SMB_HEADER_LEN constant, since it wasn't actually referring to the
  length of the SMB header, but the NetBIOS session header plus the SMB header.
  This led to some confusion as to what exactly the packet byte offsets used by
  "proc.c" would reference.

- "proc.c" now lists the byte offset values into the packet buffer, so as
  to make it clearer what exactly is being referenced.

- smb_valid_packet() now correctly displays the expected and actual
  packet size.

- smb_setup_header() no longer includes the NetBIOS session header
  in the total message length calculation. Which means that smbfs
  no longer sends packets with a NetBIOS header which claims that
  the messages should be longer than they actually are.

- smb_proc_write_raw() no longer cares about the number of
  command words, but only about the number of data bytes and
  the command, when waiting for a raw write operation to
  conclude.

smbfs 1.114 (1.10.2016)

- The packet buffer size is now increased during the protocol
  negotiation, if the default buffer size proves to be too
  small. This avoids trouble with the MAXTRANSMIT option,
  which used to leave the original packet buffer size
  unchanged, and too short.

- The raw write operation no longer stumbles into a 0 length
  write, which the server would not expect and not respond to.

- Moved the test for the "write behind" option in the
  raw write operation so that it is handled before the
  server response (which hasn't arrived yet) is checked.

- Verified that the raw write operation can deal properly
  with the server response (interim update and write
  completion).

smbfs 1.115 (2.10.2016)

- The MAXTRANSMIT option controls how much data smbfs is
  prepared to receive. That value cannot be smaller than
  8000 bytes, and it cannot be larger than 65535. The
  code which sets up this parameter and verifies that it
  is in range is now implemented only once, and not
  twice in different places.

- The MAXTRANSMIT option also controls how much data
  smbfs may send to the server. This limit is no longer
  capped at 65535 bytes.

- The size of the message reception/transmission buffer
  can no longer be smaller than 8000 bytes and it cannot
  be smaller than the number of bytes which may be sent
  to the server.

smbfs 1.116 (3.10.2016)

- smb_receive_trans2() now verifies that the amount of
  data received is not larger than the maximum acceptable
  by the client. Previously, it compared the amount of
  data received against the server's upper limit. Ouch :-(

- smba_readdir() now stops immediately if no directory
  entries are supplied. Previously, it could deliver
  a bogus directory entry to the scanning function.

- The number of directory entries accepted by smb_proc_readdir_short()
  is now calculated according to how much data the client will
  accept, and not according to the server's limit.

- smb_proc_readdir_long() now reports how much data the
  client will accept, rather than how much the server will
  accept. This was problematic because that number is a
  16 bit value, and the server's maximum transmission
  value could be larger than 65535 bytes, causing directory
  scanning to fail because the truncated 16 bit value
  could be too tiny to report even a single result.
 


 


Renaud Schweingruber
(Apollo Team Member)
Posts 378
22 Apr 2018 19:08


nice find !


Mo Retro

Posts 241
22 Apr 2018 19:31


Thanks Nicolas :)

smbfs 1.115 (2.10.2016)

- The MAXTRANSMIT option controls how much data smbfs is
  prepared to receive. That value cannot be smaller than
  8000 bytes, and it cannot be larger than 65535. The
  code which sets up this parameter and verifies that it
  is in range is now implemented only once, and not
  twice in different places.

- The MAXTRANSMIT option also controls how much data
  smbfs may send to the server. This limit is no longer
  capped at 65535 bytes.

I wonder if that MAXTRANSMIT option could have impact on my upload speed.
Where can I manage this?


Eric Gus

Posts 477
23 Apr 2018 00:05


Ill give 1.116 a try and see how it goes..

For what its worth my home NAS runs on linux/OpenMediaVault .. I dont know if different NAS servers work slightly differently (I presume as much).. some may be more particular than others..


Shane Stringer

Posts 22
23 Apr 2018 00:40


I am also accessing an OpenMediaVault share...


Eric Gus

Posts 477
23 Apr 2018 05:24


smbfs 1.116  does not work either for UPLOADING to an SMB server
    (well to my smb server) ..
   
    the original version works 1.74 .. 1.116 does not..
   
    I tested both, I renamed the 1.74 version, installed the 1.116 version, tried .. it locked up just like the 1.102 version did .. reverted back to 1.74, works..
 
  As with 1.102 .. it looks like it partially works ( I get incomplete uploads .. which end in a hang of the application I am using to test with and the file only partially uploaded to the SMB server .. DirOpus, workbench ,etc).. only way to recover is to CTL-A-A or power off/on.
 


Mo Retro

Posts 241
23 Apr 2018 11:47


Eric & Shane what's the upload & download speed you're getting with smbfs 1.74?


Shane Stringer

Posts 22
23 Apr 2018 12:53


With a 10Meg test file on a SMB share, using smbfs 1.74:
D/L: 21.36 sec = 479.4 KB/s
U/L: 39.92 sec = 259.77 KB/s

Note: with smbfs 1.116, the same download takes 22.34 sec


Mo Retro

Posts 241
23 Apr 2018 18:21


Shane Stringer wrote:

With a 10Meg test file on a SMB share, using smbfs 1.74:
  D/L: 21.36 sec = 479.4 KB/s
  U/L: 39.92 sec = 259.77 KB/s
 
  Note: with smbfs 1.116, the same download takes 22.34 sec

These are high numbers for the 1.74. I have around 300kB/s download and around 70kB/s upload.
My upload rate stays low on the 1.102 and 1.116 version, around 75kB/s
Download is higher in the newer versions, I get around 580kB/s with version 1.116

So my problem is the poor upload rate :)

These are numbers I get on my A500 V2+.


Niclas A
(Apollo Team Member)
Posts 219
23 Apr 2018 18:48


EXTERNAL LINK 

smbfs 1.117 (11.4.2018)

- Looks like the SMB_COM_WRITE_RAW implementation is really as simple
  as the documentation suggested. Just two packets need to be sent to
  to the server.




Renaud Schweingruber
(Apollo Team Member)
Posts 378
23 Apr 2018 21:56


Compiled :
EXTERNAL LINK


Henryk Richter
(Apollo Team Member)
Posts 128/ 1
23 Apr 2018 22:21


Mo Retro wrote:

  These are high numbers for the 1.74. I have around 300kB/s download and around 70kB/s upload.
  My upload rate stays low on the 1.102 and 1.116 version, around 75kB/s

I might have some insight to this upload performance issue. It's called Delayed ACK in TCP. Modern IP-Stacks send data all the time and expect that TCP segment acknowledgement might come late. On Amiga, most IP Stacks (notable exception: RoadShow) will wait for the actual ACK before sending data again.

This is a behaviour of the remote machine which must be circumvented there. Examples:

OSX (commandline): sysctl -w net.inet.tcp.delayed_ack=0

Linux (Samba smb.conf): socket options = TCP_NODELAY

Windows (not tested by me on recent versions, Registry):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces

find your LAN interface there and add the following keys:
TcpAckFrequency=1 (DWORD32)
TCPNoDelay=1 (DWORD32)


Shane Stringer

Posts 22
24 Apr 2018 00:59


I did have "socket options = TCP_NODELAY IPTOS_LOWDELAY" in my NAS smb.conf file; maybe that's why my upload speed was higher on 1.74

1.117 locks up after transferring 16640 bytes, instead of 32786 bytes with the earlier versions.


Eric Gus

Posts 477
24 Apr 2018 01:34


Mo Retro wrote:

Eric & Shane what's the upload & download speed you're getting with smbfs 1.74?

Can't really test upload speed when it locks the entire thing up..  :-/




Eric Gus

Posts 477
24 Apr 2018 01:37


What tool are you guys using to bench download/upload speeds?


Shane Stringer

Posts 22
24 Apr 2018 02:35


I used the 'time' program from shelltools, available on Aminet, which I would link to if Aminet was working.  It's a port of the linux 'time' utility.


Eric Gus

Posts 477
24 Apr 2018 07:40


Shane Stringer wrote:

I used the 'time' program from shelltools, available on Aminet, which I would link to if Aminet was working.  It's a port of the linux 'time' utility.

Yea I use that at work .. I will try to grab it when Aminet isnt suffering from a bout of severe depression..


Renaud Schweingruber
(Apollo Team Member)
Posts 378
24 Apr 2018 20:59


c:timeme is also useful


Mo Retro

Posts 241
24 Apr 2018 21:06


Henryk Richter wrote:

  I might have some insight to this upload performance issue. It's called Delayed ACK in TCP. Modern IP-Stacks send data all the time and expect that TCP segment acknowledgement might come late. On Amiga, most IP Stacks (notable exception: RoadShow) will wait for the actual ACK before sending data again.
 
  This is a behaviour of the remote machine which must be circumvented there. Examples:
 
  OSX (commandline): sysctl -w net.inet.tcp.delayed_ack=0
 
  Linux (Samba smb.conf): socket options = TCP_NODELAY
 
  Windows (not tested by me on recent versions, Registry):
 
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces
 
  find your LAN interface there and add the following keys:
  TcpAckFrequency=1 (DWORD32)
  TCPNoDelay=1 (DWORD32)

Thanks for the elaboration on this issue Henryk.
I'm away now, I'll test it when I'm back home in a couple of days.



Mo Retro

Posts 241
24 Apr 2018 21:08


eric gus wrote:

Mo Retro wrote:

  Eric & Shane what's the upload & download speed you're getting with smbfs 1.74?
 

 
  Can't really test upload speed when it locks the entire thing up..  :-/
 

  Eric I thought 1.74 was working for you?



posts 58page  1 2 3