swap_pager indefinite wait buffer - question - SOLVED

Sat Dec 27 09:56:22 PST 2014

In general terms I think FreeBSD is tuned for larger memory configurations
out of the box, while DragonFly auto-tunes pretty well across all memory
configurations.  It should be relatively easy to tune FreeBSD for smaller
configurations for everything except ZFS.  ZFS really needs a lot of memory
regardless, so I can see how that could be a problem.

I did spend a lot of time on the DragonFly NFS implementation, both
client-side and server-side, to make the read-ahead streaming work well.
On FreeBSD the client-side read-ahead can be tuned but, yah, I would expect
DragonFly to work better there.  FreeBSD does have some NFS locking support
and NFSv4 support which DragonFly does not, but NFS locking has always been
a bit messy and NFSv3 works very well otherwise.

Suspend and resume has always been a hard problem.  It's easy enough to
suspend, but difficult to resume reliably.  I would expect even OpenBSD
will have issues if you suspend/resume enough times.  Even Windows can have
problems.  On newer Intel systems (if/when they start getting recycled and
made available)... on Intel haswell or later systems the cpu itself does a
pretty good job getting power consumption down to around 5 watts without
suspend/resume.  The haswell cpus you find in most chromebooks (e.g. the
Acer C720 works quite well with DragonFly) are phenominally good
low-power/low-price packages.  Those would be something like the Intel
Celeron 2955U.

FreeBSD's WIFI support is better at the moment.  I have to resync the
FreeBSD code to get the latest into DragonFly.

For a server doing nothing but streaming video to clients, even atom cpus
work pretty well.  For a client, the atoms are a bit too slow but the
laptop/chromebook haswell cpus are excellent.

In terms of swapcache use on DragonFly.  It generally works very well as a
way of caching pieces of a much larger HDD onto a SSD but as with all
caches it only works well if the clients are mostly accessing a data
'footprint' which in aggregate fits into the SSD, at any given moment in
time.  This will generally be the case for text (books, PDFs, etc).  Not so
much for videos if the aggregate file size of the videos exceeds 75% of
configured swap space for swapcache.  We use swapcache on all of our
production machines.

-Matt

On Fri, Dec 26, 2014 at 10:48 PM, PeerCorps Trust Fund <
ipc at peercorpstrust.org> wrote:

> Really? Would have been nice to meet up for a chat, although I am only
> there for part of the year.
>
> All of the BSD's, hmm. The results we came up with in our testing were as
> follows (I'm summarizing).
>
> OpenBSD - having the ability to suspend and resume is extremely useful for
> both a server device and workstations in this environment, and it does this
> flawlessly on Thinkpads (which we are focused on using). It is easy to
> install and everything was very very well laid-out, including getting a
> nice simple desktop environment for the workstations. Unfortunately both on
> the server and client side, NFS is just not there in terms of speed or
> reliability no matter what configuration its in. Apart from NFS, everything
> just works.
>
> NetBSD - couldn't get anything to work.
>
> FreeBSD - worked very well. Rich selection of packages. NFS is fast and
> easy to configure on both client and server machines. ZFS is very useful,
> but am not sure if it is a long term solution for low-end set-ups.
>
> DragonflyBSD - Works! Rich selection of packages (Dports). NFS is
> extremely robust and ridiculously fast. Never seen anything like it before.
> HAMMER offers quite a number of very useful benefits and we are learning to
> put these features to good use.
>
>
> On 12/27/2014 06:12 AM, Matthew Dillon wrote:
> > That's an excellent use of a free OS.  I was in Tanzania at the beginning
> > of the year on vacation.  You can do a lot with 1GB and a lean UI.  All
> the
> > BSDs should do quite well in that configuration.
> >
> > -Matt
> >
> > On Fri, Dec 26, 2014 at 4:05 AM, PeerCorps Trust Fund <
> > ipc at peercorpstrust.org> wrote:
> >
> >> It certainly is, although the machines are actually running stock
> FreeBSD
> >> 10.1.
> >>
> >> PC-BSD was an option in the beginning, but because these were older
> >> computers it was easier to build a low-resource install enabling only
> basic
> >> services such as NFS rather than trying to pare down a PC-BSD install to
> >> suit the needs of the project (which is a basic KDE-based workstation).
> >>
> >> Most of those desktops had only one gigabyte of RAM ad PC-BSD uses a lot
> >> of resources. We learned a lot in the process and will be implementing
> >> modified libraries in the coming year using donated computer equipment.
> >>
> >> I think many underestimate the enormous value that such projects have in
> >> these communities. Just having access to books and educational material
> is
> >> tremendously beneficial from a development perspective.
> >>
> >> On 12/26/2014 01:12 PM, Carsten Mattner wrote:
> >>> On Fri, Dec 26, 2014 at 12:43 AM, PeerCorps Trust Fund
> >>> <ipc at peercorpstrust.org> wrote:
> >>>> Indeed in Tanzania :) we have a couple of technology initiatives
> taking
> >> place at the
> >>>> moment and *BSD is at the center in many ways. The delivery of
> >> educational
> >>>> materials and books to resource-limited communities is an important
> aim
> >> of
> >>>> these initiatives.
> >>>>
> >>>> We actually used FreeBSD in our first effort, but want to experiment
> >> with some
> >>>> of the capabilities of DragonflyBSD and HAMMER in the next one. In our
> >>>> estimation we can possibly stretch our hardware and funds a bit
> further
> >> with
> >>>> DragonflyBSD/HAMMER owing to its low resource requirements.
> >>>
> >>> Ah nice. Is it the same project we heard recently of with photos of a
> >> library
> >>> room running PCBSD machines with a video and document library?
> >>>
> >>>
> >>>> On 12/25/2014 11:20 PM, Carsten Mattner wrote:
> >>>>> On Thu, Dec 25, 2014 at 7:08 PM, PeerCorps Trust Fund
> >>>>> <ipc at peercorpstrust.org> wrote:
> >>>>>> I just wanted to take the opportunity update a previous post that I
> >> made to the
> >>>>>> list concerning a swap_pager concern. It isn't an issue at all but
> >> the fault of my
> >>>>>> own ignorance and hardware limits.
> >>>>>>
> >>>>>> The external drive in question was simply not pulling enough power
> >> from the
> >>>>>> USB port of the laptop. This was likely resulting in a stalled drive
> >> when anything
> >>>>>> substantial was being copied to it.
> >>>>>>
> >>>>>> This has since been solved by connecting the drive first to an
> >> externally powered
> >>>>>> USB hub. So, if there is anyone else out there having a similar
> >> issue, trying this
> >>>>>> seems to do the trick. Alternatively, just use a drive that is
> >> powered externally.
> >>>>>>
> >>>>>> Everything works beautifully now and this low cost experiment for a
> >> simple file
> >>>>>> server will find a home in a school classroom next year.
> >>>>>
> >>>>> In Tanzania?
> >>>>>
> >>>>> FreeBSD had a writeup about a set of PCBSD machines installed in
> >> Nigeria IIRC.
> >>>>>
> >>>>> A blog post or other writeup to link on dragonflybsd.org would
> surely
> >> be nice.
> >>>>>
> >>>>
> >>
> >> --
> >> Michael L. Wilson
> >> International Project Coordinator
> >> PeerCorps Trust Fund - Tanzania
> >>
> >>
> >>
> >
>
> --
> Michael L. Wilson
> International Project Coordinator
> PeerCorps Trust Fund - Tanzania
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20141227/6e2220d5/attachment-0002.html>