New Install on RPI 3 issues

I started 20 years back with a A3010

I first started 2 years ago. xD

I first started 2 years ago. xD

RISC OS? 29 years ago.

Acorn? 31 years ago.

Yes…I have grey hair…

SDFS is great, but Pi interface is not. USB is faster for RPi.

I think that only would be true for slow SD cards. IIRC Ben who wrote SDFS reckoned it was 2-3 times faster than USB.

I think that only would be true for slow SD cards.

Maybe, but not my experience. I just did a mini test which is by no means conclusive but does hint towards my impression. I copied the DDE27 archive to RAM from SD or USB and copied from RAM to SD of USB respectively to get some rough numbers.

Onboard SD (with ROOL ePic):

Read: 2.44
Write: 3.28

USB-to-SD adapter (Kingston 80MB/s):

Read: 1.76
Write: 3.44

I don’t know what ROOL use for the ePic, but used high-quality cards on RO5 and still found USB faster.

Edit: Fixed ambiguity, hopefully

I’m having trouble making sense of your figures. You say you copied from RAM to SD or USB, yet the lower figures say “USB to SD”?

If we assume that what you did was copy from the media to RAM, and then from RAM back to the media, and that the upper figures are SD and the lower USB (is that correct?), then…

…looks to me like SD is considerably faster at reading, and only marginally slower at writing. Whether or not this affects you will surely depend upon your ratio of reads to writes, but RISC OS isn’t a system that tends to lend itself to hardcore writing (you won’t be dealing with HD video streams, for instance). With that in mind, a faster read speed might be more useful – in which case SD would seem to be better.

To put this into context, the DDE when building RISC OS may need to read dozens (if not a hundred odd) files repeatedly
over and over, hundreds of times, while creating files that are fairly small in comparison to the amount of data read.

As for the potential difference in speed and what effect it can have:

In 2013, I was using an older class 4 2GB card. Unpacking the RISC OS sources took 28 minutes to unbzip, and several hours to untar; then about 50 minutes to build from scratch.

I rebuilt RISC OS recently from a more recent source archive. I don’t recall how long it took to unbzip as the extraction process froze the machine (I was unpacking to a FileCore format USB stick). I unpacked again directly to SD card (a Class 10 claiming to be good for HD video) from the already expanded tar file (why decompress twice?) and it did the job in about 7-8 minutes. Seriously, it was done when I came back from making a cup of tea. The logfiles indicate that building RISC OS itself (from scratch) took around 35 minutes.

If we assume that what you did was copy from the media to RAM, and then from RAM back to the media

Thats correct. I did the same for both USB and onboard SD. Onboard SD did not write to USB nor the otherway around.

looks to me like SD is considerably faster at reading, and only marginally slower at writing.

Onboard SD is slower at reading. Writing is about the same speed.

With that in mind, a faster read speed might be more useful – in which case SD would seem to be better.

It is more useful, but USB is the faster read.

To put this into context, the DDE when building RISC OS may need to read dozens (if not a hundred odd) files repeatedly over and over, hundreds of times, while creating files that are fairly small in comparison to the amount of data read.

No. It was archived, so in a zip file.

It is more useful, but USB is the faster read.

I use a better SD card, and go up to 30 MB/s (reading/writing). Reading and writing can be a bit faster on an external SSD. But you must not doing anything else, as all USB peripherals (including the Ethernet chip) share the same limited bandwidth.

That’s the problem: USB disc is faster, but only under no load. Nota: the use of the SD port have no impact on USB bandwidth. Note that I did not try to boost the SD with “dtparam=sd_overclock=100”. It should boost the speed of around 50%.

I use a better SD card, and go up to 30 MB/s (reading/writing). Reading and writing can be a bit faster on an external SSD. But you must not doing anything else, as all USB peripherals (including the Ethernet chip) share the same limited bandwidth.

30MB/s is more or less the top end of an standard clocked Pi. Ethernet will take 12.5MB tops (thats 100Mbps), so 60MB – 12.5MB = 47.7MB (I think, mental arithmetic) keyboard and mouse take next to nothing so looking at 47MB R/W easy if eth at full wack. Still faster.

Semi related. I used the Pi 3 with Raspbian last night to copy the contents of my FAT32 USB stick that I use for misc. RO stuff to the NAS. As soon as I started the feeling of dread set in.

RPis are phenomenally slow when it comes to concurrent disk and network usage because of the previously stated bandwidth sharing. I imagine anyone with a fabled good internet connection would really feel it with downloads.
One of the reasons I’m trying to do an OPi PC port. It doesn’t share bandwidth between ports. Network transfers are fast.
Still, for what it is the RPi is good. Bottlenecks have to be expected.

I imagine anyone with a fabled good internet connection would really feel it with downloads

I have 100 megabit fibre and get maybe 10 on the Pi. I’m pretty sure that it’s only marginally faster under Raspbian, although my memory may be a little faulty there.

I have 100 megabit fibre and get maybe 10 on the Pi. I’m pretty sure that it’s only marginally faster under Raspbian, although my memory may be a little faulty there.

I’m getting a little bit worried people are confusing bits with bytes. Networking is measured in bits, but file transfers are bytes and download dialogs too. 10 M Bytes is the top end of a 100 M bits ethernet, like on the RPi. Further, the TCP/IP stack is in need of a refresh so that would also be a factor.

To clarify: My 100 megabit connection runs at ~10 megabits or ~1.2 megabytes/second on the Pi.

Although I’m actually sitting next to the Pi right now so why don’t I get some actual figures instead of trusting my memory?

Edit: Downloading to RAM disc using NetSurf yielded 700 kb/s or approx 5.6 Mb/s (although I’m not sure whether NS saves directly to RAM or whether it goes via Scrap).

so 60MB – 12.5MB = 47.7MB

60 MB/s?

The max I get is around 35 MB/s on USB ports, without any networking. With networking, it will be less. And with big sync issues on USB. That lowers the usable bandwidth… a lot. it’s not something like 480-100 Mbit/s, but more something like 280-15(Ethernet)-50(sync).

And the stability will be lowered too. Try to move 100 GB of data from one USB disc to one another (I did): crash. Try to use RISC OS – a lot – for a whole day on external USB disc: crash. The only good point is speed with little files. Not linked to USB but to SSD.

And as I said, if 100 MHz mode is supported by RISC OS, there is no way for USB storage to go faster than SD card reader.

Nota: I use Samsung Evo+ cards. Very fast. 80 MB/s on PC. 30 MB/s on SD card reader (Pi). 35 MB/s on USB reader (Pi) without network or other peripherals. I did not benchmark it yet, but I think on Raspbian with 100 MHz mode, I probably go up to 45 MB/s on internal SD card reader.

You guys are totally going to bait me into a full benchmark, aren’t you. Lol

I just did a little test on my Pi 3.

RAM → HDD: 16.65 seconds
HDD → RAM: 16.66 seconds
RAM → SD: 50.37 seconds
SD → RAM: 21.77 seconds

Clearly the HDD is faster, at least on my system. The SD card is a class 10 Transcend, and the HDD is a 500 GB HGST (formatted with FileCore to 256 GB), hooked up with a “Seagate Expansion” adapter. Test data was a folder containing the installer for a Windows app, duplicated a few times to get it up to a reasonable size (388 MB).

Clearly the HDD is faster, at least on my system.

Mine too, plus it’s my boot disk and I’ve had no stability problems (except the hot weather overheating my Pi) I think the worry was ethernet at full speed bottle-necking the USB drive. My inclination would be no, but not run any tests yet.

I think the worry was ethernet at full speed bottle-necking the USB drive. My inclination would be no, but not run any tests yet.

Remember, the Pi only has one actual USB port. It goes from there to a hub/Ethernet device…

Remember, the Pi only has one actual USB port. It goes from there to a hub/Ethernet device…

I factored that in Rick. This is why I’d be interested in the result. I’m curious, but not curious enough to actually manufacturer a test, yet.

You guys are totally going to bait me into a full benchmark, aren’t you. Lol

The figures I gave you are real numbers on a Pi3 used several hours a day from months.
To get fair tests, compare the same SD card on internal reader and external reader.

Nota: the 100 MHz mode makes the internal SD card reader being much faster on Raspbian. Even if here I have no precise numbers to give. Boot time suggests +40% / +50%.

Is there a way to send and receive emails with freeware tools?

!PopStar seems to be not 32-bit compatiple.

!TapirMail runs but doesn’t connect to gmail. I’ve setup the pop and smtp server account but when I try to receive mails TapirMail shows the yellow icon endlessly. Same when I try to write and send an email.

Any advice would be welcome.

!PopStar seems to be not 32-bit compatiple.

I mean you need this newer RunImage.
Additional you should use !SMTPS, !POP3S and !Mailer from here and a free eMail-App ist !Pluto (!POPStar is only a transporter).

Hi Raik,
tried the RunImage still the same problem.
“Error: Application may have gone wrong.”
!POP3S and !Mailer isn’t running as well. !Mailer breaks with an error code.
Do you have any additional ideas to get !PopStar running?

tried the RunImage still the same problem.
“Error: Application may have gone wrong.”

The RunImage file was compiled in 2013 and consequently has CLib content that probably won’t run on a Pi3. The solution may be a simple as a recompile with an up to date library.

Do you have any additional ideas to get !PopStar running?

Here you find the POPStar I “use” (only to play around with, for daily use is Messenger my first choice). I wondering, is a old version but I have try with my Pi3 Pi-Top and a RC15 based system. I use it with ppp so I need “alignment exceptions off” in the CPU settings.

!POPStar is only a transporter without SSL/TLS. I mean (not sure) for GMail you need SSL/TLS. !SMTPS and !POP3S can handle. !Mailer is not necessary. It should make things easier but you can use !SMTPS and !POP3S without (if I use, I do so). As I remember you not need a full working !POPStar. It must only seen by the filer. !POP3S and !SMTPS are using the mail folder inside !POPStar because they are knowing by the eMail apps like !Pluto or the commercial !Messenger. So both are working with the default settings for !POPStar.
Alex is not activ here. If you need help (!SMTPS and !POP3S) you should use www.arcsite.de ;-)

To confirm that POPstar 2.06-ds.5 (8-Jun-2013) works perfectly on the RPi3.

This brilliant wrinkle to the Messages file ducks some ZeroPain

@Oliver, if using a high vector ROM, the ZeroPain module is installed isn’t it?

A 32bit SocketWatch Module 0.04y is here

I use the paid for MessengerPro for the rest of it, so cannot help further.