Hello,

I'm a bit of a Moron when it comes to the newer 64 bit Dual-Core
technology. Are there programs out there that can test this new machine
(amd64 dualcore) to see if it is running up to par. That both CPUs are
doing there thing under load before I put this server into service?

And are there some docs that I can look at to help enlighten me on this
subject?

Thanks,

Ken



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 08/01/08 11:05, Account for Debian group mail wrote:

Hello,

I'm a bit of a Moron when it comes to the newer 64 bit Dual-Core
technology. Are there programs out there that can test this new machine
(amd64 dualcore) to see if it is running up to par. That both CPUs are
doing there thing under load before I put this server into service?

And are there some docs that I can look at to help enlighten me on this
subject?


What do you mean by "up to par"?

--
Ron Johnson, Jr.
Jefferson LA USA

Scientists are people, too. IOW, they also "crave power, money,
respect, and influence, and they also fear for their jobs. Each
can be a healthy motivator, but each has the ability to turn a
good scientist into a bad one; and in some cases, they can turn
a good scientist into a charlatan."
http://thefutureofthings.com/book/3/the-bomb-that-never-was.html


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Fri, 1 Aug 2008, Ron Johnson wrote:

> What do you mean by "up to par"?
>
> --
> Ron Johnson, Jr.
> Jefferson LA USA
>


http://idioms.thefreedictionary.com/up+to+par


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

>> What do you mean by "up to par"?
> http://idioms.thefreedictionary.com/up+to+par

I would venture to guess that we understand the expression, but just
don't know what you're talking about.

What specifically about the chip did you want to test? That it's
operating at the advertised clock speed, that it's computing
successfully, that it is in fact 64-bit...?


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Fri, 1 Aug 2008, Jeff Soules wrote:

> >> What do you mean by "up to par"?
> > http://idioms.thefreedictionary.com/up+to+par
>
> I would venture to guess that we understand the expression, but just
> don't know what you're talking about.
>
> What specifically about the chip did you want to test? That it's
> operating at the advertised clock speed, that it's computing
> successfully, that it is in fact 64-bit...?


I'd like to put the computer as a whole under a stress test, performance
test. I can look at the /etc/dmesg and see that the CPS's are up and
running and what the BogoMIPS are (5630.82 on this machine) but this tells
me nothing about how it is going to be when its put into service under
heavy load.

So I'm hoping that there is a Debian program that I can grab, and put this
server into all kinds of test. To make sure both processors are doing what
they should be doing and are they doing it at the same time. To check out
disk reads and writes and what type of speed and transfer rates we have
... to check it out.

Thanks,

Ken


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Fri, Aug 01, 2008 at 09:54:14AM -0700, Account for Debian group mail wrote:
>
> On Fri, 1 Aug 2008, Jeff Soules wrote:
>
> > >> What do you mean by "up to par"?
> > > http://idioms.thefreedictionary.com/up+to+par
> >
> > I would venture to guess that we understand the expression, but just
> > don't know what you're talking about.
> >
> > What specifically about the chip did you want to test? That it's
> > operating at the advertised clock speed, that it's computing
> > successfully, that it is in fact 64-bit...?
>
>
> I'd like to put the computer as a whole under a stress test, performance
> test. I can look at the /etc/dmesg and see that the CPS's are up and
> running and what the BogoMIPS are (5630.82 on this machine) but this tells
> me nothing about how it is going to be when its put into service under
> heavy load.
>
> So I'm hoping that there is a Debian program that I can grab, and put this
> server into all kinds of test. To make sure both processors are doing what
> they should be doing and are they doing it at the same time. To check out
> disk reads and writes and what type of speed and transfer rates we have
> ... to check it out.

there may be something specific for testing this stuff, but at a basic
level, you can just run top (or one of its variants) while running
some big jobs just to see how the cpus get used. If you hit '1' while
looking at top, it will split some of the cpu info out into two
lines. Maybe you could just run multiple kernel compiles
simultaneously, including one or two that are reading/writing to a
network share and see what happens that way?

I"m sure someone will come along with a proper tool for this, but
that's my .02

A

On Fri, Aug 1, 2008 at 9:54 AM, Account for Debian group mail
<debian@pcez.com> wrote:
> I'd like to put the computer as a whole under a stress test, performance
> test. I can look at the /etc/dmesg and see that the CPS's are up and

Possibly mprime's torture test? That's at mersenne.org. I've used it
to check a variety of PC health issues.

It'll run for as long as you want. If you get errors, there could be
hardware issues with your RAM, cpu, bus, power supply and so forth.

You can also benchmark and compare your speed with other like machines.

Or maybe a few days of BOINC/setiathome (that's 64 bit, and you can
make it use both cores.)

Those, of course, are cpu tests and don't really test out all the
things in the machine, such as network, disk reads/writes etc.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Fri, Aug 1, 2008 at 10:27 AM, David Fox <dfox94085@gmail.com> wrote:
> Those, of course, are cpu tests and don't really test out all the
> things in the machine, such as network, disk reads/writes etc.

Another possibility is to run a script that continously compiles a
recent linux kernel, using the -j parameter, upped sufficiently to
ensure that all the memory in the system is exercised. I personally
know an admin that has done that.

Here's one writeup, but references rather old hardware. It might be a
starting point.

http://pygmy.utoh.org/stress.txt

He's only doing one compile job repeatedly through a shell loop, and
obviously his test subjects wouldn't fare well on a make -j # because
there's not enough system ram to get the job done. I'm trying to find
the writeup, but if you ask nicely this gentleman
(rick@linuxmafia.com) about how to go about this, he might be able to
help.

Also see the linuxmafia knowledge base www.linuxmafia.com/kb although
I can't quite see the writeup he shared sometime ago about it - but it
basically involved running something like make -j 256 on the linux
kernel, in a shell loop, for something like 24 hours. (And that system
was *heavily* loaded !!)


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Fri Aug 1 21:30:01 2008
Return-path: <bounce-debian-user=tom=linux-archive.org@lists.debian.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Fri, 01 Aug 2008 20:48:34 +0300
Received: from liszt.debian.org ([82.195.75.100])
by s2.java-tips.org with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.69)
(envelope-from <bounce-debian-user=tom=linux-archive.org@lists.debian.org>)
id 1KOyjy-0000gR-An
for tom@linux-archive.org; Fri, 01 Aug 2008 20:48:34 +0300
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with QMQP
id 63AAE13A597A; Fri, 1 Aug 2008 17:48:19 +0000 (UTC)
Old-Return-Path: <jan@tofuwurst.org>
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on liszt.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-11.0 required=4.0 tests=LDOSUBSCRIBER,LDO_WHITELIST
autolearn=failed version=3.2.3
X-Original-To: lists-debian-user@liszt.debian.org
Delivered-To: lists-debian-user@liszt.debian.org
Received: from localhost (localhost [127.0.0.1])
by liszt.debian.org (Postfix) with ESMTP id 2157313A5970
for <lists-debian-user@liszt.debian.org>; Fri, 1 Aug 2008 17:48:13 +0000 (UTC)
Received: from liszt.debian.org ([127.0.0.1])
by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)
with ESMTP id 19315-29 for <lists-debian-user@liszt.debian.org>;
Fri, 1 Aug 2008 17:48:10 +0000 (UTC)
X-policyd-weight: using cached result; rate: -6.1
X-Greylist: delayed 142 seconds by postgrey-1.27 at liszt; Fri, 01 Aug 2008 17:48:10 UTC
Received: from dd17600.kasserver.com (dd17600.kasserver.com [85.13.138.69])
by liszt.debian.org (Postfix) with ESMTP id 0BA4F13A5958
for <debian-user@lists.debian.org>; Fri, 1 Aug 2008 17:48:03 +0000 (UTC)
Received: from dd17600.kasserver.com (kasmail2.kasserver.com [85.13.139.242])
by dd17600.kasserver.com (Postfix) with SMTP id CCEDAC1DD10E
for <debian-user@lists.debian.org>; Fri, 1 Aug 2008 19:45:36 +0200 (CEST)
Subject: Apache+PHP-suPHP+Suhosin = chmod Problems
from:"Jan Zilatny"<jan@tofuwurst.org>
to:debian-user@lists.debian.org
MIME-Version:1.0
Content-Type: text/plain; charset="iso-8859-15"
Message-Id: <20080801174536.CCEDAC1DD10E@dd17600.kasserver.com >
Date: Fri, 1 Aug 2008 19:45:36 +0200 (CEST)
X-Virus-Scanned: at lists.debian.org with policy bank en-ht
X-Amavis-Spam-Status: No, score=-5 tagged_above=3.6 required=5.3
tests=[LDO_WHITELIST=-5]
X-Rc-Virus: 2007-09-13_01
X-Rc-Spam: 2007-10-04_01
Resent-Message-ID: <hyTpBwsQdY.A.VcE.jx0kIB@liszt>
Resent-From: debian-user@lists.debian.org
X-Mailing-List: <debian-user@lists.debian.org> archive/latest/526294
X-Loop: debian-user@lists.debian.org
List-Id: <debian-user.lists.debian.org>
List-Post: <mailto:debian-user@lists.debian.org>
List-Help: <mailto:debian-user-request@lists.debian.org?subject=help>
List-Subscribe: <mailto:debian-user-request@lists.debian.org?subject=subscribe>
List-Unsubscribe: <mailto:debian-user-request@lists.debian.org?subject=unsubscribe>
Precedence: list
Resent-Sender: debian-user-request@lists.debian.org
Resent-Date: Fri, 1 Aug 2008 17:48:19 +0000 (UTC)
Content-Transfer-Encoding: quoted-printable

Hi!

I'm running a local setup using Debian Etch 4.0, Apache 2.2, PHP 5.2.0 (s=
uPHP+Suhosin) - all are the default Debian Packages, as my development sy=
stem. The problem I'm having is that all files created by PHP Skript are =
only "chmoded" to 600, so only the user who created them has read access =
and the Apache user can't access and deliver them.=20

I think this might have something to do with Suhosin. The files created a=
re fine on all the system where I host my files (webhosting accounts).

I've already tried to find out by searching around the web and looking at=
my config files, but can't come up with the cause.


Does anyone have an idea?

Thanks,
Jan







--=20
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org=20
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian=
.org

Andrew Sackville-West:
>
> [...] Maybe you could just run multiple kernel compiles
> simultaneously, including one or two that are reading/writing to a
> network share and see what happens that way?

To use all cores available when compiling a kernel, you don't need to
run several compilation jobs at the same time. Just set
CONCURRENCY_LEVEL to the number of cores you have.

J.
--
I wish I looked more like a successful person even though I'm a loser.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>

On Fri, 1 Aug 2008, Jochen Schulz wrote:

> Andrew Sackville-West:
> >
> > [...] Maybe you could just run multiple kernel compiles
> > simultaneously, including one or two that are reading/writing to a
> > network share and see what happens that way?
>
> To use all cores available when compiling a kernel, you don't need to
> run several compilation jobs at the same time. Just set
> CONCURRENCY_LEVEL to the number of cores you have.

Where do you set this CONCURRENCY_LEVEL at?

Thanks,

Ken


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org