element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      • Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Raspberry Pi
  • Products
  • More
Raspberry Pi
Raspberry Pi Forum Initial Thoughts and Experiences
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Raspberry Pi to participate - click to join for free!
Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 22 replies
  • Subscribers 679 subscribers
  • Views 2953 views
  • Users 0 members are here
  • raspberry_pi
Related

Initial Thoughts and Experiences

Former Member
Former Member over 13 years ago

Three days ago my Pi arrived via UPS and I've been playing around with it a bit. I thought I'd write my comments about it for the benefit of those interested and so that I can receive some tips/ideas.

 

First and foremost, I apologize about the lack of pictures, my digital camera broke a few months ago and I never replaced it since I don't take a lot of pictures, I can put some from my cellphone later on if people are curious but there are a lot of pictures out there already.

 

I ordered my Pi on March 12th from Newark for delivery to New Mexico in the U.S. (I live on NMSU's main campus) and it arrived on the 10th of July at approximately noon (I took the day off from my job as a research assistant, informing my professor that I was expecting a new "tinker toy" to come in). This was after three weeks of my shipping date changing at the last second to exactly one week later (it was always listed to be shipped on a Thursday, and come that Thursday morning, would be pushed to the Thursday exactly one week later).

 

When it finally did ship (element14 listed it as "Complete" and gave me a tracking number) I noticed a charge on my credit card of $50.75 from element14 when my order listed my price as $44.76. I contacted customer service and things got a bit weirder, according to the customer service rep. I was only supposed to be charged $42.05 (which is what my invoice says, but my order still listed the previously quoted price). Eventually they gave me the contact info for their credit department, who I contacted by email and still have never gotten a reply (but the charge was fixed to the lower price, so I never bothered investigating it any further).

 

My Pi did not arrive in a box with "Raspberry Pi" written on it like many others seem to have gotten. Mine came in an envelope with bubble wrap on the inside from element14 and upon opening it there was a tiny white box no larger than the Pi itself, with the Pi being inside of that.

 

Fortunately my power supply arrived at the same time (same UPS guy), I ordered a cheap Motorola power supply that was listed as being compatible (on the elinux wiki I believe) from Amazon.com:

http://www.amazon.com/gp/product/B004EYSKM8/ref=oh_details_o02_s00_i00

 

Unfortunately, my desktop's keyboard uses an old PS/2 connector (been so long since I hooked it up I had forgotten and just assumed it was USB) which is what I had planned on using with my Pi, so then I drove around town looking either for a cheap USB keyboard or PS/2 to USB adapter (my dedicated USB keyboard for the Pi arrived two days later), I ended up buying a cheap USB "Onn" brand keyboard from Wal-Mart for $9 because all the PS/2 to USB adapters I could find in-store (not online) were $21+ and the cheaper keyboards were all wireless (I prefer wired, batteries always seem to die at the most inconvenient of times while I never need to change the wire on something wired unless for some reason I happened to cut the wire).

 

So great, I was up and running, mostly. I still needed to write an image to an SD card run that. The 4Gb SD card I had ordered specifically for the Pi still hasn't arrived, but luckly I had an extra 4Gb microSDHC card from an old phone as well as a microSD to SD adapter "sleeve" (the microSDHC card slides into it and then can go into SD slots) which I put the Arch Linux Arm image on (I will be testing the other distros later, just more familiar with Arch at the current moment).

 

My monitor connects to the Pi via HDMI and runs at 1680x1050, which the Pi almost did on its own. For some strange reason Overscan was setup and I was getting roughly 15 pixels on all sides as a buffer, I have no idea why this is set as I've never run into this on anything else (I've used many distros of linux, and during the school semester work for my university's physic's department as an IT Assistant, mostly dealing with setting up computers for the graduate students and helping them with any problems they run into since linux is almost exclusively used for research). This was simple enough to turn off, just went into the /boot directly and edited the config.txt to disable overscan and rebooted, nice and normal again.''

 

I'm enjoy running a minimal linux install personally, mostly because I deal with older hardware on a regular basis (and I've never been lucky enough to afford some ultra powerful computer, usually I search around every 5 years for a new machine with a budget of about $500 total for a desktop and $400 total for a laptop which is good enough for day to day use but not good enough to run any recent games). Currently on my laptop I run DWM and thought it would be pretty good on the Pi, using the standard 192/64 CPU/GPU memory split and installing DWM left me with very little memory running while idling (when idle I'm not sure how much I was left with, but idle with Conky running and being piped to dmenu every 2 seconds left me with only about 1Mb of memory, so my assumption is to either not run Conky or to update it much less frequently). Opening up a terminal would have about a 3-4 second lag from pressing the key combination of Alt+Shift+Enter (DWM key setup to open uxterm, I changed rxvt with unicode support). Didn't run as fast as I had liked, opening up Surf to browse the web would take about just as long (3-4 second lag to press Alt+P in order to enter command into dmenu and then 3-4 second lag for surf to open, about 2 seconds to load google.com from the university internet connection). That isn't all that bad, but not as responsive as I would've expected (I know, everyone talks about how weak the machine is, but I used a Pentium 2 machine with 128Mb ram up until 2003 (running Windows 9x, hadn't discovered linux yet) and then a Pentium 3 750 Mhz machine with 256Mb of ram with Windows XP and Linux up until 2007 (discovered linux in 2005) with better performance on each then than with the Pi now, so it can't be the hardware like how everyone enjoys to blame, it is most likely a side of effect of software needing to be compatible with newer standards). Heck, my android phone runs at 700Mhz (Huawei Ascend 2).

 

Anyway, after that I installed DVTM (basically a console version of DWM) and dropped X entirely, which runs great after you delete /etc/profile.d/locale.sh (this is recommended in an old Arch Linux announcement, always end up forgetting all the steps to take when updating a fresh Arch install as it involves sifting through the annoucements from the past and checking to see if they apply or not anymore) (otherwise DVTM displays a bunch of gibberish where it would typically draw lines and write info about each "window"). I even got retroarch (a multi-platform, multi-console emulator front end based off the libretro emulator cores [only managed to get SNES emulation running using the pocketsnes core supplied by ToadKing's github]). Took a while to get running, an embarrassingly long time actually. I was up all night (forgot to sleep) messing with it, primarily because SDL didn't want to run (kept trying to make a surface along the lines of 159000x159000, so I spent a considerably amount of time sifting through the retroarch source trying to figure out what was causing this since nobody on their forums seemed to have encountered the same problem and I wanted to be sure I did an exhausted troubleshoot before bothering others on the forum with my problem). Unfortunately I'm not that familiar with SDL and am honestly not much of a programmer (typically write short codes to collect data, calculate something in either Fortran or MatLab, or simulate a system using Fortran, not much C experience), and eventually gave up. After getting some much needed sleep I tried again with a fresh download of retroarch from ToadKing's github and compiled it (had to use the --disable-sinc feature when running ./configure otherwise it wouldn't compile, something about alinged_alloc being statically defined and then non-statically defined later in the audio/sinc.c file, nobody else seemed to have this problem and I only did a quick sift of the file to try to see if my limited programming skills could resolve this issue, which I couldn't). Also needed to link a folder in /opt/vc (cannot remember which, it is listed in their forum) that rpi.c needs while compiling otherwise it will not detect that you are using the program on a Pi (runs on PC, Mac, XBOX 360, PS3, etc..). After all that is said an done, and making a retroarch.cfg to my liking (changed the input settings) I was able to get it to work, but it breaks whenever I turn on the Audio Sync setting (which is recommended in the default config file). Sound is hit or miss, since the Pi's sound driver is still in an early stage (I believe either pre-alpha or alpha, can't recall) and works for the first 2-3 seconds of running Super Mario Bros. (the game freezes when the first black box message appears on the first level). I've been able to run Ogre Battle with no issues aside from cruddy sound, as well as Super Mario RPG (which runs surprisingly well considering Super Mario Bros. freezes and RPG runs the system much harder) with relatively good sound. EarthBound runs like a champ except when characters enter or leave your party (lags for a couple seconds before the message pops up, but does not freeze) and sound works fine indoors but becomes pops and hisses in the outside world and when going through doors. Chrono Trigger runs fine with no lag but sound does not work at all for me.

 

I'm mostly testing what the Pi is able to do based off of what it currently available, not off of what I could program it to do. I also installed Yaourt, which is much easier as you just use pacman -S yaourt instead of the round-about way you need to on regular Arch Linux and most packages install fine if you edit the PKGBUILD, particularly the "arch" line and add in "arm" it'll work about 7/10 times. Can compile most of the programs I tried to so long as I was in the console, with only one "window" in dvtm open and the 224/32 CPU/GPU memory split (no swap!).  I couldn't manage to get cups to work for my printer, I have a Brother MFC-9010CN color laser printer on my network that used to be a pain to set up (roughly 2 years ago) but is now a piece of cake as support for it has improved greatly. Unfortunately adding it using lpadmin -p [name] -E -v lpd://printer-ip-address/binary_p1 -m [ppd file for printer] would set up the printer, but it would only print blank pages with some faint multi-colored lines on it (using lpr [file] after the printer was made the default using lpoptions -d [name]). If I used the option to print the raw file (can't remember the lpr option at the moment) it would print the first line of what was in the file, but upon going to the next line would continue (didn't recognize the return, perhaps if the file was formatted with a "\n" at the end of each line, but did not test, ended up giving up since I don't need it to print, just wanted to see if I could make it print). The cups web interface could not install the printer, it would always fail at finding the "drivers" giving a failed message and a success message at the same time and not adding it to the list of printers.

 

Today I was planning on trying out the Raspbian image on a different SD card and playing with that, to see what I could get it to do. That is my overall experiences so far. I hope this either helps someone, or sparks an interest in someone (that way I'm not just writing it to "hear myself talk", so to speak) and I'd be happy to answer any questions or try any suggestions anyone offers (or test any ideas for those who have yet to get their Pi). Also, I have been able to ssh from my laptop to my Pi, providing I was on the exact same network (I sort of have a 2 network setup at home, my main router is downstairs as the is where the "live" phone line in student housing is for the dsl modem to connect to, but my office is upstairs so I have an Amped Wireless Range Extender SR150 (or 1500, cannot remember how many 0's in the name) that my desktop is plugged into (and the Pi is plugged into) which makes a "second" network that runs off the "first" network wirelessly (better than running Cat5 cables upstairs along the walls).

 

I'll try to document more of my experiences with the Pi if anybody is interested, and as I said I'm willing to take requests.

  • Sign in to reply
  • Cancel
Parents
  • morgaine
    morgaine over 13 years ago

    Good write-up, Alexander.

     

    Nice to see you get Arch up.  I haven't tried it yet, but I am intending to do so once Debian is fully operational on my Pi.

     

    I too have some old Linux machines on my network, including a 400MHz AMD-K6 with only 64MB RAM and a 750MHz P3, and just as you report, they both seem a lot more responsive than the Pi.  I haven't examined exactly what makes them faster yet, but I expect that in part it's the hard disk drives.

     

    Have fun. image

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to morgaine

    some known reasons for slowness are:

       1) SD card slowness;  some firmware improvements have been

    made recently, but probably best to put root filesystem on a usb

    stick or usb hard drive;

       2) L2 cache is connected to GPU, not CPU, so doesn't do much

    at all for CPU;

       3) GPU isn't used for X Window acceleration, or for music;

       4) hardware floating-point isn't used, except for Raspbian OS

    and Gentoo;

       5) USB causes 8000 interrupts/second even when idle, using up

    about 20% of the CPU;

       6)  ethernet goes through USB hub, which is polled.

       7)  lack of RAM can cause swapping, or can reduce I/O buffers;

       8)  libc has a slow version of memcopy (being fixed);

       9) USB is only 2.0, not 3.0; ethernet is 10/100, not 1000;

    10) ARM11 is pretty primitive, introduced in 2002;

    11)  Debian is built for ARM v4, not v6;

    12) unaligned memory accesses may be slow.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    Okay, I've only recently began using ssh (access work computers from home as well as sftp to move files between computers on the same network at a higher speed than copying over via a usb stick) and was unaware I could run X applications remotely. I was only aware that I could issue console commands and run console programs. Today just keeps becoming more and more progressive and has offered me some interesting ideas to play with in my mind as I wait to do more experimenting/playing. Don't use windows, haven't for a couple years and don't need to (you'd be amazed at how much the physics department of my university uses linux, especially when most of the other departments use windows).

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    hardfloat:  I think javascript will be a big win, because all numbers are

    stored as floats. 

    Is there any reference for that ?   I've seen it repeated several times but with no reason as to why it must be true for all implementations of javascript. Seems like it should be an implementation specific bug.

    But, given that I don't use javascript (no X installed, no browsers) what else uses floating point enough to be a problem ?  For example, would this same design flaw be present in python ?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    disabling usb also disables ethernet, so you have to use GPIO

    for the console uart.

    I'm considering that a model A, an enc424j600 or similar for ethernet, and disabling usb altogether might end up being a sane option.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    http://oreilly.com/javascript/excerpts/learning-javascript/javascript-datatypes-variables.html

     

    I don't have first-hand experience with javascript implementations, but this is what I've read.

     

    Python doesn't have the same problem.  It has 4 builtin numeric types, int, float,

    long, and complex.

     

    I don't know what other applications have "hidden" uses of floating point.

    Probably some graphics apps do.   When raspbian get widely used soon,

    I'm sure there will be lots of reports on what's faster and what's not.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member
    I don't have first-hand experience with javascript implementations, but this is what I've read.

    Oh dear. It's no wonder the next generations have no interest in programming with a confused mess like that. Strangely enough, I stumbled on some similar stupidity recently when asked to help a friend with some php.

    Give me a strongly typed language any day..

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • johnbeetem
    johnbeetem over 13 years ago in reply to Former Member

    coder27 wrote:

     

    some known reasons for slowness are...

    One performance issue I wonder about is how well ARM11 deals with long internal pipelines versus a given Intel/AMD x86.  ARM11 has an 8-stage pipeline according to Wikipedia, so a load/store, (conditional) branch, or other interlock can cause a serious performance hit unless the hardware can compensate for it with out-of-order execution and compilers that optimize for it.  Intel typically solves performance problems by throwing more transistors at them.  My limited understanding of ARM performance optimization is that you can buy good ARM compilers and performance profilers and adjust your programs to get excellent performance.  This is well worth it if your ARM application is a cell phone or other mobile device that you expect to manufacture in the millions, so spending some time optimizing your software so that it runs well on a cheaper core is well worth it.  OTOH, ARM does not have much experience in the general-purpose computing world where user X just wants to compile and run program Y without tuning it for a particular processor.

     

    One of the keys to good ARM performance is to use conditional instruction execution instead of conditional jumps, to prevent bubbles in the pipeline.  I don't know how well GCC generates this kind of code.

     

    Cortex-A15 incorporates many of the known methods for pipeline mitigation, which makes the core more complex than earlier ARMs.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • jamodio
    jamodio over 13 years ago in reply to Former Member

    Be careful with the Microchip ethernet controllers, I use them a lot and they are also power hungry and have some limitations.

     

    -J

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to Former Member

    here are some raspbian benchmarks

     

      http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • mgt6910
    mgt6910 over 13 years ago in reply to Former Member

    Very encouraging results on the benchmarks for raspbian, but I'm not sure about the percentages.

    adama claims a best case improvement of 40%,but for example OpenSSL RSA improved from

    1.00 to 2.17. That's better then 100% , isn't it ?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to mgt6910

    the only way I can make any sense of the 40% is that 1.00 is around

    40% of 2.17, but that obviously is a bogus way to figure improvement.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Reply
  • Former Member
    Former Member over 13 years ago in reply to mgt6910

    the only way I can make any sense of the 40% is that 1.00 is around

    40% of 2.17, but that obviously is a bogus way to figure improvement.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube