Announcement

Collapse
No announcement yet.

Debian 8.0 Jessie - GNU/Linux vs. GNU/kFreeBSD Benchmarks

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

  • Debian 8.0 Jessie - GNU/Linux vs. GNU/kFreeBSD Benchmarks

    Phoronix: Debian 8.0 Jessie - GNU/Linux vs. GNU/kFreeBSD Benchmarks

    Here's our latest benchmark results comparing the performance of Debian Jessie GNU/Linux vs. GNU/kFreeBSD -- the Debian port that uses the FreeBSD kernel rather than Linux...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Thanks; interesting that only a few of the tests show a big difference in performance now.

    That graphics card should work on GNU/kFreeBSD for 3D acceleration, only the "firmware-linux-nonfree" package must be installed:

    Comment


    • #3
      I tried Debian GNU/kFreeBSD on my laptop recently but noticed it could only support Vesa graphics and X wouldn't load when I removed the Vesa driver. Wish I knew to do "kldload i915kms" "kldload drm2". Maybe I may give it another try.

      How is lid opening/closing ACPI suspend support on Debian GNU/kFreeBSD?

      It would be interesting to see Michael test his usual assortment of FOSS games on kFreeBSD with the new Radeon KMS drivers but the code is based off the old Linux 3.8 DRM code. I'm eager to see what kind of FPS these games get on the BSD driver stack.

      Comment


      • #4
        Originally posted by stevenc View Post
        That graphics card should work on GNU/kFreeBSD for 3D acceleration, only the "firmware-linux-nonfree" package must be installed:
        https://wiki.debian.org/Debian_GNU/k...ware#AMD.2FATI
        No, that is GCN part - no accel supported.

        Comment


        • #5
          Originally posted by dungeon View Post
          No, that is GCN part - no accel supported.
          Oh I see, thanks, the HD 7850 (Southern Islands) support is not complete: https://wiki.freebsd.org/Graphics
          so an older card actually should perform better.

          Originally posted by Xaero_Vincent View Post
          How is lid opening/closing ACPI suspend support on Debian GNU/kFreeBSD?
          By default I don't think the lid switch will trigger anything, but /etc/devd.conf has instructions on how to script something from those events. So it requires the user's effort to make it do something, but should be very flexible and clear (vs. something like systemd handling things for you but being difficult to change/understand later).

          ACPI suspend works mostly OK for me on a regular desktop, using a custom launcher that runs "sudo acpiconf -s 3".

          Comment


          • #6
            Originally posted by stevenc View Post
            Oh I see, thanks, the HD 7850 (Southern Islands) support is not complete: https://wiki.freebsd.org/Graphics
            so an older card actually should perform better.



            By default I don't think the lid switch will trigger anything, but /etc/devd.conf has instructions on how to script something from those events. So it requires the user's effort to make it do something, but should be very flexible and clear (vs. something like systemd handling things for you but being difficult to change/understand later).

            ACPI suspend works mostly OK for me on a regular desktop, using a custom launcher that runs "sudo acpiconf -s 3".


            What do you mean by "vs. something like systemd handling things for you but being difficult to change/understand later"? (It is a genuine question), I am one of those using acpid for things like this, yet I am curious to know what exactly on systemd is difficult to understand regarding the mechanism it uses to suspend and resume.

            As in, as long as you have logind configured to HandleLidSwitch=suspend, I don't see how anything else could be a systemd fault. Doesn't it use the power states (from swsusp) for that?

            Comment


            • #7
              Originally posted by Paul-L View Post
              What do you mean by "vs. something like systemd handling things for you but being difficult to change/understand later"? (It is a genuine question), I am one of those using acpid for things like this, yet I am curious to know what exactly on systemd is difficult to understand regarding the mechanism it uses to suspend and resume.
              FreeBSD devd sounds exactly like acpid in that events can run scripts or other executables, which is a very simple interface and allows tons of flexibility to do what you want. Debugging is easy as you can run the scripts manually, use "sh -x" to trace line-by-line, echo out extra debug info, put "exit" somewhere in the script to not actually sleep while testing it.

              systemd's handling sounds great *if* its default behaviour works for you, but otherwise it only lets you choose from a set of built-in actions: ignore, poweroff, reboot, sleep, etc. If it lacks some feature you'd like for your setup, that's no longer simply a line of shellscript, but lots of reading through systemd docs to find a workaround, or a feature request to upstream (https://bugs.debian.org/761639).

              Or if systemd's handling of ACPI events doesn't work as expected (https://bugs.debian.org/736389, https://bugs.debian.org/769946) that also sounds very difficult to debug without upstream's help. With a small, standalone daemon like acpid or devd that should have been much easier (and in both examples acpid had worked fine before on the affected machines).

              Comment


              • #8
                Originally posted by stevenc View Post
                FreeBSD devd sounds exactly like acpid in that events can run scripts or other executables, which is a very simple interface and allows tons of flexibility to do what you want. Debugging is easy as you can run the scripts manually, use "sh -x" to trace line-by-line, echo out extra debug info, put "exit" somewhere in the script to not actually sleep while testing it.

                systemd's handling sounds great *if* its default behaviour works for you, but otherwise it only lets you choose from a set of built-in actions: ignore, poweroff, reboot, sleep, etc. If it lacks some feature you'd like for your setup, that's no longer simply a line of shellscript, but lots of reading through systemd docs to find a workaround, or a feature request to upstream (https://bugs.debian.org/761639).

                Or if systemd's handling of ACPI events doesn't work as expected (https://bugs.debian.org/736389, https://bugs.debian.org/769946) that also sounds very difficult to debug without upstream's help. With a small, standalone daemon like acpid or devd that should have been much easier (and in both examples acpid had worked fine before on the affected machines).
                Ah, quite interesting, the two laptops I have are still using acpid on Wheezy, and I guess I'll stick to that until well...atleast once I see systemd on Debian mature enough (less systemd bugs of that nature on the tracker). I am quite happy that so far I didn't have any problems with systemd on my Arch desktop, hopefully it stays that way for long...

                Comment

                Working...
                X