Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19

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

  1. #11
    Join Date
    May 2009
    Posts
    10

    Default

    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.

  2. #12

    Default

    Quote 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.

  3. #13
    Join Date
    Jul 2012
    Posts
    107

    Default

    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).

  4. #14
    Join Date
    Oct 2013
    Posts
    109

    Default Same outcome as in 2010

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

  5. #15
    Join Date
    Jan 2013
    Posts
    23

    Default

    Quote 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.

  6. #16
    Join Date
    Oct 2014
    Posts
    3

    Default

    Quote 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.

  7. #17
    Join Date
    Oct 2014
    Posts
    3

    Default

    Quote 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 ...

  8. #18
    Join Date
    Oct 2014
    Location
    Turku, Finland
    Posts
    9

    Default

    Quote 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.

  9. #19
    Join Date
    Oct 2014
    Posts
    3

    Default

    Quote 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •