Titanium slow networking.

Has anyone else noticed slow networking on the Titanium with today’s, 03Apr20, ROM which has an updated EtherCPSW 0.04.

The VNC server on the Titanium is noticeably slower, writing to a USB memory pen in the router is slower both with LanMan98 and LanManFS, and ShareFS to the RPi3B+ would not even start. The ROM from 29Mar20 is OK.

I have just downloaded the latest ROM and given it a whirl. No problems here with ShareFS – in fact on the few tests I did with some mp3 files to/from the ARM6 it seemed rather nippy.

I’ve had a problem for a few months now only on Titanium. Downloads are between 20K/s and 150K/s. e.g NFS mounted folder using sunfish. Uploads transfer at full speed. Still the same with today’s ROM.

Has anyone else noticed slow networking on the Titanium with today’s, 03Apr20, ROM which has an updated EtherCPSW 0.04.

I’d tested the changes locally for a week or so before submitting to ROOL, and haven’t noticed anything different, though I rarely use ShareFS myself.

There was only 1 material change in all the diffs, which was to turn off flow control on the internal switch (note: nothing to do with Ethernet flow control). To see if that’s the difference type

*MemoryA P 48484024 1

Also check *ShareFSWindow is tuned (to 1?) as I’m sure it is on both ends.

I’ve had a problem for a few months now only on Titanium. Downloads are between 20K/s and 150K/s. e.g NFS mounted folder using sunfish. Uploads transfer at full speed. Still the same with today’s ROM.

Could you check *Status and make sure the various ‘ECP’ settings make sense for your setup. Does the NFS client in !Omni do anything different? And check *ShowStat isn’t reporting lack of Mbufs? A WireShark capture would also be good if the far end is able to capture that. Feel free to stick it in an Elesar support ticket if there’s too much to paste here.

*MemoryA P 48484024 1

That restored things nicely as does a ROM build with flow control turned on in c.if_cpsw line 1085.

Do my networking arrangements have anything to do with this. The Titanium sits behind a 100Mb/s switch. (To connect directly to the gigabit network then networking would be throttled with co. ECPAdvertise 0 10 100.) The 100Mb/s switch connects to the router via a Netgear EX6150v2 range extender.

Also check *ShareFSWindow is tuned (to 1?) as I’m sure it is on both ends.

ShareFSWindow is 1 on the Titanium and 2 on the Pi’s. That works just fine here.

Had a try earlier with VNC. ARMX6 as server, Titanium as client. Things running nicely. The machines are connected via a 1Gb switch. This is all with flow control as set in the ROM – no override.

Had a try earlier with VNC. ARMX6 as server, Titanium as client. Things running nicely.

The problem here is the other way around, the Titanium serving to VNC Viewer on the Mac.

Netgear EX6150v2 range extender

To see if the range extender is an issue both the Titanium and RPi3B+ were moved (downstairs) onto the wired gigabit LAN but on the Titanium ‘flow control’ still needed to be on and its Ethernet limited to 100Mb/s. The RPi3B+ does seem OK at 1000Mb/s.

The problem here is the other way around, the Titanium serving to VNC Viewer on the Mac.

Just tried with ARMX6 as client and Titanium as server (default flow control). It seems not too bad – certainly no worse than with earlier OS versions (I only change the OS on the Ti every 1 or 2 weeks). The ARMX6 always appeared to be slower when client.

Fixed in EtherCPSW 0.05.

Many thanks.

Fixed in EtherCPSW 0.05.

You’re awake early, David – thanks for confirming. We’re in dialogue with Jared, the developer of the upstream NetBSD version, but in the meantime the safest option was to put the egress flow control back to its default value for RISC OS.