n userland and you'll see that most
foss programs require modifications, despite using the basic gnu tools. just
because it's not linux.
I am curious about the nature of those modifications that "most foss"
programs require.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.sim
system) became a Sun employee and was
appointed head of Project Indiana, under which OpenSolaris and IPS
were originally developed in public and with participation of non-Sun
volunteers.
https://en.wikipedia.org/wiki/OpenSolaris#History
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.si
with the historical
knowledge of the SVR4 package management software.
More than likely we will learn that there was some license or
robustness issue which resulted in dropping the SQL implementation.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfri
lean. The base install
of OmniOSce is pretty small by today's standards.
OmniOS /bin/sh is still ksh93. The root shell is for interactive
logins.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
e a RAIDZ2 filesystem?
You can use a SSD and a disk to create a mirror. The reads may occur
more often on the SSD due to better latency. The writes will be as
slow as the disk. To me this seems like a bad trade-off.
It is possible to stack zfs storage pools but that is not recommended.
pying data. The "unused" space may actually be
used.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfr
a lot more sense.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
--
illumo
to happen,
there should be some concern about space efficiency. For example,
disks with 4k sectors are less space efficient with raidz than ones
with 512 byte sectors, and particularly if small zfs filesystem block
sizes are used.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, htt
tent store.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
--
illumo
e=1048576,namlen=255,hard,noacl,
proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=65.66.246.70,mountvers=3,
mountport=59848,mountproto=udp,local_lock=none,addr=63.67.246.72)
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick
?
I do recall that Illumos re-wrote the NFS locking daemon.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
regarding how to solve this problem?
Is there a Zone option which needs to be enabled in order to use NFS
locking?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http
script) which sets the necessary LOCALE?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
it is
much more likely to work.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
--
illumos: illumos-discuss
/umem.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
--
illumos
for the function which frees the allocation to know about how the
buffer was allocated.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users
On Mon, 18 Mar 2019, Bob Friesenhahn wrote:
Based on my understanding of plockstat output (reported times are described
as "Average duration of an event, in nanoseconds"), libumem is taking 28.6,
47.8, or 67.1 *milliseconds* per contested lock for memory requests related
to posi
nt of time.
In contrast, the maximum contested lock in my own application's code
requires 1.6 milliseconds, during which time it is copying 384MB of
memory using memcpy().
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintaine
131072 |@@ | 1
libgomp.so.1.0.0`gomp_thread_start+0x24
262144 |@@ | 1 libc.so.1`_thrp_setup+0x8a
libc.so.1`_lwp_start
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
the memory allocator used.
It is doubtful that the GNU GCC developers spend much effort with
tuning pthreads-based OpenMP under Illumos or Solaris.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.Graphics
On Sat, 16 Mar 2019, Joshua M. Clulow wrote:
On Sat, 16 Mar 2019 at 12:09, Bob Friesenhahn
wrote:
Using the default allocator:
% gm benchmark -duration 10 convert -size 4000x3000 tile:model.pnm -wave 25x150
null:
Results: 40 threads 13 iter 74.63s user 10.122100s total 1.284 iter/s 0.174
57 1% ==
32816-32831 1 <1%
large 172 3% ==
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.si
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/T5f2d86b0b56e6f31
, and without even considering that the
opinion of CDDL non-compliance is a weak one.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
--
illumos-discuss
as described at
"https://en.wikipedia.org/wiki/Adaptive_replacement_cache;. One goal
of ARC is to avoid the simplistic filling that you describe.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagic
for the failing configuration:
"VMware-virtualized OmniOS with passthrough LSI-HBA"
How transparent is VMware's passthrough?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.Graphics
use classical sh, ksh93.
I think that 'zsh' at least matches 'tcsh' for usage as an interactive
shell. Long ago I was a dedicated 'tcsh' user but then moved to 'zsh'
and did not find a lack for anything.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
be at a disadvantage
against other options like freebsd. the best we could hope for is
to make the gap less severe.
There is too much talk of winners and losers, and not enough about the
users.
Please don't make me have to use another computer just to type in my
source code.
Thanks,
Bob
--
Bob
interfaces since they were
broken by chroot. If I configured Dovecot to not do a chroot then
they seemed to be working.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
is unlikely to ever use
upper-addressed sectors.
It is of course easy to test actual zfs behavior using a dtrace
script.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
to be spending 64-70% of its time in the tight loop which takes bytes
of input data from a buffer and writes (expands) them contiguously
into memory. About 0.5% of the time is reported to be due fread().
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
). My theory
may be faulty.
Tools I have used thus far to attempt to find the root of the problem
assume that programs run for a long time and are bottlenecked by CPU
and are poor for evaluating this sort of issue.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
On Sat, 15 Mar 2014, Bob Friesenhahn wrote:
I am still struggling to get GraphicsMagick running properly fast on an
Illumos system (in this case OpenIndiana oi_151a9).
Previously, GraphicsMagick was entirely profiled and tuned on a 4-core AMD
system running Solaris 10. It still runs well
52763 1 0 96
300 00121 341300 156219 4 0 87
310 0011080300 5950 0 0 100
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer
to how well it works.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180
is a complicated topic since mappings may
be file-backed. The 'pmap' output can be quite illuminating as to how
Solaris programs work.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
of keeping things running properly without the considerable
resources required for performance tuning/testing. Maybe there are
significant issues to be resolved.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
-and-programs-1/zilstat)
would be very useful in order to see what synchronous writes are
occuring.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
, 0.741682 s, 1.4 GB/s
dd if=/dev/zero of=/tmp/testfile1 bs=128k count=8k 0.00s user 0.89s system 99%
cpu 0.898 total
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
if
there are ECC errors) the classic STREAM benchmark would be a useful
test:
http://www.cs.virginia.edu/stream/
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
by iostat) while the program is
running.
And you do skip the first few lines of vmstat output, right? (that
should show lifetime stats average during this OS uptime). Trust
it for dynamic data only after the second or third line.
Yes, I do skip those lines.
Bob
--
Bob Friesenhahn
bfrie
total
It bothers me that GraphicsMagick has principly been developed and
tuned on Solaris yet I see it performing poorly under OpenIndiana vs
Linux.
Any ideas for the best way to diagnose?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen
working system, then you can see how many IOPS
are already being consumed (including synchronous writes) and have
some idea of the necessary IOPS capacity of the system.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer
that Python is necessarily to blame.
It is likely a design issue. As reason to believe that the problem is
not with Python, Mercurial is written in Python and Git is written in
compiled C yet Mercurial is demonstrated to perform operations on
remote repositories twice as fast.
Bob
--
Bob
, except that
SATA is used for boot/system drives.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
Archives: https
on the co-processor card.
What is the possibilities that Illumos can support Xeon Phi as a
co-processor, or even usefully boot and run natively on Xeon Phi?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
On Fri, 16 Nov 2012, Gary wrote:
On Fri, Nov 16, 2012 at 7:31 AM, Bob Friesenhahn bfrie...@simple.dallas.tx.us
wrote:
It seems that Linux boots and runs on the co-processor card. What is the
possibilities that Illumos can support Xeon
Phi as a co-processor, or even usefully boot
not search a filesystem which might hang
even though the system is otherwise working.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos
for running Illumos-based systems. There will be ARM64
hardware available (from other than AMD) for deployment within the
next 5 months.
Hopefully some company will decide to add ARM support for Illumos.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
, OpenOffice, and VirtualBox, would not be able to execute
due to missing libraries?
I do like the idea of a relatively spartan desktop.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
On Thu, 12 Jul 2012, Bob Friesenhahn wrote:
This evening I replaced the failed drive with a completely different one.
The OS is able to query the drive info but is still completely unable to
perform I/O on it.
I am not sure why the original first boot drive stopped working 1-1/2
days after
browsers.
I definitely agree that code which is not periodically tested is sure
to become broken.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
anticipated to be successful since
both Intel and AMD have made the necessary acquisitions so that they
can offer competing systems with their own low-power x86 CPUs.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
relationship with Oracle. Oracle does not seem to have an
interest in the type of large systems that Fujitsu is building since
Oracle is primarily interested in Oracle-designed T-series SPARC and
running the Oracle application stack.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
between this motherboard
and recent releases of Illumos, is that correct?
This board seems highly likely to work without problems
(http://www.supermicro.com/support/resources/OS/C204.cfm).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen
, then it is best to retain the
option.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
Archives: https://www.listbox.com/member
a different story than something as low level and
intrinsic as libresolv. Programs using an old LDAP interface may be
rendered totally useless in the modern world.
There should be a formal policy decision on the ABI age that Illumos
will support.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed: https
it (and machine is going away
soon) but the related 'cputrack' was used on this hardware. The
'cputrack' command also reports that AMD Family 15h is unsupported but
it did seem to produce useful output.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen
, even when these cases are avoided, heavy lock usage
becomes a significant problem with many threads running.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
the same). I am a poor free
software developer purchasing expensive hardware out of his own pocket
so it is important to make the right decision. The system vendor has
been quite helpful to me but it seems that my original question is
still unanswered.
Bob
--
Bob Friesenhahn
bfrie
On Thu, 12 Apr 2012, Hans Rosenfeld wrote:
On Thu, Apr 12, 2012 at 09:39:23AM -0500, Bob Friesenhahn wrote:
My OpenMP-based application definitely fits the description of a
potentially problematic application because it does execute the same
code in tight loops in both cores of a compute unit
they maintain (Open64) so there is no telling what
is necessary in the OS, run-time libraries, and compiler, to achieve
the sweetness indicated by the SPEC benchmark reports.
It is of course possible that there is an issue with my software or in
GCC's GOMP library.
Bob
--
Bob Friesenhahn
bfrie
On Wed, 11 Apr 2012, Bob Friesenhahn wrote:
On Wed, 11 Apr 2012, Rich wrote:
You neglect to mention your test platform's kernel or userland version
- are you running the latest illumos head, the stock kernel+userland
provided by OpenIndiana/Nexenta of some version, etc, etc?
The OS
will make changes to prevent
it) but quite often plockstat shows that the high-runners are in
mutexes that my application does not explicitly allocate.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
+0x11e
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed
the
performance problem. Since I would be purchasing the system out of my
own pocket, if I can not obtain satisfactory performance then I would
purchase an E5 Xeon system instead. The 64-cores are quite attractive
to me, but not if they can not be effectively used.
Bob
--
Bob Friesenhahn
bfrie
routine which is attempting
to read an enumeration value from the stack.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
Archives
|@@@ 4
65536 |@@ 5
131072 | 0
My application seems to be properly designed.
Ideas?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
=barcelona is requested then the programs work fine.
Is there anything in the kernel or run-time environment which might be
causing this problem?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
On Mon, 9 Apr 2012, Bob Friesenhahn wrote:
I am not sure if the AVX instruction set is being used or not, but this
evening I am running tests on a quad core Opteron 6282 SE system running
OpenIndiana.
Sorry, I meant to say four socket. Not quad core. 64-cores in
all.
Bob
--
Bob
Is there any effort underway to add AMD SVM support for KVM in
Illumos?
I don't see any related commits in the Joyent illumos-kvm respository,
but that does not mean that no one is working on it.
Thanks,
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users
from
disk.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS
On Thu, 15 Mar 2012, Simone Ricci wrote:
On Thu, Mar 15, 2012 at 3:21 PM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
The reads likely indicate that 4GB of RAM is not nearly enough. If the data
can not be cached in RAM, then it needs to be re-read from disk.
Yes, that's quite
for free in spare time by a volunteer?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
Archives: https://www.listbox.com/member
feature of CPUs currently available (e.g. Intel Core 2 +
AVX, Intel Sandy Bridge, and AMD Bulldozer), it seems like the
bug should be given increased priority.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
notice you try, but because of a rather silly bug).
Perhaps there may be another missing related bit which would be
support for setting this AVX flag via /usr/ccs/bin/as and
/usr/ccs/bin/ld (assuming that these were open-sourced).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http
.
However, I have seen the sort of threading issues you mention in the
past.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
be used
based on the drives involved? This would help avoid the problem that
information provided via installation media becomes stale.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org
list.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
Archives: https://www.listbox.com/member/archive/182180/=now
RSS Feed
to be dangerously small for the size of the pool. Of
course this would need to be based on common estimates since some
pools will deduplicate much better than others.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http
On Mon, 12 Dec 2011, Bob Friesenhahn wrote:
With assistance from a local hardware vendor, I hope to observe OpenIndiana
running (or not) on a two-socket Opteron 6200 system, at least for an hour or
two.
I did get an opportunity this past weekend to test a two-socket
Opteron 6220 (two
per-core power management quite right yet.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
---
illumos-discuss
Archives: https://www.listbox.com
84 matches
Mail list logo
