DragonFlyBSD Project Update - colo upgrade, future trends

Bret Busby bret.busby at gmail.com
Mon Jul 22 14:19:06 PDT 2019


On 23/07/2019, Matthew Dillon <dillon at backplane.com> wrote:
> For the last week I've been testing out a replacement for Monster, our
> 48-core opteron server.  The project will be removing Monster from the colo
> in a week or two and replacing it with three machines which together will
> use half the power that Monster did alone.
>
> The goal is to clear out a little power budget in the colo and to really
> beef-up our package-building capabilities to reduce the turn-around time
> needed to test ports syncs and updates to the binary package system.
> Currently we use two blades to do most of the building, plus monster
> sometimes.  The blades take almost a week (120 hours+) to do a full synth
> run and monster takes around 27.5 hours.  But we need to do three bulk
> builds more or less at the same time... one for the release branch, one for
> the development branch, and one for staging updates.  It just takes too
> long and its been gnawing at me for a little while.
>
> Well, Zen 2 to the rescue!  These new CPUs can take ECC, there's actually
> an IPMI mobo available, and they are fast as hell and cheap for what we
> get.
>
> The new machines will be two 3900X based servers, plus a dual-xeon system
> that I already had at home.   The 3900X's can each do a full synth run in
> 24.5 hours and the Xeon can do it in around 31 hours.  Monster will be
> retired.  And the crazy thing about this?  Monster burns 1000W going full
> bore.  Each of the 3900X servers burns 160W and the Xeon burns 200W.  In
> otherwords, we are replacing 1000W with only 520W and getting roughly 6x
> the performance efficiency in the upgrade.  This tell you just how much
> more power-efficient machines have become in the last 9 years or so.
>
> This upgrade will allow us to do full builds for both release and dev in
> roughly one day instead of seven days, and do it without interfering with
> staging work that might be happening at the same time.
>
> --
>
> Future trends - DragonFlyBSD has reached a bit of a cross-roads.  With most
> of the SMP work now essentially complete across the entire system the main
> project focus is now on supplying reliable binary ports for release and
> developer branches, DRM  (GPU) support and other UI elements to keep
> DragonFlyBSD relevant on workstations, and continuing Filesystem work on
> HAMMER2 to get multi-device and clustering going.
>
> John Marino (marino) pioneered the 'synth' system for dports and continues
> to help out, but his focus is on RavenPorts for now.  Rimvydas Jasinskas
> (zrj) and Antonio Huete Jimenez (tuxillo) have done a huge amount of work
> bringing dports back into operational form and getting the FreeBSD ports
> sync stuff working better.    DragonFlyBSD is still using synth, and will
> probably remain on synth for the foreseeable future, though there is always
> some discussion about how best to move dports forwards.  It's an excellent
> build platform for us.
>
> Francois Tigeot (ftigeot) has done a ton of work taking DRM up to
> Linux-4.7.10 and this has worked very well for Intel iGPUs.  We are now
> finally starting to dive into Linux's 'amdgpu' subsystem which is much
> older, in order to modernize our AMD support (which is still deficient).
>  Numerous other people have spent a considerable amount of time helping
> test GPU support and tracking down bugs.  The work is ongoing.
>
> I apologize for only writing everyone's names in plain ascii :-)
>
> Right now HAMMER2 makes for an excellent single-device filesystem
> (extremely well given that it supports writable snapshots and compression
> out of the box), but it remains deficient when it comes to expandable
> storage, multiple devices, and clustering.  This will be active work for me
> but honestly the amdgpu support has to come first so it's still going to be
> a long-haul for HAMMER2.
>
> The mailing lists are not seeing much if any activity any more.  This is
> more a generational issue... people kinda prefer web-based forums these
> days and younger generations do not use mailing lists at all for group
> stuff (not really).  Even the devs almost universally use IRC and not
> mailing lists for discussions now (its kinda too bad that we don't have a
> permanent irc log stored on DFly servers for posterity).  So we are looking
> into potentially shifting user interaction to a web-based forum, perhaps
> this year, and retiring the mailing lists, leaving just an archive for the
> mailing list.  Possibly sometime this year, so look for action on that
> upcoming.
>


I had been watching and hoping that DragonflyBSD would incorporate a
driver for the nVIDIA Optimus stuff.

When I tried to find open source operating systems that would run my
laptop computer with an i7 Haskell CPU and nVIDIA Optimus, I could
find only two non-MS operating systems  that would drive the CPU -
only Ubuntu Linux (no other Linux) and DragonflyBSD (no other BSD) had
drivers for the Intel Haskell architecture, and, only Ubuntu Linux
(going back to v12.04) had drivers for both the Intel Haskell
architecture and the nVIDIA Optimus thingy. The computer is currently
running UbuntuMATE Linux 16.04.x.

So, I waited, and, watched the mailing list, for information that
DragonflyBSD would run the nVIDIA Optimus thingy.

But, as DragonflyBSD has not yet (insofar as I am aware) incorporated
a driver for the nVIDIA Optimus thingy, and, with DragonflyBSD now
apparently going to end the use of the mailing list, it appears that
it is now time for me to give up waiting for DragonflyBSD to provide
an operating system that I could use. Especially, if, even if a driver
for the nVIDIA Optimus thing, became available, mailing list support
would not be available.

It is kind of sad, to me.

-- 
Bret Busby
Armadale
West Australia
..............

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992

....................................................


More information about the Users mailing list