RISCOS networking and remote desktop?

Hi,

I’m planning to get more active on programming start dusting off my old skills.
I have a Iyonix with 2 video cards and so I like to use that for editing but I also have Raspberry Pi’s and I read a Pi is a lot faster in compiling and file access.

Is there a good way to transfer files from the Iyonix to a Pi and then compile them there by remote desktop?
Just leaving the files on the Pi and editing them on the Iyonix (remote folder) will also work as long as it is also possible to start a compiler on the Pi.
Thanks.

Cheers,
Jaco

I would write a simple multi-tasking programme to run in the background on the Pi looking at a particular directory for a particular file and if it exists to rename it, start a compilation session and, when finished, to rename the file again. Then the remote machine (Iyonix) can put a file there then put another file ‘CompileMe’ there, watch it change to ‘Running’ and then ‘Done’ and then read the result back. All using sharefs. The compilation on the Pi can be single tasking if necessary.

I guess that means sharing a folder is straight forward and sharing a desktop is not possible.
I will settle then for sharing the folder and have a screen and keyboard connected to the Pi and will find out how to share the Pi’s disk with the Iyonix.

Type share SDFS::Name.$ (you can’t do it from the SDFS drive icon) and make sure it is on the same sub net. It will then appear in the ‘Discs’ icon on the Iyonix. (Sharing a desktop may be possible but I would not know how.)

Sharing a desktop is possible, but the performance of existing solutions isn’t very good.

There’s a VNC server here which I maintain, and VNC clients here (Avalanche) and here (ViNCe).

The main performance issue is on the server side – RISC OS doesn’t provide an easy way for the server to detect screen updates so it has to periodically scan the screen to look for changes. Removing the backdrop and using a low resolution, low colour screen mode is the best way of improving performance. Running the server on the Pi would be best (screen memory reads on the Pi are a lot faster than on the Iyonix).

Another solution might be to have a telnet server running on one of the machines so that you can kick off a build that way. I’m not sure offhand where to find a suitable telnet server though. I think I wrote my own one – it sat on the iconbar and when a remote machine connected it would create a windowless taskwindow to execute the commands in. But it doesn’t look like I released it (I think it needs some basic password authentication adding, at least).

Thanks.
I’ll try the VNC server the way you recommend it. If it doesn’t crash it will be workable (I don’t need to be connected all the time and there won’t be a lot of movement)

I like to launch another question if I may.
At some point I will want to try connecting to a database. If the database is running local or on another machine doesn’t matter much.
Is there a database API?

You could still export individual windows via VNC, couldn’t you? It might even be possible to hook into the WIMP to intercept the update messages, or is that unlikely?

I read a Pi is a lot faster in compiling and file access

I’d compile on the iyonix – which I do – I haven’t noticed that the pi is noticably faster compiling and I wouldn’t trust the sd card with my sources.

I read it here: http://www.svrsig.org/HowFast.htm but another reason is that the Raspberry Pi is more supported. As I’m not so confident with RISCOS that’s maybe the strongest reason to use a Raspberry Pi with standard utilities. In case of any problems I’ll probably need to reproduce on RPI anyway to see if there is any difference.

Backups are needed anyhow. The SD card can be easily backed up and can run reliably. I have a RPI running for years reading my electric power meter, putting data in an SQL database and showing in web format via an apache web server. So I don’t see a problem there.

The compile times in the benchmarks are from RAM Disc – an odd benchmark in my view. Normal compiling shows little difference.

In case of any problems I’ll probably need to reproduce on RPI anyway to see if there is any difference.

It makes no difference if you compile on the iyonix or pi you’ll get the same code. You don’t even have to transfer the compiled program over to the pi to test on the pi you can just run it on the pi via sharefs and if it crashes it doesn’t affect your editing.

The SD card can be easily backed up and can run reliably.

I must have a lot of bad luck then :-)

Performance-wise, a lot depends on which model Pi is being compared to the Iyo. I’ve used both Pi B and Pi 2 and for most real-world tasks the latter is between 50% and 100% faster than the Iyonix, and similarly faster than the model B, providing it is explicitly clocked at 900Mhz and core and RAM speeds are also raised to 450Mhz by inserting the appropriate lines in Config.txt. So set, the Pi2 scores 1,047,711 (463,544) on the processor test and 10,606 (292) on memory (According to ROmark, Iyonix figs in brackets).

I like to launch another question if I may.
At some point I will want to try connecting to a database. If the database is running local or on another machine doesn’t matter much.
Is there a database API?

There aren’t any database APIs that I know of.

You could still export individual windows via VNC, couldn’t you? It might even be possible to hook into the WIMP to intercept the update messages, or is that unlikely?

Listening for redraw messages might work – I should probably look into it at some point. It would still have to scan each rectangle to work out what’s changed, but it would avoid it needing to constantly scan even when the machine is idle.

I’ve always thought it would be fun to do something that’s kind of a mish-mash of the X11 protocol and Synergy. Share keyboard and mice between computers as if they were all one big desktop, but also have the ability to seamlessly drag windows from one machine to another (either using a remote framebuffer like VNC, or by recreating the actual window and icons on the destination machine and forwarding Wimp messages between the two), and maybe even drag running applications between different machines too (OK, that last one is a bit ambitious, at least with RISC OS).

But for now I think I’ll just be happy with getting the OS to the point where modules can receive notifications when areas of screen memory are modified, so that fast VNC servers and DisplayLink drivers are a possibility.

but also have the ability to seamlessly drag windows from one machine to another

There was/is activeapps with a bouncy ball application to demo it plus the page suggests running over a net

Ah yes the Jaffasoft stuff. Appeared at just the time that things really went pop.

Notice the link to similar stuff in the other OS’s?:

“Gateway was under-development, but has since been paused. If there is interest, it could be finished. The implementation will be similar to the AATerm example shipped with WimpWorks. Another alternative would be to look at reimplementing it on top of ØMQ”

I read a Pi is a lot faster in compiling and file access.

Which Pi?

The Iyonix is a 600MHz ARMv5 family processor. The Pi (original) is a 700MHz ARMv6 family processor. There wasn’t really a big change between the ARMv5 (XScale) and the ARMv6 (ARM11), so you wouldn’t notice much more than you’d expect for an extra 100MHz of clock speed; that said, the Pi does support overclocking and will happily do 800MHz, faster at your discretion. So it will be slightly faster, but not OhMyGodOhMyGod! style speeds.

The Pi2, on the other hand, is a 900MHz ARMv7 (Cortex-A7) processor. As expected from that class of processor, it supports partial dual-issue so that some specific types of code (that doesn’t have too many instructions depending upon the result of the previous) can more or less execute two instructions at the same time. The processor won’t run code slower because of this, but it might manage to run it quite a bit faster.
That, plus numerous enhancements in the processor behaviour, mean that code will run faster. I’d also be very surprised if the Pi2 couldn’t be overclocked to a nice round gigahertz, too.

Now to the downside. That is the SD cards. I’m not going to say “they’re horrible and all mess up” as I saw all of my disc corruption problems go away once I decided to use a better quality power supply, decent USB cable, and don’t overclock it. I’m not sure exactly what was affecting my SD card, but it isn’t happening any more.
Plus, there are certain benefits to having a card that can be easily inserted into a PC and a complete image of the card contents dumped to harddisc for backup. It’s just a shame there exists nothing on Windows to mount FileCore partitions. ;-)

Aaanyways, SD cards come in “classes”. You should see a little number in a sort of circle (it’s a C). That number tells you the class of the card, and the class directly translates into the card’s capability for a sustained write operation, measured in megabytes per second. Class 2 cards can keep up with writing at 2MiB/sec. Class 10 cards can manage 10MiB/sec.
The big gotcha here is that this is a continuous dump of data, such as would be expected from a video camera or digital PVR. However since SD cards have a tiny processor and practically no internal cache, they start to show their limitations when hit with real filesystem use. A typical harddisc will have megabytes of cache plus highly optimised read-ahead and write-behind facilities through many decades of development of using spinning rust in real-world applications, intending to maximise both speed and capacity.
Is it worth it? Well, let’s say that when I want to transfer some animé episodes from my phone to my computer, it is quicker to write them to an external 500GB USB harddisc than to the connected 32GB SD card. Draw your own conclusions.

Another factor to bear in mind is that SD cards use flash memory, and as such are subject to the need to perform wear leveling to prevent wearing out particular sectors from too many writes. The official SD specification does not appear to mandate wear leveling, though decent SD cards should perform wear leveling (though this is rarely mentioned on any packs and on any brochures, so does it in fact happen?). However, if it does, it is likely to be very simplistic (SD is not SSD), and more than likely tailored at the behaviour of FAT32…which will not be the same as FileCore. Which, you know, rewrites the Free Space Map. A lot. Really a lot.

Oh, and in case the name isn’t a clue, it’s a rather important part of the logical drive structure. And you’ll only know your SD card has failed on that sector when the data read from it is corrupted (as far as I can see, the interface is rather crude and doesn’t allow for fault reporting).

With all of this in mind, while the Pi / Pi2 may be able to process faster, the use of inexpensive mass-market SD cards (instead of SSDs or spinning rust) may mean that the benefits of the extra speed are lost.

And certainly, take regular backups of your SD card’s contents!

AIUI filing system access speed is significant in compiling speed. Before native SATA (ARMX6, RapidO and Titanium) I’ve heard that the fastest RISC OS ROM compiling was done using an a9Home, I’m not sure if SDFS on Pi/Panda or ADFS an Iyonix was next in speed!

In my benchmarks (from a long time ago), IYONIX UDMA IDE was a lot faster than the A9home’s IDEFS. ADFS generally had the edge when handling a lot of small files, even on a Risc PC vs. the fastest SCSI cards of their time.

The Pi2, on the other hand, is a 900MHz ARMv7 (Cortex-A7) processor.

Not under RISC OS, it’s not: unless the specific _freq. lines are added to Config.txt, the Pi2 runs at approx. 600Mhz by default.

I now suspect the programmer who told me his a9Home compiled ROMS quicker than anything else he had, didn’t have an Iyonix! (I think he was comparing to his RiscPC, Pi, PandaBoard etc)

I now suspect the programmer who told me his a9Home compiled ROMS quicker than anything else he had, didn’t have an Iyonix!

The late Paul Vigay discovered that the A9home could outrun the Iyonix with very small files, I don’t recall the details but I was able to confirm it here. I think the catch was that it really was ‘very small files’.

Using DDE26 the slight snag with compiling ROMs on the A9home are all the ‘decompression failure’ errors. I did correct some of these, enough to get a build to start, and the A9home chugged along in a fairly leisurely manner. To be fair a build on a Mk1 Pi takes a while too, the A9home could be better. If the build environment could be fully fixed that is!

AIUI filing system access speed is significant in compiling speed.

That can certainly be the case as shown here by compiling ROMs on the Mk2 Pi’s RAM disc or on VRPC on the iMac.

Not under RISC OS, it’s not:

With RC14 it is – with the latest firmware however it now defaults to 600MHz and waits for the kernel to tell it when it is busy.

@Chris: I’m running RC14 already – are you saying that the additional cpu_freq, core_freq, adram_freq and force-turbo=1 lines in Config.txt are no longer required in order to run the Pi2 at up to full (900MHz) speed, providing I update the firmware to the latest versions?
PS: I don’t want to highjack the thread: should we start a new one?

I’m running RC14 already – are you saying that the additional cpu_freq, core_freq, adram_freq and force-turbo=1 lines in Config.txt are no longer required in order to run the Pi2 at up to full (900MHz) speed, providing I update the firmware to the latest versions?

No. I am saying that the RC14 SD card image (with its February 2015 firmware) runs the processor at ‘full’ speed (i.e. not overclocked but at nominal speed). The Pi Zero (nominal speed 1000MHz) requires November 2015 firmware and so will run ‘slow’ because new firmware runs slow except when the kernel asks for speed – RISC OS can’t do this yet – so to run at ‘full’ speed with the new firmware, you need config/txt to force turbo. This is OK for the Zero (it’s cheap and rated at 1000MHz) but may cause B2 to overheat (it’s only rated at 900MHz) and B+ (rated at 700MHz) and so needs some discretion regarding the actual speed you choose on hardware other than the Zero.