Boot time

Previously I had an Rpi2 with RISC OS and an Rpi3 with Raspbian. Both took the same time for bootup – from switch on to a useable desktop. Now that I have replaced the Rpi2 by an Rpi3 RISC OS boots up faster, by about half a second.

I wait 19.35 seconds from poweron to Desktop on RC15

Just tested mine. RC15 on Pi3, 11.2 seconds. I’ve not tried with the hard drive (USB, powered via the Pi) unplugged, not sure if that would make any difference.

Why’s mine so high? Did you use networking when testing?

Why’s mine so high?

What model Pi?
What class SD card?

I was vague. It’s Pi3 and U1 class

DHCP or not is often responsible for major boot time differences. And if DHCP is used, how fast your DHCP server responds. Other things is having USB hubs connected which are switched on at the same time and take a while to enumerate their devices. And directly connected USB devices which are slow in responding/configuring.

how fast your DHCP server responds

5 seconds! That’s super slow. I’ve never seen it take longer than 1 second to hand out leases. Seams to only be RO clients too.

May 18 10:21:19 x41 dhcpd⁹²⁵⁵¹: DHCPREQUEST for 10.133.7.37 from xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:19 x41 dhcpd⁹²⁵⁵¹: DHCPACK on 10.133.7.37 to xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:19 x41 dhcpd⁹²⁵⁵¹: DHCPREQUEST for 10.133.7.37 from xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:19 x41 dhcpd⁹²⁵⁵¹: DHCPACK on 10.133.7.37 to xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:19 x41 dhcpd⁹²⁵⁵¹: DHCPREQUEST for 10.133.7.37 from xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:19 x41 dhcpd⁹²⁵⁵¹: DHCPACK on 10.133.7.37 to xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:19 x41 dhcpd⁹²⁵⁵¹: DHCPREQUEST for 10.133.7.37 from xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:19 x41 dhcpd⁹²⁵⁵¹: DHCPACK on 10.133.7.37 to xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:19 x41 dhcpd⁹²⁵⁵¹: DHCPDISCOVER from xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:19 x41 dhcpd⁹²⁵⁵¹: DHCPOFFER on 10.133.7.37 to xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:23 x41 dhcpd⁹²⁵⁵¹: DHCPREQUEST for 10.133.7.37 from xx:xx:xx:xx:xx:xx via bge0
May 18 10:21:24 x41 dhcpd⁹²⁵⁵¹: DHCPACK on 10.133.7.37 to xx:xx:xx:xx:xx:xx via bge0

If you deduct DHCP slowdown, I guess its 14 seconds.

I’ve just got keyboard, mouse and Lacie hard drive connected directly into the Pi – used to have a hub on the Pi1 of course. I’m using DHCP but I don’t know how to tell how quick it’s responding. It’s connected via an over-the-mains link to the DHCP server.

I find that the simplest thing is to disable DCHP.

Why? Simple. My Pi (1) boots in around 12 seconds. My Livebox takes something closer to four minutes to get itself going. RISC OS can’t do DCHP at arbitrary times, so the simplest thing is to set up a fixed IP address for the Pi, so it’ll be ready and waiting for the Livebox…

Got 13.34 boot time with manual IP

I do at times wonder… What was the reasoning behind the changes to the start-up sequence – large banner and DHCP slowing down the time it takes to get to the desktop? My gut feeling is that this particular part of the boot sequence has gone from having a minimalist design and being quick, to slower and bloated. Especially if we ignore the passage of time and the improvements to technology, I would say that the RiscPC start-up sequence, as Acorn made it, was akin to switching on a TV and much quicker than it is today, esp. on a Pi3. My RiscPC with a network card didn’t slow on start-up waiting for a DHCP response.

In the context of the fantastic work being done on the OS it is a small thing, but for me important.

I don’t seem to need to disable DHCP. The Pi’s booting up in under 12 seconds including DHCP. DHCP provided by a bog standard Virgin box.

Edit: Ah. Perhaps the difference is that our Virgin box is always on, serving everyone else in the house (and my Mac)?

11.96 is the fastest I can push it as a noob.

My RiscPC with a network card didn’t slow on start-up waiting for a DHCP response.

Did your RiscPC even run a version of RISC OS that supported DHCP? ;-)

large banner

I think the motivation here was to try and avoid scaring off all the potential new users by showing them a screen full of gobbledygook when they power on the system (or, depending on the screen mode that was used during boot, a screen that’s 99% black and 1% tiny unreadable gobbledygook in the top-left)

Of course if you don’t use a Pi (or *Unplug BootFX) then you won’t have anything to worry about.

DHCP

A symptom of our neglected network stack.

• There are probably some bugs or poor design choices in the DHCP implementation which cause it to take longer than it should
• In the past people have complained about the DHCP not picking up some settings correctly (gateway settings?)
• The boot sequence must block until DHCP completes, because various bits of the network stack/boot sequence don’t work very well with dynamic network reconfiguration (e.g. !Configure asks you to reboot when making network changes), and DHCP itself seems to be a manual process (after obtaining a lease, the network stack will automatically renew it, but if no lease was obtained during the boot sequence then it won’t try and obtain one until you manually kick it)

I would say that the RiscPC start-up sequence, as Acorn made it, was akin to switching on a TV and much quicker than it is today, esp. on a Pi3.

If I do the same on the RPi(whatever revision) as I did on my Risc PC (i.e. static IP), the Pi’s are a lot faster. The Risc PC took at least 30s to boot up. But that’s down to SD cards being faster (access time!) than SCSI spinning rust.

My RiscPC with a network card didn’t slow on start-up waiting for a DHCP response.

Maybe it didn’t do DHCP? This was an invention in Select 1 (RISC OS 4.29 IIRC). But you could be right, I always felt that the Select DHCP stuff was a lot faster than the RO5 (IYONIX pc back then) DHCP stuff.

I think the Boot application is pretty slick these days. Relatively recently (within the last couple of years?) Someone gave it a good clear out and put some effort into testing on all ‘Acorn’ versions of RISC OS, right back to 3.1.

A large part of the delay on the Pi is the slightly rough DHCP implementation. Maybe when/if the Internet stack is updated, improvements will follow? You can always configure static IP or disable networking entirely.

I found a Risc PC could take a while. The Boot app was less optimised (particularly the 1994 versions) and the disk drives much slower.

Maybe I’m misremembering but I thought RISC OS 3.7 supported BOOTP?

I was vague. It’s Pi3 and U1 class

Nota, the fastest cards are sometimes the slowest for multiple accesses with small files.

the fastest cards are sometimes the slowest for multiple accesses with small files.

After reading some filecore documentation, I don’t think that’s much to worry about. Annoying thing is card slot appears capped at 30MBps where as USB 2 is 60MBps (assuming a full 480Mbps) so might try out an HDD over USB. (Since HDDs average 80-160MBps, so why waste an SSD?)

Reminds me – I need to find a good USB stick for my satellite receiver. NHK World is 1080i and runs to a little over 3GB per hour (more than BBC One!), and my current new USB stick just can’t keep up.
Any recommendations?

my current new USB stick just can’t keep up

That’s weird. I assume you mean for recording. I’ve never seen a USB drive that cant write 3GB in an hour. I’d have thought any would’ve been fine.

By my rough calculation, that’s about a megabyte per second. Which I suppose would be ~8 megabit?
Perhaps it is less the data rate, and more the fact it must do this continually with no hiccups. I see when copying large files from my computer that it seems to go in bursts…

I see when copying large files from my computer that it seems to go in bursts…

I think that’s more because of fragmentation, so it needs to jump to next free space without overwriting other files.

Annoying thing is card slot appears capped at 30MBps where as USB 2 is 60MBps (assuming a full 480Mbps)

AIUI SDFS is able approach the maximum hardware speed. USB on RISC OS is far slower than the hardware is capable of.

Mmm I just looked here to see if I can quantify the above statement and Chris’s results seem to say a different story. It says HD Read is actually faster on a USB Pen than an SD card though write and FS Read/Right are much quicker on SDFS. (Hard drive figures are for an SD card so not a useful comparison)