Pi Isochronous ROM

LM98 Pi Model B RAM disc to NAS: ONLY about 60 times quicker than it used to be:-)
Great work Colin. Do you know which part of your work was the speed fix?

I think the speed up of writes just requires a couple of changes to EtherUSB however there is still something wrong with reads. I fixed a bug in the driver for an ax88772 usb dongle relating to reads which made it work with my Pi but when I tried the EtherUSB changes on a beagle reads are still slow. I’ve a bad feeling that I’ll have to make changes to the USB driver to fix this.

I’d like to know if anyone who is using USB ethernet not on a Pi is having problems with reading from a NAS or via ShareFS from an Iyonix. The reason I specify a NAS or Iyonix is to avoid the other machine having EtherUSB problems.

Is anyone successfully using a USB Ethernet dongle to read from a NAS/Iyonix

Presumably the PandaRO which is USB ethernet if I remember correctly works ok reading? If so Have you ever tried a separate Ethernet dongle.

I’m trying to figure out if there’s a problem with the ax88772 driver or it’s more serious than that.

Just tried a few tests.

File is a recent HD4 zip file about 11.3 MB.

Timings are using Alarm set to display secs, so +/- 1 sec allowing for the vagaries introduced by NetTime 8)

All machines are connected via the same 100 Mb/s switch and using ShareFS.

Tests done are
IYO – PandaRO SD card
IYO – PandaRO SSD Filecore format
PandaRO – Iyo
IYO – ARMini SD card
IYO – ARMini SSD Fat32Fs format
ARMini – Iyo

In all cases the transfer took 6 +/- 1 seconds, probably limited by my eyeballs and mouse finger, so we are looking at about 2 MB/s.

Not sure if that is any help.

All machines are running versions of RISC OS 5.21 dated in August, but not the same date. The ethernet hardware in all cases is ‘as supplied’, no separate dongles.

… and just for the record I have now done BB-PB and PB-BB and the timings for the 11.3MB file are both around the 6 second mark.

Looks like there is no problem with the smsc95xx drivers which I think is used in all these machines except the Iyo.

Thanks

I can not try my AX-Dongle. It is not in the *ejproducts list.
I have used *set ejproduct_0b95_772a AX88772 that works with my Beagle C4 and my Pandora but not with your ROM and not with the original RC12a.
This post is via my mobile stick. Works.

When you say the dongle works on a Beagle C4 can you transfer files ‘quickly’ ‘to’ the Beagle C4 using shareFS?

No, I can’t ;-)
I use the Pandora. Is comparable and I could do that at breakfast ;-)
Also the 100MB file… share with a9home.

AX88772 —> very very slow… abort by me after 15 Minutes (download from ROOL and send a Mail… no problem)
MCS 7830 (my main adapter) —> 45s
external SMSC 95xx —> 50s

Yes I find that using netsurf and lanman98 the ax88772 works ok but not reading with ShareFS. I think it may be a problem with flow control – I find ShareFS to be fast – it’s the fastest program for file transfer I’ve tried. I think fast replies are causing problems.

Nothing to add on the pluggable adaptor issue, but I’ve been testing the PiISoch ROM on my (700Mhz) Pi using a 12xJPEG, 46,000k directory, copying it from its location on my 32GB Kingston class 10 USB stick to various locations and back again:

USB card → SD card = 12 secs;
USB card → PC shared drive via LM98 = 24 secs;
USB card → NAS via LM98 = 25 secs;
SD card → USB card = 14 secs;
NAS drive → USB card = 30 secs;
PC drive → USB card = 33 secs.

This is a /massive/ improvement on the situation with the standard ROM, where network writes were so glacially slow as to be virtually useless. Many thanks Colin! I’ll do the same tests again with my Pi upclocked to 900MHz in due course.

I note that my changes have now been added to the ROOL sources so the latest ROOL pi rom should have fast writes.

I didn’t find a solution to the problem of the plugable adapter (or any ax88772 adapter) not working properly with sharefs – which uses udp so I think the problem is receiving udp packets in general – but I did find a work around. So for anyone who wants to know you need to set

*sharefswindow 1

on all machines using sharefs.

I found an oddity which may be of interest. When using lanman98 I would get the hourglass appearing every so often. It turned out to be related to the connection to my laptop being wireless. If I plugged my laptop into the router I don’t see the hourglass appearing on my riscos machines. It must be caused by errors in the wireless transmission.

When using lanman98 I would get the hourglass appearing every so often. It turned out to be related to the connection to my laptop being wireless. If I plugged my laptop into the router I don’t see the hourglass appearing on my riscos machines. It must be caused by errors in the wireless transmission.

Inherent in wireless systems. They are contended media and CSMA comes to the fore.
On wired a device can send and receive simultaneously (full duplex) unless wireless uses two channels it has to operate half duplex.

You want a simple connection – use wireless.
You want a fast connection – use wired.

Sadly, I’ve had to revert to the ‘slow’ 2412k Riscos.img; the Isochronous one doesn’t work with my Epson Perfection 1660 scanner, which I use regularly; the machine freezes and requires a Ctrl-Break or a physical switch-off to exit. I tried reducing the number of USB devices to 3 (mouse, keyboard and USB card) on my powered hub, without success.

Could you try the latest pi rom from ROOL that should fix the slow network writes. Does the scanner work with that?

George/Colin

I have tried my Espson 1660 with DPlngScan and Twain 0.02 with a Raspberry Pi ROM dated 31st Aug 14 plus same dated hard disc image and it works fine.

Hope this helps

Doug

Did you try my Isochronous rom? I’m just wondering if you can repeat George’s problem

Colin

Tried it with your Isochronous ROM and it does lock up and freeze the Pi.

The first time I tried things using the preview option it gave this error:

“Internal Error, no stck for trap handler. Divide by Zero, pc = FC19EC98 Registers at 000D3854.”

The next time just caused the Pi to lock up.

Reset and tried again and got a lock up straight away when using the scan option.

Reverting to 31/8/14 ROM restores DPlngScan to working order.

Doug

Thanks for trying it.

Hmmm….

Colin: I’m confused by the Hmmm isn’t Doug’s findings good news?
i.e. that the latest ROM with your Isochronous updates works.

Well, Doug seems to have established that Colin’s ROM crashes the Epson 1660 scanner, so can’t be said to ‘work’ for anyone needing to use that particular device with their Pi (despite its considerable merits in other respects). Hence the Hmmmm?

The problem is I can’t solve it from here and can’t keep asking people to try things out – they may not want to :-)

One problem I do have is the changes I have made require more memory and this can cause failure because ‘PCI shared memory’ – see tasks window – isn’t big enough when I need memory allocated from an interrupt. If that is the problem then Increasing the ‘PCI shared memory’ in the tasks window before using the scanner should make it work.

The Pi seems particularly prone to having little free space in PCI memory at startup. I thought the minor change to the bootfile in the readme file was a temporary work around but it isn’t always the case.

Note the error quoted is in the sharedCLib so unfortunately doesn’t help.

Just re-tried the PiIsoc ROM, set PCI shared memory to 25000k (initial size 380k on this system), launched DPingScan, acquired scanner and attempted to Preview, got same error message as Doug but with the registers at 000D247C. For the record I’m running 5.21, 25-Feb-14, Pi at standard clock settings e.g. 700MHz.

AIUI: George and Doug confirmed that the special Isochronous ROM build Colin did and put on the iconbar website had problems with scanners.
Doug tried “Reverting to 31/8/14 ROM restores DPlngScan to working order” which I’m presuming is the ROOL build that has Colin’s Isochronous USB updates in it.
Or have I misunderstood everything like normal?

ROOL have only incorporated the EtherUSB changes not the USB stack changes I have.

Ahh now I understand. I thought they’d sprinkled fairy dust on your code and made it work even better.
One bit of feedback when using your build from the iconbar website our Pi was falling over during booting 80%+ after the init mod message. We tracked it down to only having the keyboard plugged in at the time, we plugged in a mouse and it booted fine. This was repeatable. No hub was in use.