Announcement

Collapse
No announcement yet.

PC-BSD 10.0 vs. PC-BSD 9.2 vs. Ubuntu 13.10 Benchmarks

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

  • #16
    Originally posted by endman View Post
    Same as the results in 2010, Linux still beats crappy BSDs overall.
    You and most other users in this forum do not understand that by default FreeBSD kernel optimizes CPU and I/O resource allocation for interactivity. This means that the kernel reserves spare resources for all processes that are interactive (such as getty, login, sshd, X11 clients etc). Thus benchmarks, such as Postmark, that artificially reach max CPU and I/O capacity will be throttled to ensure other interactive processes get a chance to respond to input.

    And ZFS is, by default, not meant for high burst speed of ridiculously big data stream. ZFS's defaults are to ensure fair I/O capacity for all tasks, and do extra integrity verification. If you want high burst speed with disk/etc I/O, you'd need to either use UFS with tuning that forsakes I/O fairness (and if you wanna go further, forsakes even system interactivity), or tune ZFS to do the same.

    Tuning guide for ZFS is here: https://wiki.freebsd.org/ZFSTuningGuide

    There are also many other utilities that can be used to prioritize a process for higher CPU and I/O capacity (which naturally means other processes get hosed, but hey, you don't care about that right?).

    The reason why FreeBSD ensures interactivity over all others by default (by reserving CPU and I/O resources for interactive tasks) is because *BSD admins generally do not want their servers to livelock if some gung-ho process decides to go postal.

    And you won't notice speed difference between FreeBSD and Linux if using normal apps that don't artificially spam-hog all resources.

    Considering all the above, I think the benchmark is not representative of the true power a FreeBSD system can serve if configured properly.

    Comment


    • #17
      Originally posted by endman View Post
      Same as the results in 2010, Linux still beats crappy BSDs overall.
      You and most other users in this forum do not understand that by default FreeBSD kernel optimizes CPU and I/O resource allocation for interactivity. This means that the kernel reserves spare resources for all processes that are interactive (such as getty, login, sshd, X11 clients etc). Thus benchmarks, such as Postmark, that artificially reach max CPU and I/O capacity will be throttled to ensure other interactive processes get a chance to respond to input.

      And ZFS is, by default, not meant for high burst speed of ridiculously big data stream. ZFS's defaults are to ensure fair I/O capacity for all tasks, and do extra integrity verification. If you want high burst speed with disk/etc I/O, you'd need to either use UFS with tuning that forsakes I/O fairness (and if you wanna go further, forsakes even system interactivity), or tune ZFS to do the same.

      Tuning guide for ZFS is here: https://wiki.freebsd.org/ZFSTuningGuide

      There are also many other utilities that can be used to prioritize a process for higher CPU and I/O capacity (which naturally means other processes get hosed, but hey, you don't care about that right?).

      The reason why FreeBSD ensures interactivity over all others by default (by reserving CPU and I/O resources for interactive tasks) is because *BSD admins generally do not want their servers to livelock if some gung-ho process decides to go postal.

      And you won't notice speed difference between FreeBSD and Linux if using normal apps that don't artificially spam-hog all resources.

      Considering all the above, I think the benchmark is not representative of the true power a FreeBSD system can serve if configured properly.

      PS. If this post is doubled, I am sorry about that. This forum software is not very nice ...

      Comment


      • #18
        Originally posted by aksyom View Post
        You and most other users in this forum do not understand that by default FreeBSD kernel optimizes CPU and I/O resource allocation for interactivity. This means that the kernel reserves spare resources for all processes that are interactive (such as getty, login, sshd, X11 clients etc). Thus benchmarks, such as Postmark, that artificially reach max CPU and I/O capacity will be throttled to ensure other interactive processes get a chance to respond to input.

        And ZFS is, by default, not meant for high burst speed of ridiculously big data stream. ZFS's defaults are to ensure fair I/O capacity for all tasks, and do extra integrity verification. If you want high burst speed with disk/etc I/O, you'd need to either use UFS with tuning that forsakes I/O fairness (and if you wanna go further, forsakes even system interactivity), or tune ZFS to do the same.

        Tuning guide for ZFS is here: https://wiki.freebsd.org/ZFSTuningGuide

        There are also many other utilities that can be used to prioritize a process for higher CPU and I/O capacity (which naturally means other processes get hosed, but hey, you don't care about that right?).

        The reason why FreeBSD ensures interactivity over all others by default (by reserving CPU and I/O resources for interactive tasks) is because *BSD admins generally do not want their servers to livelock if some gung-ho process decides to go postal.

        And you won't notice speed difference between FreeBSD and Linux if using normal apps that don't artificially spam-hog all resources.

        Considering all the above, I think the benchmark is not representative of the true power a FreeBSD system can serve if configured properly.
        Hmm, that explains some of my experiences with PC-BSD and Ubuntu. I had to do somewhat big file copying after I upgraded my computer last summer. Cpied data was about identical on both OS (big buch of personal files, videos and so on.). Ubuntu copied files somewhat faster, that's true. But when operation was on, you could not do effectively anything else with system. IO-operations simply robbed all resources. With PC-BSD copying took somewhat longer, but on other hand system remained usable through whole process. And I prefer that.

        Comment


        • #19
          Originally posted by TiberiusDuval View Post
          Hmm, that explains some of my experiences with PC-BSD and Ubuntu. I had to do somewhat big file copying after I upgraded my computer last summer. Cpied data was about identical on both OS (big buch of personal files, videos and so on.). Ubuntu copied files somewhat faster, that's true. But when operation was on, you could not do effectively anything else with system. IO-operations simply robbed all resources. With PC-BSD copying took somewhat longer, but on other hand system remained usable through whole process. And I prefer that.
          Yes, this is because Linux (as per my experiences; I really like Debian actually!) has been designed so that the kernel (by default, perhaps?) does not differentiate between interactive and non-interactive processes, the so called "completely fair scheduling" and related features. There is no implied throttling, afaik.

          Many believe that this is not a bug but a feature of the Linux kernel. The general concensus among Linux users is to run I/O heavy operations on idle priority (the idprio -command enables that) to prevent starvation. Sometimes, however, there are situations where you cannot determine priorities of processes beforehand. There are some solutions, like changing governor and I/O scheduler etc, that provide something close to FreeBSD behaviour (interactive processes remain responsive etc) but I am not sure if they work as well as FreeBSD.

          I prefer the disriminative resource allocation model of FreeBSD. And it doesn't make FreeBSD worse than Linux, it is just a feature. Gaming and 3D is not affected as you can see here: http://www.phoronix.com/scan.php?pag...8_ubuntu&num=4

          You can see discussion about the I/O livelock feature of Linux here:
          https://bugzilla.kernel.org/show_bug.cgi?id=12309

          Comment

          Working...
          X