Group Actions
Engagement
  • Author Author: Former Member
  • Date Created: Date Created
  • Views 1010 views
  • Likes 1 like
  • Comments 14 comments
Related
Recommended

Overview

Former Member

In this blog I hope to share with you some of the more interesting way points on the journey to designing the Raspberry Pi Hardware from the ideas kicking around 6 years ago to the overwhelming (for me and a few servers!) launch on Wednesday. 

 

I was lucky enough to be with element14 in Nuremberg when the RPi arrived from the UK for the noon on-stand launch.  Mike Powell from element14 deftly cabled the RPi, but gave me the 'honour' of powering it up. As many of you will know - it's a heart stopping moment (especially in front of a crowd of enthusiasts) until the kernel boot appears on the screen - it's either command line, terminal silence or smoke!

 

There is plenty of stuff on the Web about the Foundation and it's aims so I won't be repeating it here (unless asked).  There will be little discussion about software - we have lots of talented people in the team that can talk way more sensibly about that.  There is also an equally talented team on the hardware side and I hope I can encourage them to chip in with useful comment and correct me when I go off the rails.

 

I'm very happy to be sign posted to things that interest you - so let me know, and I'm sure they can be worked in somewhere.

  • in reply to Former Member

    agreed that there are many ways for a computer to seem slow besides a slow cpu.

    However, the RPi and SoC designers couldn't have done much about the slow

    interfaces (SD card, USB 2.0, 10/100 ethernet over USB, etc.,) within their budget,

    but it does seem like they probably could have integrated the ARM better, rather than

    just "bolting it on the side", where the L2 cache is pretty much useless to the cpu.

     

    Based on celeron benchmarks vs Pentium II, the L2 cache probably has about a

    20% effect on cpu intensive jobs.  That's what caused Intel to quickly put 128KB

    L2 cache on the celeron.

  • in reply to Former Member

    @coder27: Funny you should mention apt get.  I had a low-end Ubuntu server with a dual-core Athlon part in it that was taking ages to do package updates, and I was wondering whether the CPUs were really that slow.  I realised that the version of btrfs that I had used for the root filesystem was generating much too much synchronous disk activity.  Turning on write-behind caching on the disk caused apt get to run much faster, which showed that the CPUs weren't the bottleneck.  The real fix is either to upgrade to a later Ubuntu release with better btrfs performance or reinstall with ext4 as the root partition!  This is an example of how there are more ways for computers to seem slow than just having a slow CPU.

     

    apt get to an SD card will depend very much on the SD card's small write performance.  As far as self-hosted Linux compilation, I'd guess the same thing.  A USB external HD would be a very good idea for such a workload.

     

    A correction to my last comment: my recollection of Celeron overclocking was hazy - I had a 266MHz Celeron with no cache early on that I got running at 400MHz when I couldn't afford anything better, but the Celeron 300As that I used to play with had 128KB of L2 cache on-die.  This was still a lot less than the 512KB on the contemporaneous Pentium II, but when running at 450MHz the Celeron held up fairly well against a 450MHz PII.

  • in reply to Former Member

    Jason,

      About the only thing I remember from Hennessy and Patterson was Tomasulo this and Tomasulo that.

    It sounded to me like a cross between Han Solo and Mr. Sulu.

     

      My concern isn't so much the eye candy of a fancy GUI, I am presuming the GPU can eventually be

    harnessed for that.  I'm more concerned about mundane things like reports of apt get "taking ages",

    or web pages taking a long time to load.  It's also really useful for a linux box to be able to compile linux.

     

    I don't really understand why the L2 cache in the RPi is more closely attached to the GPU

    than the CPU.  Ideally, it would be readily accessible to both.  It probably wouldn't be cost effective

    to have a separate L2 cache for each. 

     

    My recollection of celeron overclocking is that it was easier to do without cache because the

    cache SRAMs were separate chips, and they had less overclocking headroom than the cpu. 

    I don't think that has any bearing on the ARM.

  • in reply to Former Member

    @coder27: yes, Turbo Pascal was a nifty bit of assembler hacking.  But the RPi is probably 100 times faster than the old 5MHz 8088 - they had pretty crappy memory systems too, you know... and their closest thing to a cache was a 4 byte instruction queue. :-)    If you want a full on compositing desktop with wibbly windows and translucent borders, it'll likely chug, but if kids get put off because the GUI isn't shiny enough then they weren't that likely to be really motivated at programming either.

     

    I've read Hennessy and Patterson, I know a fair deal about caches and CPU.  I also had an L2-lacking 300MHz Celeron which ran just fine at 450MHz and a 600MHz Duron which ran just fine at 900MHz; the fact that these chips lacked L2 meant that they tended to run cool enough and draw little enough current to run successfully at a 50% overclock, at which speed they felt pretty snappy, despite needing to hit memory more often than an equivalent Pentium III or Athlon would.  It really does depend a huge amount on the miss rate and achievable IPC of your workload as to how badly things will run with just a moderate sized L1 cache.  Would the RPi's SOC be as cheap, or run the ARM as fast, if the CPU had a bigger, better L2 cache?

     

    I will say that as a sysadmin these last 16 years, I've seen a lot of ways in which a machine can seem slow at doing one thing or another that have proved to be absolutely nothing to do with raw CPU speed; as well as some that have... looking forward to seeing this sluggish RPi for myself someday! image

  • in reply to Former Member

    The reports we have heard so far say the RPi is "sluggish".

    Sluggish computers are not fun to use, which defeats the purpose

    of getting kids excited about programming.  Yes, you can

    minimize the problem by using light-weight versions of IDE's,

    programming languages, word processors, web browsers,

    window managers, etc., but it would be a lot better to be able

    to use more mainstream software.

     

    Modern software is quite extensive in its memory usage,

    and benefits greatly from memory caches.  My understanding

    is that although it is possible to access the L2 cache from

    the CPU, it is not practical to do so, because the L2 cache is

    directly connected to the GPU and takes longer to access

    from the CPU.

     

    Turbo Pascal was quite an anomaly, with exceptional

    performance due in large part to being written in assembly,

    which is not true of most modern software.