Debian - issues

omcomali.rhn at porcupinefactory.org omcomali.rhn at porcupinefactory.org
Fri Feb 19 22:20:22 CET 2010


On Fri, 19 Feb 2010 21:35:30 +0200
Timo Juhani Lindfors <timo.lindfors at iki.fi> wrote:

> omcomali.rhn at porcupinefactory.org writes:
> > It's installed on SD card with multiple partitions, but how to mount
> > the other partitions? I couldn't find the relevant device files in
> > /dev, except for mtdX, which are character devices and probably
> > related to builtin NAND anyway.
> 
> uname -r?
> dpkg -l udev?
> zgrep SYSFS /proc/config.gz | grep DEPRECATED?
> 
> My guess is that you have too old kernel which does not work with your
> udev.
Here are the results:

debian> uname -r
2.6.29-20100118.gita15608f2
debian> dpkg -l udev
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                   Version                Description
+++-======================================-======================-============================================
ii  udev                                   151-2                  /dev/ and hotplug management daemon
debian> zgrep SYSFS /proc/config.gz | grep DEPRECATED
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y

Doesn't Debian install its own kernel? uname -r on SHR gives 2.6.29-rc3

> 
> > Another issue: wlan. I'm using a 2.6.29 kernel (I don't know if it's
> > the kernel I use on my primary SHR or Debian-installed one). I know
> > there are some WiFi problems with it, but my research suggested
> > people were able to use it sometimes. In my case, the network device
> > is not even present... Can I do something about this?
> 
> We need to first know which kernel you have.
> 
> > Bonus question: why does Debian feel (and compile stuff) so much
> > faster than SHR?
> 
> No idea, you need to come up with some objective benchmarks :-)

The thing I noticed first is the 6MB smaller memory footprint in Debian. As openembedded is specifically designed for devices with less memory, I expected it to be better...
Compiling a program (peak memory usage during compilation >70MB) took twice the amount of time on SHR, but I don't think the swapping alone was the reason.
I can post the "time g++" and "free" output for both systems.

A synthetic benchmark (only the ending for brevity):
shr> openssl speed
                  sign    verify    sign/s verify/s
rsa  512 bits 0.023652s 0.002222s     42.3    450.1
rsa 1024 bits 0.134795s 0.007125s      7.4    140.3
rsa 2048 bits 0.884167s 0.025219s      1.1     39.7
rsa 4096 bits 6.150000s 0.092828s      0.2     10.8
                  sign    verify    sign/s verify/s
dsa  512 bits 0.021685s 0.024925s     46.1     40.1
dsa 1024 bits 0.070863s 0.083551s     14.1     12.0
dsa 2048 bits 0.254737s 0.304000s      3.9      3.3

debian> openssl speed
                  sign    verify    sign/s verify/s
rsa  512 bits 0.008735s 0.000819s    114.5   1220.9
rsa 1024 bits 0.041125s 0.002088s     24.3    478.9
rsa 2048 bits 0.237857s 0.006484s      4.2    154.2
rsa 4096 bits 1.604286s 0.022031s      0.6     45.4
                  sign    verify    sign/s verify/s
dsa  512 bits 0.007156s 0.007992s    139.7    125.1
dsa 1024 bits 0.019780s 0.023389s     50.6     42.8
dsa 2048 bits 0.063590s 0.075344s     15.7     13.3

Turns out Debian is over twice as fast as SHR! What's the status of fso and shr-apps compared to SHR?

Cheers,
rhn



More information about the community mailing list