I still say the interface is wrong for IPv4 and that you should
store precomputed netmasks for IPv4. I'd advocate the same
for IPv6 too.
How about a branchless ipv6 check:
r = (a[0] - (b[0] & c[0]));
r |= (a[1] - (b[1] & c[1]));
r |= (a[2] - (b[2] & c[2]));
r |= (a[3] - (b[3] & c[3]));
...wel
Dan McDonald wrote:
(This time, using e-mail instead of the web form...)
Hello again!
After what suggestions I saw (all on networking-discuss...), I put together a
multiple-choice question.
Consider thie _LITTLE_ENDIAN section in this code fragment, which is known to
be an improvement on SPARC
(This time, using e-mail instead of the web form...)
Hello again!
After what suggestions I saw (all on networking-discuss...), I put together a
multiple-choice question.
Consider thie _LITTLE_ENDIAN section in this code fragment, which is known to
be an improvement on SPARC:
===
You have to use accounting to capture short lived processes, there is also
the "child CPU" counter that some tools show (e.g. SE toolkit pea.se)
however these use the low resolution 10ms cpu tick so to accurate
measurements you really need to use extended system accounting, which is
based on micro
On 6/18/07, 陶捷 Euler Tao <[EMAIL PROTECTED]> wrote:
ok, i see.
Then, how can I correct this problem when using prstat?
Or is there any other statistics tool that could catch these short lived
processes correctly?
If your using Solaris 10 or Nevada, you can use shortlive.d from the
DTraceToolki
Hi
I don't know enough about the specifics for Open Solaris so the
following is based on the guess that it is the same as regular Solaris
(the fact that your vmstat r queue is at values like 7 and that idle CPU
is at 0% but prstat shows only about 4% CPU makes this feel like a good
guess) . Hist
On 6/18/07, 陶捷 Euler Tao <[EMAIL PROTECTED]> wrote:
ok, i see.
Then, how can I correct this problem when using prstat?
I'd try microstate accounting to see but I'm not sure if it will help.
You could also try to reduce the reporting interval.
Or is there any other statistics tool that could c
ok, i see.
Then, how can I correct this problem when using prstat?
Or is there any other statistics tool that could catch these short lived
processes correctly?
2007/6/18, Wee Yeh Tan <[EMAIL PROTECTED]>:
On 6/18/07, Wee Yeh Tan <[EMAIL PROTECTED]> wrote:
> prstat may miss
Stupid safari3 is c
On 6/18/07, Wee Yeh Tan <[EMAIL PROTECTED]> wrote:
prstat may miss
Stupid safari3 is chopping off my post.
prstat may miss short lived processes and this seems possible because
you are compiling stuff.
--
Just me,
Wire ...
Blog:
___
perf-discuss m
On 6/18/07, 陶捷 Euler Tao <[EMAIL PROTECTED]> wrote:
Dear all:
I'm compiling the ON build 65's source code now, using "nightly
opensolaris.sh" command.
The prstat reports that system is very idle, but the load average tells me
that the system is very busy. -,-
And then I check the vmstat report,
Dear all:
I'm compiling the ON build 65's source code now, using "nightly
opensolaris.sh" command.
The prstat reports that system is very idle, but the load average tells me
that the system is very busy. -,-
And then I check the vmstat report, it shows the system is busy now, too.
Following are
> On 12/06/07, Nicolas Linkert <[EMAIL PROTECTED]>
> wrote:
> > Nevada Build 65 performace vs. Debian 4.0 performace is abysmal.
> > I don't know whether itr has to do with the desktop (I think so, because
> > core
> > Solaris performance is fine), but Vermillion performance really sucks.
> > Comp
> > Now I'm going to have a look at the ehci USB2.0 driver; I seems that it
> > needs
> > 5 seconds to "initialize" (time spent between the "npe: .. ehci0" message
> > and "genunix: ehci0 is ...").
> >
> > And the USB disk that happens to be connected to that ehci USB 2.0
> > controller
> > delay
13 matches
Mail list logo
