OMAP4 network test

Doug.

Thanks for testing. It shows how much wifi slows things down but at least you can connect. You probably also find that repeating the test gives varying results. As a matter of interest is the server also on wifi ie is your connection pi – wifi – router – wifi -laptop?

Jeffrey.

Excellent! The slower windows7 results is because windows no longer supports raw transfer mode – apparently its been deprecated for ages – so single smb commands are limited to 3 full packets instead of the 10 lanman uses in raw mode. With windows XP, which uses raw, mode you get a similar performance to lanman → linux – probably because the linux server is configured to use raw mode.

sharefs seems to have a 4MB/s limit

I think 40/56bit mode in windows is for the ‘client’ to use version 1 encryption and 128bit version 2 encryption. I think servers accept passwords depending on policy. I’ve implemented LMv2 encryption – the bits required were in various rfc’s.

Have you tried backslashes this is a windows protocol after all. Sources imply users\public should work but I’ve not tried it.

Yeah, I tried backslashes (I think!)

Colin,

Yes the both LaPi and Windows machines are served via wi-fi.

Doing multiple tests do show some variance but always LanMan98’s read speed is about a 30%-35% of it’s write speed.

I have tested your new rom against the 17-Feb-2015 rom on a Pi model 2:

RISCOSmark 1.01 (14 May 2003)
Comparison with RiscPC SA 202MHz running RISC OS 4.02 800x600,256
(HD benchmarks are in kilobytes/sec)

Pi model 2
LANMANfs / 8Tbyte NAS/ new rom
HD Read - Block load 8MB file                               8623     289%
HD Write - Block save 8MB file                              5936     195%
FS Read - Byte stream file in                                458     221%
FS Write - Byte stream file out                              401     208%

SHAREfs / VRPC / new rom
HD Read - Block load 8MB file                               2864      96%
HD Write - Block save 8MB file                              4628     152%
FS Read - Byte stream file in                                101      48%
FS Write - Byte stream file out                               51      26%

LANMAN98fs / 8Tbyte NAS / new rom
HD Read - Block load 8MB file                               9362     313%
HD Write - Block save 8MB file                              7314     240%
FS Read - Byte stream file in                                443     214%
FS Write - Byte stream file out                              256     133%

LANMANfs / 1Tbyte NAS/ RISC OS 5.21 (17-Feb-2015)
HD Read - Block load 8MB file                               3126     104%
HD Write - Block save 8MB file                              3706     121%
FS Read - Byte stream file in                                 50      24%
FS Write - Byte stream file out                               50      26%

SHAREfs / VRPC / RISC OS 5.21 (17-Feb-2015)
HD Read - Block load 8MB file                               2834      95%
HD Write - Block save 8MB file                              1692      55%
FS Read - Byte stream file in                                101      48%
FS Write - Byte stream file out                               51      26%

LANMAN98fs / 8Tbyte NAS /RISC OS 5.21 (17-Feb-2015)
HD Read - Block load 8MB file                               9002     301%
HD Write - Block save 8MB file                              6714     220%
FS Read - Byte stream file in                                451     217%
FS Write - Byte stream file out                              263     136%

Pi model 1 B+
LANMANfs / 8Tbyte NAS/ new rom
HD Read - Block load 8MB file                               6942     232%
HD Write - Block save 8MB file                              4404     144%
FS Read - Byte stream file in                                480     231%
FS Write - Byte stream file out                              453     235%

SHAREfs / VRPC / new rom
HD Read - Block load 8MB file                               2659      89%
HD Write - Block save 8MB file                              4096     134%
FS Read - Byte stream file in                                 93      44%
FS Write - Byte stream file out                               37      19%

LANMAN98fs / 8Tbyte NAS / new rom
HD Read - Block load 8MB file                               7447     249%
HD Write - Block save 8MB file                              4905     161%
FS Read - Byte stream file in                                484     233%
FS Write - Byte stream file out                              256     133%

With the 17-Feb-2015 rom, LANMANfs won’t authenticate with my 8Tbyte NAS but LANMAN98 will.

Jeffrey.

You can’t do what you want. LanMan’s ‘Directory path’ should be called ‘Share name’. the connection is made to \\server\sharename. Just to confirm that a path doesn’t work Lanman sends backslashes in the sharename – but limits the sharename to 15 characters so I tested a Directory Path of ‘temp\piboot’ which tries to connect to \\server\temp\piboot and it doesn’t work. I know that that is what was sent because I can see it on the server machine using wireshark.

So you would need to create a share of your public folder to connect directly to it.

Is it possible to expand the share name? The Livebox buries USB shares in a folder structure.

Thanks Chris. I think your slow sharefs read speeds are down to VRPC. I’ve found read speeds are normally similar to write speeds – does it have ‘*sharefswindow 1’ on it? You can see by typing *sharefswindow. The pi2 performance is interesting – the fastest etherusb performance I’ve seen I think.

Overall it looks a worthwhile improvement.

Is it possible to expand the share name?

I would find that handy too. I have a NAS with two shares. All the other clients I have can access the shares I want; with LM98 I have to connect one level higher and then enter the correct share folder from there.

Not a show stopper, of course, but it would be handy.

They aren’t strictly shares they are folders in shares. Connection to a share is made via SMB_COM_TREE_CONNECT – see [MS-CIFS].pdf page 293. This just connects to shares.

Interesting Dave – I didn’t fancy wading through the other 784 pages of the spec to find out :-)

Interesting. Apart from the statement that SMB_COM_TREE_CONNECT is deprecated, the document refers to a path “that represents the server and share name of the resource to which the client is attempting to connect”. I read that as being a complete path. Presumably you’ve read something somewhere that states otherwise?

Presumably you’ve read something somewhere that states otherwise?

No but I have tried it. At the moment sharename is limited to 15 characters but LanMan allows you to use a \ in it so on server ‘pluto’ I have a share called ‘temp’ containing a folder called piboot so using temp\piboot as the directory path fails. Analysing what happened with wireshark on the server machine. Lanman tried to open

\\pluto\temp\piboot

and the server responded with ‘Error: Requested share does not exist’.

Apart from the statement that SMB_COM_TREE_CONNECT is deprecated.

A lot of commands in LanManFS are deprecated. Raw read and Writes for example. The latter are now no longer supported by windows – which is why newer versions of windows are slower. I read that even Samba on linux don’t allow raw reads and writes by default – though Jeffreys tests would suggest that his linux server has them enabled.

The comments about sharenames and paths are interesting. I went with LanMan98 years ago because I could never get omni/lanman to connect to anything. While doing some of Colin’s tests over the last couple of days, I did actually manage to get my Iyonix and RaPi to connect to a NAS, by playing with share names and paths. I did end up with a shortened version of sharename and path. I still cannot get the PandaRO to connect using LanMan even using the exact same connection details. I will investigate that further.

At the moment sharename is limited to 15 characters

That sound suspiciously like the NETBIOS limit, are you using SMB over NBT by any chance?

I have lmtransport configured to IP so it’s using the NBIP back end.

Chris. I don’t remember sending you an Iyonix rom with encrypted authentication. Is the pi that you connected with using ROOL’s rom? The ROOL LanMan uses unencrypted passwords and it may be that your nas accepts them but not the encrypted version.

@Colin: The RaPi ROM I was using was your ROM of 6th April – I assumed that had all your recent changes. The Iyonix was ROOL’s ROM from mid March, and the Panda was using your ROM of (I think) 3rd April.

In that case it looks like your nas accepts both encrypted and unencrypted passwords – which isn’t unusual XP does that too. So something else must be going wrong.

You said earlier

I did end up with a shortened version of sharename and path

Just to clarify, In the ‘Directory Path’ field in LanManFS you only put the share name which contains no backslashes – there is no path. It shouldn’t be case sensitive.

does it have ‘*sharefswindow 1’ on it?

Yes

Is the pi that you connected with using ROOL’s rom?

The second part was a question for Chris Johnson :-)

You shouldn’t need to use the sharefswindow 1 command with my roms. The default is sharefswindow 2 if you want to temporarily try it.

on server ‘pluto’ I have a share called ‘temp’ containing a folder called piboot

Lanman tried to open

\\pluto\temp\piboot

and the server responded with ‘Error: Requested share does not exist’.

Quite right. The share is “temp” on “\\pluto” so the UNC is \\pluto\temp in which you find your directory “piboot”

If you had another directory shared out alongside “temp” as “temp2” connecting to “temp” would not allow you to shift down into the root and then up into temp2.

Just to clarify, In the ‘Directory Path’ field in LanManFS you only put the share name which contains no backslashes – there is no path. It shouldn’t be case sensitive.

Note your problem Colin but that “Directory Path” really ought to read “Share Name” or “ShareName”

Interestingly now that I don’t need sharefswindow 1 just to get sharefs to work I can use it to tune the performance and *sharefswindow 8 on all devices seems to be optimum. The best results I got was 5.99MB/s read and 5.5MB/s write from a pi B+ to a pandaboard compared to 4.6MB/s read 3.79MB/s write with *sharefswindow 2

OK. After upgrading the PandaRO with the latest nightly hard disc image (!Boot and Apps – Omni etc) and a reboot, I now have LanManFS working also on the Panda. No idea why the Panda was behaving differently to the Iyo and RaPi before.

Colin’s speed test app using LanManFS to the NAS now gives about 4.2 MB/s write and 6.8 MB/s read, which is on a par with the results I was getting with LanMan98 before, so things are looking good.

On Colin’s other point, I had already put the sharefswindow setting back to the default 2 on all the machines (Iyo, PB, RPi) and sharefs is now generally running at 4 – 5 MB/s on all machines, and seems reliable on the limited use of sharefs since. Maybe I will bump up the setting a bit more.

All in all, Colin’s changes have made a significant improvement in this area.

I have lmtransport configured to IP so it’s using the NBIP back end.

SMB over NBT using IP as the transport then. Mappings will be restricted to share level with a sharename of of 15 characters or less. Full UNC mapping won’t be supported, as a few have already noticed – not a problem, but can cause some confusion when you try to map to a UNC and receive a “share does not exist” failure.

As Steve has pointed out, provided the map is to the share and you then browse to any subdirectory it should work perfectly. UNC mappings won’t be possible (as in the \\pluto\temp\piboot example above)

Where there is a need to share to a subdirectory, the sharing device would need a specific share at that level. Taking the \\pluto\temp\piboot example, that means a share called “piboot” created at “C:\temp\piboot”