Keith Bierman wrote:
Sorry to respond to myself..
(across a large MP) is stable over time, do you? Otherwise there'd be
no need for protocols like NTP :>
I meant, stable without some synchronization infrastructure ;>
--
Keith H. Bierman[EMAIL PROTECTED]|
http://blogs.sun.com/khb
Co
Roman wrote:
I thought an OS kernel was supposed to synchronise hardware counters on
multiple CPUs when it was loading??
Well, I don't know where that requirement is stated; but initialization
aside, over time you surely can't think that resolution down to a tick
(across a large MP) is stab
On Thu, Feb 02, 2006 at 03:01:12PM -0800, Roman wrote:
> I thought an OS kernel was supposed to synchronise hardware counters
> on multiple CPUs when it was loading??
It does when it can. On x86 hardware, depending on how the BIOS sets things
up, it can be impossible. On Sparc, there *will* be a
I thought an OS kernel was supposed to synchronise hardware counters on
multiple CPUs when it was loading??
In regard to %tick being privileged register: yes and no. There is flag in that
register the kernel can set, to allow user processes access to it. Earlier
versions of Solaris made it priv
On Thu, Feb 02, 2006 at 04:17:56AM -0800, Roman wrote:
> I don't think it's filesystem related, i.e. there is not much I/O happening
> at the time. Maybe NetBSD's /bin/sh is a lot faster than Solaris
> /bin/{sh,ksh,bash}, maybe NetBSD's fork() is a lot faster. I didn't benchmark
> the two operat
I've used gethrtime on both
Roman wrote:
I don't think it's filesystem related, i.e. there is not much I/O happening at
the time. Maybe NetBSD's /bin/sh is a lot faster than Solaris
/bin/{sh,ksh,bash}, maybe NetBSD's fork() is a lot faster. I didn't benchmark
the two operating systems. I'm h
I don't think it's filesystem related, i.e. there is not much I/O happening at
the time. Maybe NetBSD's /bin/sh is a lot faster than Solaris
/bin/{sh,ksh,bash}, maybe NetBSD's fork() is a lot faster. I didn't benchmark
the two operating systems. I'm hoping to conduct some benchmarks soon and wil
for mplayer try -cache 16384 or something to increase the cache size this helps
a lot on my ati based notebook... don't knwo if such an option exists for
xine...
This message posted from opensolaris.org
___
perf-discuss mailing list
perf-discuss@opensol
