Pi Isochronous ROM

Re omni I couldn’t get the password to work so had to disable passwords for network connections on my PC. I found it slow.

or anything to add?

Just a note on my experience with a self-built mid-July ROM on the Pi. My PC fetches stuff at around 260KB/sec. That’s maxing out my connection. The Pi fetches at about 86KB/sec flat out.

It is otherwise stable – I can hook up to AnimeNFO (http://itori.animenfo.com:443/) or JPopSuki (http://213.239.204.252:8000/stream) and pass half a GB or more in listening to the 192kbps streams.
Although given the apparent demographic of RISC OS users according to show photos, this might be more appropriate: http://lush.wavestreamer.com:7309/ ;-)

To me this shows that the backend of EtherUSB for the plugable adapter is slow for reading and writing and the backend for the pi’s internal adapter is only slow writing.

Beagle xM, Panda und RPi Modell B use the same chipset (SMSC) fur USB and Ethernet.
The problem is only a Pi one.
If I use my external Lindy adapter on a Beagle and a Pi Modell A the reading speed is both the same (fast) and the writing speed is slow only with the RPi.
If I use Linux, the read/writing speed is nealy the same an both (Beagle/RPi; write/read; fast).

Ok I’ve fired up Dave’s beagleboard (it doesn’t have its own Ethernet port) I’ve also tried Dave’s Ethernet adapter. His ethernet adapter turned out to use the same chipset as my adapter (AX88772) and the results on all computers for both adapters are identical – so we can rule out a faulty adapter.

Using lanman98 I have the following situation (slow is >10min and fast is <1 min for a 15MB file)

Computer   Backend   Read   Write
Beagle     AX88772   slow   fast
Pi         AX88772   slow   slow
Iyonix     AX88772   slow   slow
Pi         SMC95xx   fast   slow

So the problems I’m having are not pi specific. The Beagle and Iyonix both use the same EHCI backend and same EtherUSB backend ie identical code yet one is fast to write and the other is slow.

I can only think at the moment that there is some sort of reentrancy problem that a faster machine doesn’t suffer from. On the slow transfers I have had the odd timeout writing implying the sockets are waiting for replies before they can continue.

Do you know what chipset the Lindy Adapter has?

The Lindyadapter has a MCS7830. I have also a external with a AX88772 and a other I forget. All the same. Only the RPi has the slow writing speed. The external adapters are a little bit slower (5%) then internal.
I never use lanman98. I only read/wrote with FTPc to my NAS and to the homepageserver. The reading speed was never a problem.
The other I use is ShareFS. It is not the fastes with all.
And if I use ComCentre with my MobileStick, the writing speed to my homepage with the RPi is also slower (1%?) then with the rest of my hardware.

ShareFS is not very stable. The NFS server/client works perfectly with my Panda and Iyonix.

Can you confirm that when you say it works with the iyonix that you are using the iyonix motherboard ethernet?

The Iyonix ethernet uses a different system.

Which NFS server/client would that be?

The question was not for me, l know.
I have use the fishes (Sun and Moon) but only with xM and a9home. Stable but ShareFS is a little bit faster but not so stable, I can confirm.

Delete by myself.

Double trouble from Smartphone ;-)

I use Moonfish and Sunfish too. Integrated Ethernet for the workstation (iyonix), integrated ethernet for the server (PandaBoard). No real problem. ShareFS is less stable and have annoying refresh bugs.

http://www.riscos.fr/cgi-bin/uptime

I hope that Ethernet will be more fast on Pi soon, as it’s impossible to reboot a PandaBoard without crashing it.

http://www.riscos.fr/cgi-bin/uptime

“L’ouverture de ce site français dédié à RISC OS est programmée pour mai 2014.”

C’est maintenant septembre! ;-)

Yes, I’m really late :)
A lot to do.

Does anyone know if the DWCdriver software for the pi is the same as the one used by linux?

I’ve been tracking down why writing is slow with lanman98 on a pi. It turns out that it isn’t writing that is slow it is reading.

When a file is written from the pi to my pc there are a lot of reads interleaved with the writes. Timing the writes from programming the USB controller until the transfer_complete interrupt from the controller always happens within 1 centisec. Reads however sometimes can take several seconds between programming the controller and receiving the complete interrupt This appears to coincide with the hourglass appearing during the transfer – generally the complete interrupt happens within 1 csec.. The mouse still works while the hourglass is on, showing usb is still working, but taskwindows stop.

It looks like lanman98 is waiting for a reply to the read before it can continue with the write.

I suppose I’m hoping writing this down will give me new inspiration :-) but if anyone has any thoughts?

Note this isn’t a lanman98 specific problem it’s just excellent at producing it.

Mmm, my copy of Sun- and Moonfish not working with my RPi. Maybe not the newest.

I have copy my 100MB Testfile…

NFS (Sun-, Moonfish)
a9home —> xM 1min 30s
xM —> a9home 1min 20s

ShareFS
xM —> a9home < 55s
a9home —> xM 30s

Does anyone know if the DWCdriver software for the pi is the same as the one used by linux?

The RISC OS version of the driver is based around this version of the Linux driver. However that code is now fairly out of date; shortly after I got that version of the code working under RISC OS the Linux version of the driver was updated to the ‘fiq_fsm’ version which completely overhauls how the driver uses FIQs. Looking at the checkin comments fiq_fsm does feature some improvements to handling of isochronous transactions, so from your perspective it might be nice to try getting it working some day, but I’m not sure how straightforward it would be (the big problem with porting any FIQ-based code is making sure that it can gracefully release and reclaim the FIQ vector in response to Service_ClaimFIQ/Service_ReleaseFIQ – Linux doesn’t seem to have a counterpart for these and so the code expects to always be in control of the FIQ vector)

Ok.

Anyone like to try this PiIsocRom.zip.

It has a modified EtherUSB module and should work writing.

Let me know if there are any problems.

Thanks

I’ve updated the above link to fix a bug in the EtherUSB ax88772 backend so if you are using a ax88772 ethernet dongle with the pi that should work fine now.

Note if you are networking to a beagle, panda ie another RISCOS machine that uses USB ethernet you will still have problems as you don’t have an updated etherUSB for these machines.

Thats fantastic!

I can now upload large files to my nas storage in seconds and not minutes

I tried out the PiIsocRom posted yesterday, my Pi fails during mod init.
I get the following error;
mod init doneError: Not enough memory, stack overflow (Error Number &80000021)

I am then left without a keyboard and mouse. I did make the changes inside !Boot as per the readme.
I even tried increasing the AddToRMA value to 512K

Jeff

Excellent. What are you using to transfer?

Rob.

Unfortunately the error occurs before the AddToRMA change happens. I found I get it if I have too many devices plugged into an attached hub. If that is the case for you could you try unplugging something – you can plug it back in after the desktop appears.

I’m still trying to work out how to fix that.

Thanks Colin.
The ROM boots fine if I unplug my USB hub.

I’m using lanman98 as I found omni to be a bit buggy (not a pi thing, but something changed in omni a few years ago which meant that it didn’t transfer multi files correctly).

Thanks Colin.

The Isochronous ROM works fine here too provided there is not “too much” connected to the USB hub. Outbound LAN traffic is now at about the same rate as inbound transfers as tested with LanMan98 to a NAS and with ShareFS to a VRPC.

I have tra any things with my B+ and the “old” 100MB file.

ShareFS:
a9home <—> B+ 1min

FTPc:
B+ (MicroSD) —> NAS 30s
B+ (RAMDisc) —> NAS 25s
NAS —> B+ (MicroSD) 1 min
NAS —> B+ (RAMDisc) 20s

Works fine for me. Fast and stable.
Tomorrow I will try my Modell A with a ax-Dongle and any audio-stuff with the B+.

Thanks a lot.

Yesssss!
Now RISC OS can act as a NAS system :)
NFS, Samba, web… just needs a (stable) FTP Server.