Announcement

Collapse
No announcement yet.

Intel Atom On Ubuntu, Fedora, OpenSuSE, Mandriva

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Performance differences in SQLite

    I am the primary developer for SQLite. The SuSE people have contacted me asking why I think SQLite runs so much slower on their system than on Ubuntu. I don't know, but I can posit a guess or two....

    The culprit is likely the fsync() system call. SQLite makes use of fsync() in order to insure that transactions survive unexpected power loss. As long as you never loss power, whether or not fsync() works is probably unimportant to you. But if, someday, you do lose power unexpectedly, and you are in the middle of an SQLite transaction, a working fsync() might become very important to you.

    It could be that SuSE has a kernel bug that somehow makes fsync() really slow. Or (more likely) it could be that the other distributions are skimping on fsync() and not taking the time to do it right.

    I am writing because I am concerned that benchmarks such as those you publish are encouraging vendors to skimp on fsync() and other services, which make average performance better, but which result in catastrophe when an anomaly such as a power loss occurs. We've already seen that most disk drive and memory stick makers take shortcuts on their flush operations. We at the SQLite development team have heard many woeful tales from people who thought their data was safe, because the disk drive said it was on oxide, but who lost data during a power loss because the disk drive was really lying.

    Benchmarks are important. But it is also important to understand that some vendors might increase benchmarks performance at the expense of reliability.

    I do not know what is going on with these tests. There really could be something wrong with SuSE for all I know. (Nobody on the SQLite development team has any connection with SuSE and SQLite does not receive any funding from SuSE or Novell.) But my suspicions are that the other distros are in fact skimping on fsync somehow, which is boosting performance and the risk of corrupting data during a power loss.

    Can anyone suggest ways of testing the rebustness of a distro against power loss? Such a test would likely settle this question.

    Comment


    • #17
      I suggested before that barriers could be the reason of OpenSUSE's slower performance in that test. It's the only distro that turns them on by default. Maybe just testing with and without barriers (with mount option barrier=1 and barrier=0)could give an answer to the question.

      Someone else also pointed at the Beagle indexer as the culprit. So turning that off could be another way of finding out if it makes a difference.

      I don't think it's a different implementation of fsync. No distro would disable fsync to improve performance.

      Comment


      • #18
        Andreas Jaeger commented on the performance issues with openSUSE 11.1.

        http://lizards.opensuse.org/2008/12/...-opensuse-111/

        Phoronix has run some tests comparing the openSUSE 11.1 release candidate (RC1), Ubuntu 8.10, Fedora 10 and Mandriva 2009.0 on Intel Atom.
        We have looked at the results and they are not good for openSUSE 11.1. I’ve talked with a few engineers and want to present below our first analysis.
        While the benchmarks were done on a specific hardware, they might be relevant for other hardware as well.
        Note that the numbers I cite below are not benchmark numbers comparable to the one Phoronix measured, they are measured on totally different machines by different engineers and not all are done as real benchmarks. But they show some of the problems.

        Disk I/O - Safe or Fast?

        We have barriers enabled for the ext3 filesystem. This is needed for filesystem integrity but forces at certain points a flush of disk writeback caches to prevent data corruption.
        As Wikipedia states:
        “Ext3 does not do checksumming when writing to the journal. If barrier=1 is not enabled as a mount option (in /etc/fstab), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash.”
        With openSUSE barrier=1 is the default and even AFAIK openSUSE and SUSE Linux Enterprise are the only distributions enabling barriers by default.
        If you want to disable barriers, use “mount -o barrier=0″ on ext3 (or change /etc/fstab).
        The gzip test for example gives on one of our machines the following results:
        kernel-default-2.6.27.8-1.1 / ext3: 1348s
        kernel-default-2.6.27.8-1.1 / ext3 barrier=0: 437s
        X11 and Graphics - Performance of the Intel Driver

        Looking at the graphics results, I see that OpenGL has the same performance but XRender is horribly slow, but Ubuntu sometimes(!) hits the same issue.
        We have an upstream bug open about X11 speed (see here), and it’s considered the highest priority bug, still nobody has a clue where it comes from. This needs to be rechecked with the final version of openSUSE 11.1, though, because there are some indications that it got improved. Intel has apparently fixed some of that in a newer driver that is not available yet.
        It would also be interesting to know whether Mandriva uses XAA or EXA, we do not use XAA for Intel driver any longer, since Intel as driver author does not want to support it, and it has issues with suspend and resume. The old XAA is currently better optimized than the new EXA.
        Performance is Important

        Performance is important for us and our engineers are working on performance improvements and try to help with known regressions.
        For example, if you look at discussions about the tbench regression (LWN reports about these at “Tracking tbench troubles” and “Tbench troubles II“, you see a couple of Novell engineers involved including Rafael Wysocki and Jiri Kosina - and we have run quite some benchmarks to help track and fix these problems.
        Call for Action

        I’m interested to see what’s we can do to improve the performance and invite you to discuss on the openSUSE-factory mailing list what to do. Contribution in benchmarking and figuring out bottlenecks is important as well.
        Conclusion

        So, whom does the problems hit - and how hard? So far, I see two culprits: The ext3 filesystem with barriers enabled and the Intel graphics driver. If you’re not using either, you’re on par with other recent distributions.
        The ext3 filesystem regression can be worked around at the risk of filesystem integrity with disabling barriers. I doubt that I will hit this during normal desktop usage on my system.
        The Intel issue has been discussed already at the openSUSE-factory mailing list and it was even suggested to not ship openSUSE 11.1 because of this. It hits some Intel graphics driver users quite card
        and I wonder why I don’t see it on my machine. It might be better/worse on specific graphics chip.
        If this issue is fixed with a new driver that works in our 11.1 setup, we will consider doing an update via our update repositories.

        Comment


        • #19
          Netbook distros

          How about benchmarks on lighter distros ?
          Zenwalk, Vector, Puppy and PC-BSD ?

          Comment


          • #20
            I'd love to see in the test suite a benchmark to measure Flash video playback performance and resource consumption (CPU and RAM) using the Adobe Flash plugin (for Linux, Windows, etc.). I doubt it would happen since the plugin isn't available on all platforms, and besides it's not open-source.

            However, such a test would resolve (in mind at least) whether a Atom-based Linux netbook could reasonably be used for web-surfing sites featuring Flash video (YouTube, Hulu, etc.)

            Comment


            • #21
              Originally posted by fxfuji View Post
              I'd love to see in the test suite a benchmark to measure Flash video playback performance and resource consumption (CPU and RAM) using the Adobe Flash plugin (for Linux, Windows, etc.). I doubt it would happen since the plugin isn't available on all platforms, and besides it's not open-source.

              However, such a test would resolve (in mind at least) whether a Atom-based Linux netbook could reasonably be used for web-surfing sites featuring Flash video (YouTube, Hulu, etc.)
              Well this wouldn't be a problem for the ION systems in windows as Flash now supports nvidia's Purevideo. As far as vdpau support for Flash in linux I'm still waiting for a reply from Adobe on that if it is ever going to be incorporated in their linux versions.

              Comment

              Working...
              X