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

  • #11
    while PC-BSD 10.0 was much faster... Too fast, in fact. The reported speeds were past where the Fujitsu HDD is capable of performing so it looks like there's some handling of ZFS in PC-BSD where not all operating may be writing to the disk as handled in previous releases or other changes with syncing to the disk or caching.
    One way to exceed the write capacity of the HDD is to compress the data before it hits the disk. ZFS supports transparent compression using such algorithms as lzjb, gzip, zle, lz4. The lz4, in particular, is quite a fast algorithm. From the man pages:
    The lz4 compression algorithm is a high-performance replacement for
    the lzjb algorithm. It features significantly faster compression and
    decompression, as well as a moderately higher compression ratio than
    lzjb, but can only be used on pools with the lz4_compress feature set
    to enabled. See zpool-features(7) for details on ZFS feature flags
    and the lz4_compress feature.
    It can deliver faster results but it's unsafe in the case of power outages or other issues if the disk is left in an awkward state.
    I am curious as to the basis of this claim, or is this mealy an supposition. ZFS has been specifically designed to handle hardware failure (i.e. a flip bit), and thus I expect a power failure will be easily managed as ZFS, using hashes of all data including meta data, will simply discard the bad data and work off a previous state. I cannot, however, provide any links to substantiate my expectation.

    Comment


    • #12
      Originally posted by Rexilion View Post
      So, PC-BSD10 comes with the nVidia blob by default? Really?
      Yep, it sees NVIDIA GPU present and then loads the NVIDIA blob by default; it doesn't have Nouveau, etc.
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #13
        Debian GNU/kFreeBSD jessie could be interesting once the FreeBSD 10.0 kernel is ready, due to generally still using GCC 4.8 (same as Ubuntu).

        Comment


        • #14
          Same outcome as in 2010

          Same as the results in 2010, Linux still beats crappy BSDs overall.

          Comment


          • #15
            Originally posted by mzs_47 View Post
            Where are the gaming benchmarks?

            Imo, PC-BSD is heavily modified with lot of added "extras", which slow it down. For instance, there is not option to choose UFS as the default filesystem while installation. I think it will perform better without zfs, which is the default.

            So can we have GhostBSD(FreeBSD with GUI) vs Debian vs Ubuntu?

            Thanks!
            PC-BSD is just a FreeBSD with a graphic installer and some extra stuff like their PBI packagement, there is no modifications in kernel.

            Comment


            • #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:

                    Comment

                    Working...
                    X