Very slow network reads on ARMx6 with LanMan98

1) LanMan98 is HORRENDOUSLY slow in READING files to ARMx6 over a gigabit network, with good cabling and network switches. It is the only computer with this problem on the network. Iyonix is fine. WRITING to the server is fine. LanMan is fine.

2) Using LanMan instead is not an option because it introduces errors into reads of large files. My 10M OPro files (and some large sprite files) cannot be read by LanMan. Not just when the files are read by OPro, but also when just copied across the network by the filer. So OPro is clearly not the problem here.

3) The upshot of this is that I can’t read the files via LanMan due to its bugs, and LanMan98 is at least 10x slower (yes, really) but at least reliable. It NEVER corrupts files. If I really want to look at something in a hurry I need to resort to my old Iyonix, which reads the files on LanMan98 fast and reliably, or store the files on the local hard disc and miss out on the daily automatic backups the main linux file server gets.

My own ‘take’ on all this is that there must be a subtle bug in the EtherTH module which is triggered by LanMan98 and not by LanMan. This is the only variable between the two machines. But because there is no possibility of comparing the LanMan and LanMan98 source code nobody knows what the problem might be. Everyone says the other must be at fault.

It was suggested that I try changing some settings on the server, as it may be ‘flooding’ hardware buffers on the ARMx6. However, I see the same slow read speeds from a Windows 10 PC. I can’t change the settings of every machine on the network just because of the ARMx6!

I am NOT trying to blame anyone. But this is a serious problem which needs to be fixed.
I would be happy to run any tests, betas, etc through my system in order to help.

Software version:
ARMx6 standard 5.23 OS
LanMan version 2.56
EtherTH version 0.23
LanMan98 version 2.05

Michael

I know you say the Iyonix is Ok but have you tried changing the ARMX6 LanMan98 !Run file settings to disable RAW reads as per the below extract?

| The following line tells LanMan98 to use raw read requests for speed if the
| server claims to support it. Some NAS, and Windows Vista claim to support
| it, but actually fail to do so. If you have problems with your connections
| comment the following line out to make LanMan98 avoid raw reads in all
| cases.
|Set LanMan98$ReadRaw ""

You will notice that Windows Vista is mentioned as having issues as well so a good chance slow reads to a Windows PC running Windows 10 may also be affected.

So ensure the above is the same in the LanMan98 !Run file on your ARMX6.

Changing this setting cleared my issues with slow NAS drive reads.

Yes, I have done that. John Ballance suggested it. It made no difference. I have also tried swapping the Iyonix and ARMx6 cables in case that was the problem. I have tried changing the mtu as well. The network has some PCs, a linux server an Iyonix and an ARMx6. The latter is the only one with this problem.

(It is also unlikely that both the linux server and the Windows 10 machines would both be sensitive to raw reads being slow).

FWIW, Chris Hall’s HowFast hardware benchmarks http://www.svrsig.org/HowFast.htm recorded a similarly slow read speed under LanMan98 for the ARMX6 (1.8 MB/s compared to 8.5 for the Iyo). That said, the Titanium registered only 2.1 MB/s, so maybe there is a s/ware issue.

Chris Hall’s HowFast hardware benchmarks recorded a similarly slow read speed under LanMan98 for the ARMX6 (1.8 MB/s compared to 8.5 for the Iyo)

Is 1.8MB/s ‘horrendously slow’ these days? What kind of speed is Michael seeing?

LanMan98 for the ARMX6 (1.8 MB/s compared to 8.5 for the Iyo)

Read speeds, LanMan98, 20MB file. Titanium 0.7MB/s, RPi3 3.4MB/s and iMac VRPC 9MB/s.

(LanManFS gave the same result as LanMan98 on the Titanium.)

Just to be quite clear, there’s definately more at play than meets the eye. We ran some tests against three different QNAP NAS devices today with identical files, one Intel-based, the other ARM-based, all from ARMX6. We observed minor hourglassing on the ARM-based one, but still with reasonable LAN performance (a 1 gigabyte file copied in about 5-6 minutes), whereas the Intel-based ones saw no hourglassing and completed in about 3 mins.

Whilst I am not denying there’s a problem, I suspect there’s a lot more to this than meets the eye, esp as Ti seems equally affected from what this thread suggests.

If I had to make a guess, perhaps the Intel-NIC on the Iyonix (which was/is best-of-breed) has more hardware buffers, and leaves less to the software stack (or simply doesn’t work the same way as modern NICs), whereas the newer hardware is expecting more from the network stack.

It is unquestionable that the TCP/IP stack in RISC OS is in dire need of a “ground up” replacement, but that’s a huge project and I don’t see funding forthcoming for it :(

If I had to make a guess, perhaps the Intel-NIC on the Iyonix (which was/is best-of-breed) has more hardware buffers, and leaves less to the software stack (or simply doesn’t work the same way as modern NICs), whereas the newer hardware is expecting more from the network stack.

No idea about the RO version driver but the PC driver for that chipset has the ability to offload some of the processing to the NIC.

I still find it very puzzling that LanMan and ShareFS do not suffer from this problem, but LanMan98 does.

Using LanMan instead is not an option because it introduces errors into reads of large files.

Does what you see sound like this description ? If you’re able you could try this modified copy and when logged on to the PC type

*LanMan
*LMInfo

Titanium 0.7MB/s

TP-Link TG-SG105 5 port Gigabit Desktop Switch!!!!! The Iyonix was OK via that same switch. The Titanium is now connected to an old 10/100 Switch to return a read of 3.5MB/s.

It may be that ‘pause frame’ hasn’t been implemented/configured in EtherTH for gigabit ethernet as suggested by the imx6 errata document. That is supposed to work around RX overruns caused by the NIC not being true gigabit ethernet.

This is what I got from the LanMan command LMInfo (with the modified LanMan – 2.58)

Machine name : ARMX6
Driver name : eth0
Name mode : 2
OmniClient : started
Workgroup/domain : WORKGROUP
Username : GUEST
Home directory : (unset)

Server ‘linux.bgnet’: ‘’
Drives : ’DocsAndSheets’
Printers : (none)

Mount ‘DocsAndSheets’: ‘DocsAndSheets’ on server ‘linux.bgnet’ as user ‘MYBG’

I think that Colin may have the answer we have all been looking for. If what he says is correct, could it be that some small modifications to EtherTH would be what is needed to fix this?

It may be that ‘pause frame’ hasn’t been implemented/configured in EtherTH for gigabit ethernet as suggested by the imx6 errata document. That is supposed to work around RX overruns caused by the NIC not being true gigabit ethernet.

Interestingly the Titanium also suffers the same slow down but not the RapidO Ig(IGEPv5) who’s “HD Read MB/s LM98 to NAS” is 12.3MB/s compared to 1.8MB/s on the iMX6 & 2.1MB/s on the Titanium in Chris Halls tests. n.b. The Titanium SOC datasheet seems to imply it is true gigabit.

All three hardware units can achieve much faster speeds under Linux! RISC OS networking is in urgent need of replacement!

It would be interesting to see if changing the network interface from auto negotiation to 100Mb has an effect on both systems as similar issues were around I seem to recall when the Iyonix first came out until changes were made. This could be a work around if it proves successful until the issue highlighted by Colin is resolved.

Also think it is right that the networking stack needs updating and perhaps one where mutual co-operation from the hardware companies and ROOL/Users may help in the form of a matching bounty/commercial support initiative. Of course that is not withstanding the little issue of having some one to do the hard slog.

I have tried to enter ethconfig eth0 100 but I get a ‘bad parameter’ error!

However, by setting the switch to 100Mb/s I get significantly better reading speed, although writing is now much slower (it was pretty fast before).

re speeds of sitara/imx6/igepv5

All 3 use different ethernet drivers. Sitara (etherCPSW) and imx6 (etherTH) may have related code so suffer the same problems. igepv5 uses EtherUSB. Whilst not great the superior performance of igepv5 suggests that the immediate problem is not the ethernet stack but the etherCPSW and etherTH drivers. It would be interesting to see the performance of a Gigabit USB dongle (I have one with a smsc7500 chip, the same as the igepv5) on a titanium or imx6 – unfortunately neither come with etherusb drivers.

Just a question, but while testing throughput from (or to) a RO5 device, has anyone been using a fully managed switch so that they can monitor the negotiated connection speed & duplex and also monitor how much data is passing through the port on a second by second basis along with various transmission errors / dropped packets?

The thing is that 20MB/s would be about 200Mb/s which is reasonable on a medium used network. However figures of 1.8 – 2MB (18-20 Mb/s) is more in line with a duplex mis-match in which I’d expect to see quite a number of packet collisions, dropped packets etc.
That kind of thing would support the idea of a driver problem.

Improving the better performance example further probably requires stack/buffer improvements.

Just as reference, using a http request and an ARMX6 on a local gigabit network I can get around 12-15MB/sec downloading a file (i.e. read).
If you use netsurf the downloads are really slow.
A lot of NAS support http or ftp downloads – could you try that as a reference?
ftp perhaps?

I can’t connect to my NAS using LANMAN98 :-( EDIT [oops I can see it, just can’t connect to shares])
!Omni (LanMan) works fine for me with later versions though (although I’m not a heavy user)

The latest beta ARMX6 ROM includes EtherUSB for comparative testing, and as a fallback should anyone damage their primary port.

Unfortunately I can’t test gigabit ethernet on my ArmX6 as my network doesn’t support it. Out of interest I checked and on my network LanMan98 transfers at about 4MB/s (read/write) with EtherTH and 3.5MB/s (read/write) with EtherUSB.

Unfortunately I can’t test gigabit ethernet on my ArmX6 as my network doesn’t support it.

You’re probably miles away from me (Cov), otherwise I’d sort out a fully managed Gb/s switch.

Out of interest I checked and on my network LanMan98 transfers at about 4MB/s (read/write) with EtherTH and 3.5MB/s (read/write) with EtherUSB.

That’s about 35 – 40Mb/s from which I’d guess you’re using a 100Mb/s switch and either there’s a reasonable amount of traffic, the frame size and MTU for the switch don’t match optimally or there’s a bit of a buffer issue in one end or the other of the stream. Interesting IBM documentation

Edit: Forgot to mention, the table at the bottom shows the Cisco (bullsh**) style duplex figure where they count data in and out as being double the bandwidth and leave the user expecting to get close to 200Mb/s on a 100Mb/s link.
So just ignore those double up rubbish items.

I connected the ARMX6 directly to my laptop with the 1000Mb USB adapter attached to the laptop (the laptop lan port is 100Mb) and the ARMX6 read at about 5MB/s. Ethinfo showed the connection was 1000Mb. When connected directly to the laptop port (100Mb) the transfer rate was about 5.5MB/s. All tests I did with different cables showed slight variations between cables but reading was always more consistent than writing which could be as low as 1.5MB/s, as high as 5.5MB

LanMan98 and LanManFS show almost identical results ie they were equally flaky when writing.

So basically I’m getting the opposite effect to Michael’s in that my writes are more of a problem than reads and it doesn’t matter which client I use. It may be because a Windows 10 connection only transfers in approx 4k chunks and other servers may use different size buffers which may change the flow control problems.

I connected the ARMX6 directly to my laptop with the 1000Mb USB adapter attached to the laptop (the laptop lan port is 100Mb) and the ARMX6 read at about 5MB/s. Ethinfo showed the connection was 1000Mb.

EthInfo is wrong. An auto-neg device facing an auto-neg device should negotiate to the speed of the slowest device so you had to be operating at 100Mb/s.

Is there an equivalent of the EKAdvertise in the EtherTH ?
If so try using it to set the advertised rates and duplex, syntax is probably along the lines of:

*Configure EKAdvertise <unit number> [10 [Half] [Full]] [100 [Half] [Full]]

You aren’t interested in getting it to offer to do 1000.

BTW, other people seem to be suggesting flow control issues but the symptoms reported sound more like the effects of duplex mis-match issues to me.

There may be other faults too.