First unboxing pictures... maybe?

That last post should have given you a few ideas Gizmo... assuming that you needed some, that is!

Anyway, it's getting a bit late now here in the U.K., and I'm off to bed.

I am sure though that you will be working all night with your new 'baby', and I will look forward to reading a full report in the morning!

Ideas are always welcome, time permitting.  Most of this Linux is new to me, closest for me was a DRS6000 about 12 years ago, and I was only writing code on it. You'll need to be patient and type S-L-O-W-L-Y for me, but glad to answer what/when I can.

My SD Card is:

Samsung 8GB Class 6

MB-SP8G

Running the "debian6-17-02-2012" image.

From plug to terminal login prompt (not into LXDE), whilst connected to Ethernet, startup time is about 36 seconds.

Screen resolution using xrandr

1920x1080

Memory using free -m

total 186

used 37

free 148

shared 0

buffers 4

cached 20

hdparm -Tt /dev/mmcblk0p1

Timing Cached reads:  306MB in 2.00 seconds = 152.92 MB/sec

Timing buffered disk reads: 32MB in 3.07 seconds = 10.42 MB/sec

My very preliminary thoughts are:

Overall response feels capable, but not blisteringly fast when running LXDE.  As the first Debian image, I would imagine there is scope for improvement with future tweaks and builds, but certainly not dissapointing for something so small and cheap.

So far the only real indication to me that this is such a low cost device, is the quality of the SD Card socket.  Having been used to the slick metal spring loaded versions in the past, this is a rather simple plastic friction affair.  If I find myself swapping cards a lot, I might decide to invest in an SD Card extender.  Otherwise, the only other weak point is the micro USB socket, but that should be no surprise to anybody that has used a device with one of these before.  Best to avoid heavy hands and if unplugging a lot (to disconnect the power), then use the other end of the cable, or a power switch.  A careful blob of epoxy glue over the socket and surrounding board would probably strengthen things up too, but I won't be putting any near mine.

I haven't even scratched the surface, but what I like best so far is it's multiple personalities.  It is just a matter of swapping the SD Card and in a few seconds it does something different.  I am keeping plenty of card backups at regular intervals, it is a simple task and makes it so easy to roll back if something goes wrong.  It is such a simple and obvious thing, but I hadn't anticipated how useful/empowering that would be as a linux noob.

I don't feel like I have done very much this evening, but really need some sleep now.  Well, I will try anyway.

Great stuff GizmoB73, it's very cool to read your experiences.

And I echo what jacques_nil said, nobody here will get annoyed at anything you write, good or bad, newbie or expert, it's all useful input on the Pi experience and interesting.  All the people who have the pettiness to get annoyed are on the official forum, which encourages intolerance.

I ran up the Fedora 14 Remix distro for the Raspberry Pi under QEMU emulation a little while back, and reported on the info revealed by running some standard commands, see here:

    http://www.raspberrymod.com/viewtopic.php?f=48&t=511&p=997#p997

If you have a moment to run the same commands on your live hardware and paste the result, it would be interesting to see how it compares with the emulation.  The fact that mine was Fedora and yours is Debian will make some difference, but most things should be identical.

Morgaine.

what I like best so far is it's multiple personalities. It is just a matter of swapping the SD Card and in a few seconds it does something different.

Many moons ago there was a terminal type PC called an Einstein, it didn't have an OS, one purchased - 51/4" floppies that contained the emulated OS (such as they were) of your choice.

Thank you for he post Gizmo, that is interesting.

10.4 MB/s for the disk read speed looks quite low for a class 6. Should be around 20MB/s

Do you have the write speed ?

Another nice and simple test would be to try some HD video steamig over the network,

this would invalidate (or validate) the therory that the shared ethernet over usb is a huge bottleneck.

Thanks Morgaine, I will try to get around to this for you.

Jacques_nil: here is the full Bonnie output for that card:

1.96,1.96,raspberrypi,1,1333224324,368M,,23,99,8722,25,4698,14,360,99,13419,13,119.8,18,16,,,,,1654,61,+++++,+++,2739,66,1847,67,+++++,+++,2080,50,830ms,3339ms,940ms,30000us,69999us,610ms,989ms,10000us,10000us,1069ms,10000us,2014ms

As for the HD Video streaming... easier said than done.

I am currently chasing my tail trying to get something to work.  VLC doesn't work because it needs a specific version of alsa-lib.  It would appear that on debian this is called libasound2 and is the latest version when I checked, so not sure how to get that working.  I am guessing that I probably need an older version, and that VLC isn't pulling that in.

I then thought I would try a different media player, but it looks like "debian-multimedia-keyring" is pretty fundamental and I cannot find a source for it that works on the Pi.

I guess these are just noob issues on my part, and I am learning loads each time I hit another dead-end.

OK, got "debian-multimedia-keyring" to install manually by downloading the .deb file and installing with dpkg -i.

I then installed SMPlayer and Gnome MPlayer.  Tested with a standard definition file streaming from my NAS over my Gigabit backbone.  Playback had no audio and was at best running at one third of the frame rate it should have been.  I have no doubt that the R-Pi is capable of better than that, but something is obviously not right.

I wonder if it is the debian build?

Once again, thank you

reordered

Sequential disk write:

with putc() : 23Kbytes/sec, cpu overhead 99%          <- horrible, but this is due to SD card that do not like small writes

with write() : 8.72MB/sec, cpu overhead 25%

read,seek,write : 4.7MB/sec, cpu overhead 14%

Sequential disk read:

with getc(): 360Kbytes/sec, cpu overhead 99%

Block read: 13.4MB,, cpu overhead 13%                   <- better than your first test

Seek time: 8.3ms ( = 1 / 119.8)

Read perfs. are not bad, but the poor write perfs.are for sure 100% due to the SD, wich are optimized for writing big block of data.

That should have no effect on applications that read a lot and write few, but when running multiple tasks, if the OS start swapping to the SD it could feel like snail driving.

I wonder if the results will be better with a SSD attached to the USB port, but is it possible to boot from usb ?

It's not possible to boot from USB.  But, a cheap SD card can be your "boot disk" and then load the rest and run from the USB HDD.  (Kinda like the olden days of booting Linux from a floppy.)

Hi Gizmo,

Instead of mplayer, you might have better luck with ilplayer.

It is apparently a custom player supplied with the RPi that Paul Maunders

used (he bought beta board #8 at the January eBay auction) and blogged

about it at:

http://www.reddit.com/r/raspberry_pi/comments/oicyr/i_have_a_raspberry_pi_beta_board_ama/

and

http://www.pyrosoft.co.uk/blog/2012/01/15/raspberry-pi-playing-a-1080p-video/

He found ilplayer to be much faster than mplayer, but also had some trouble with audio.

He was able to get sound using

  http://www.808.dk/pics/video/gizmo.mp4

He disappeared after being asked about watching videos from hulu at 1080p,

so don't try that. 

"Playback had no audio and was at best running at one third of the frame rate it should have been."

sounds like it might not be using any hardware accelleration (GPU) at all ?  If it can play 1080p MP4 files, SD should be easy...

"Playback had no audio and was at best running at one third of the frame rate it should have been."

sounds like it might not be using any hardware accelleration (GPU) at all ?  If it can play 1080p MP4 files, SD should be easy...

apparently none of the standard debian packages are accelerated,

only ilplayer.   Paul got VLC to load, but it was too slow.

Apparently AAC sound is supported, but not AC3.