Marc's Public Blog - Linux Hacking


All | Aquariums | Arduino | Btrfs | Cars | Cats | Clubbing | Computers | Dining | Diving | Electronics | Exercising | Festivals | Flying | Halloween | Hiking | Linux | Linuxha | Monuments | Museums | Outings | Public | Rc | Sciencemuseums | Solar | Tfsf | Trips

This page has a few of my blog entries about linux, but my main linux page is here
Picture of Linus


Table of Content for linux:

More pages: April 2023 March 2023 September 2021 May 2020 January 2020 January 2019 December 2018 March 2018 January 2018 September 2017 January 2017 October 2016 August 2016 July 2016 June 2016 March 2016 February 2016 January 2016 May 2015 March 2015 January 2015 October 2014 May 2014 April 2014 March 2014 January 2014 November 2013 September 2013 May 2013 March 2013 January 2013 December 2012 August 2012 May 2012 March 2012 January 2012 December 2011 August 2011 July 2011 January 2011 October 2010 August 2010 June 2010 April 2010 March 2010 January 2010 December 2009 November 2009 September 2009 August 2009 July 2009 May 2009 January 2009 December 2008 November 2008 October 2008 January 2008 November 2007 August 2007 July 2006 January 2006 August 2005 April 2005 November 2004 March 2004 February 2004



2009/12/20 Disk and Crypt Benchmarks
π 2009-12-20 01:01 in Linux
I migrated my main laptop from a Z61p to a slightly thinner W500. The big plus was not the slightly better CPU or support for more than 3GB of Ram, but the fact that it lets me select a lower performing Intel G450 video card instead of the fast power hungry and not well supported ATI one.
I've managed to get from an uncertain 25W to a 10W by switching to the Intel driver and turning off everything I can outside of the screen. Amazing!

Anyway, the point of this post was to talk about benchmarks. I was curious to know how much faster switching from a 5400RPM drive to a 7200RPM drive would be (I have a 500GB drive, SSD in that size is not too much an option yet, and I'm not really hurting for speed anyway).
The next thing was to see how much dmcrypt was slowing me down.

Ready for it?
dmcrypt gave me virtually no slowdown on a kernel build and a mere 4-5 seconds to get Enlightenment started from boot (about 40 seconds from lilo prompt to Enlightenment loaded and opening its screen with Eterms already loaded). So, I really don't care about 4 seconds of boot time if it makes virtually no difference once the system is running. The best part was that switching from a 160GB 7200 RPM drive without dmcrypt to a 500GB 7200 RPM drive with dmcrypt, opening a maildir folder with 50,000 messages actually went DOWN from 50-ish seconds to 16-ish seconds!

7200 vs 5400RPM gave a modest boot speed improvement (8 seconds) and considering I boot once a month on average, it's really not something I care much for. Opening a maildir folder is faster by a few seconds (15%-ish) but nothing earth shattering. Building a kernel is maybe 20 seconds faster. All this to say that 7200 RPM is not something I would kill or pay load of extra money to get.

Anyway, switching from my old 5400RPM drive with dmcrypt to a 7200RPM drive with dmcrypt (all using ext4 on a freshly layed out filesystem).

Oh, the other test I did quickly was to see whether HIMEM64G (enabling PAE and a 3rd level indirection required for me to see 64GB instead of 3GB), and indeed HIMEM64G is a tad slower than running without HIMEM4G as I had feared, but not by a whole lot (looks like less than 5%), so I'm willing to ignore it.

Raw data below. It shows time from lilo prompt to X starting, and E fully launched as well as how long it takes to open my rcvd and snd maildir folders on a cold cache. Then, I build a full featured kernels with 4 concurrent threads.

5400 RPM 160GB seagate, no dmcrypt, HIMEM64G

boot1: 27 X start / 50 E ready / 0:58 rcvds / 0:52 snd

kernel build #1: real 23m24.829s user 39m59.454s sys 4m16.530s

kernel build #2: real 22m47.524s user 39m52.953s sys 4m16.569s

boot 2: 23 X start / 41 E ready / 0:58 rcvd / 0:34 snd

kernel build #1: real 23m3.003s user 40m2.183s sys 4m17.200s

kernel build #2: real 22m38.859s user 40m0.710s sys 4m21.401s

boot 3: 25 X start / 46 E ready / 0:58 rcvd / 0:34 snd

kernel build #1: real 24m19.828s user 40m1.283s sys 4m35.624s

kernel build #2: real 23m51.198s user 39m58.137s sys 4m37.391s

boot 4: 23 X start / 42 E ready / 0:60 rcvd / 0:33 snd

----------------------------------------------------------------------------

7200 RPM 160GB seagate, no dmcrypt, HIMEM64G

boot 1: 21 X start / 36 E ready / 0:48 rcvd / 0:25 snd

kernel build #1: real 23m22.448s user 39m49.538s sys 4m13.604s

boot 2: 21 X start / 34 E ready / 1:03 rcvd / 0:21 snd

kernel build #1: real 22m58.988s user 39m53.308s sys 4m12.700s

kernel build #2: real 22m43.217s user 39m50.925s sys 4m14.976s

boot 3: 21 X start / 35 E ready / 0:39 rcvd / 0:20 snd

---------------------------------------------------------------------------- 7200 RPM 500GB hitachi, dmcrypt, HIMEM64G

boot 1: 27 X start / 40 E ready / 0:18 rcvd / 0:19 snd (cryptsetup unlock takes a few seconds)

kernel build #1: real 23m14.759s user 39m56.628s sys 4m11.470s

kernel build #2: real 22m46.385s user 39m52.201s sys 4m11.900s

boot 2: 26 X start / 39 ready / 0:14 rcvd / 0:18 snd

kernel build #1: real 23m5.225s user 39m59.785s sys 4m11.592s

real 22m47.208s user 39m52.411s sys 4m11.155s

---------------------------------------------------------------------------- 7200 RPM 500GB hitachi, dmcrypt, HIMEM4G boot 1: 24 X start / 36 ready / 0:14 rcvd / 0:20 snd

build #1: real 23m0.698s user 39m45.571s sys 4m3.892s

build #2: real 22m39.361s user 39m42.988s sys 4m3.924s

2009/12/11 Upgrade To Ubuntu Karmic
π 2009-12-11 01:01 in Linux
I recently upgraded to Ubuntu Karmic and took the opportunity to look into things that Ubuntu had changed and sometimes broken recently.

Let's start with the dreaded network manager: well, believe it or not, but after 2Y+ of being broken for me, it finally worked. It still had a few rough edges, but it finally would manage my interfaces without crashing.
It still has a few rough edges, and things I had to do were:

  • remove resolvconf, that just conflicted (should be fixed, or listed as a conflict).
  • nm-applet doesn't display in E systray properly. It randomly goes away
  • nm-applet has goofy static IP form entering, you have to click enter after each field before apply or it'll ignore what you typed last.
  • it's still not super obvious to get interfaces properly managed by NM if you also have them in /etc/network/interfaces, but it can be made to work now, and there even is half decent documentation on the gnome site and the ubuntu site.
  • It's not perfect but I can now have it seemlessly switch between my wired and wireless networks while keeping the same IP (like I used to do on debian years before networkmanager even existed).

    Then comes upstart. It's an overdue parallel init implementation (my cubemate Richard Gooch also wrote one years ago that never caught on unfortunately). It obviously has a few warts: some boots still hang for me, exim isn't supported (booh!), but it should hopefully be fully supported by all soon.

    pulseaudio, well, what can I say? It still does not work as shipped. I tried to make it work, but it still randomly hung mplayer and caused other random problems. If it's all this trouble just to get per application volume levels which I can't get in alsa I'm told, and moving audio to other destinations while it's play, which I don't need, it's definitely not worth it for me.
    My fix was:
    dpkg --purge pulseaudio pulseaudio-esound-compat pulseaudio-module-udev pulseaudio-module-gconf pulseaudio-module-x11.
    See this thread on phoronix, this comment sums what I think:
    I've never seen such a buggy thing like pulseaudio on linux regular distros.
    It's fine people is debugging this stuff, but I think they should not release it till it's stable on 99% of configurations.

    Acpid is still kind of broken as shipped for thinkpads, especially if you don't run gnome power manager, which I couldn't find a good reason to run: it's pretty featureless and braindead. Thankfully the acpid author works at my company too and I finally figured out with him that debian killed the logging in acpid, which explains why I couldn't see any output from it anymore when trying to make it work. The good news is that after fixing that I was able to create the right events to support all my Fn keys, and the only thing that really changed in the last years is that I can now call scripts from pm-utils to sleep and hibernate as opposed to doing it all in shell in acpid. Not too bad.

    For the rest, it looked like a pretty smooth upgrade: radeonhd still does not work reliably on my Z61p's M56GL [Mobility FireGL V5200] (crashes on 3D, known problem), but radeon still works fine.


    More pages: April 2023 March 2023 September 2021 May 2020 January 2020 January 2019 December 2018 March 2018 January 2018 September 2017 January 2017 October 2016 August 2016 July 2016 June 2016 March 2016 February 2016 January 2016 May 2015 March 2015 January 2015 October 2014 May 2014 April 2014 March 2014 January 2014 November 2013 September 2013 May 2013 March 2013 January 2013 December 2012 August 2012 May 2012 March 2012 January 2012 December 2011 August 2011 July 2011 January 2011 October 2010 August 2010 June 2010 April 2010 March 2010 January 2010 December 2009 November 2009 September 2009 August 2009 July 2009 May 2009 January 2009 December 2008 November 2008 October 2008 January 2008 November 2007 August 2007 July 2006 January 2006 August 2005 April 2005 November 2004 March 2004 February 2004

    Contact Email