Thorsten Froehlich <tho### [at] trfde> wrote:
> Not on Unix as there is no fully portable way to determine the number of CPU

  Ah, that explains it. I didn't know there was such a difference between
the windows and the linux versions.

> Every Unix uses its own way to do it, i.e. there is no
> standard Posix way of getting this information that works everywhere.

  OTOH, I'm pretty sure it would be possible to retrieve this information
in linux. Perhaps some "#ifdef LINUX" code could be added for this?

-- 
                                                          - Warp

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> > beta14. how can I activate my second core?

> will use 2 render threads, which means both of your cores should be used at
> nearly 100% for rendering (if nothing else is taking up cpu power).  You might

How should this possible ?


A normal user have only a limited bandwith of CPU-power and this is far
away from 100% CPU power. Because a program/user wich gets realy 100% of
the  CPU power would block the computer for all other programs/users.
And this can not be allowed in a Multiuser-System.
(btw. web-severs handles this in the same way, by a bandwith-control).

So the "top" command shows only the capacity of the User-Bandwith....not
the absolute CPU usage.


You can verify this very simple. Go to the "root-mode" and start
provray with the highest possible "nice value" of the privileged mode.
In this mode povray gets *much more* CPU-power than a normal user can
ever get....this reduce on the one hand the Rendering-time,
on the other hand, it is nearly impossible to do any other things
one this computer during the render-time.

Post a reply to this message

On Mon, 14 Aug 2006 01:26:29 -0400, Meothuru wrote:

> Go to the "root-mode" and start
> provray with the highest possible "nice value" of the privileged mode.
> In this mode povray gets *much more* CPU-power than a normal user can
> ever get

Actually, you can renice user processes so they run at the highest
possible level; the behaviour in Linux is that a non-root user can set the
niceness level to a higher value than it's currently set.

There also can be a tradeoff if the processes impacted by running a
program at the highest priority affect processes that control disk i/o and
such - you can actually lose performance, depending on the process
(probably not so much the case with POV-Ray, but with things like bulkload
of a local LDAP server, the bottleneck tends to be the I/O channels rather
than processing, so pushing the niceness level to an 'unfriendly' level
can actually degrade overall performance of the bulkload).

Jim

Post a reply to this message

> So the "top" command shows only the capacity of the User-Bandwith....not
> the absolute CPU usage.

	IIRC the 'top' utility reads the /proc filesystem: it should thus give the
exact same stats whether you are root or a non-privileged user.  (Otherwise, top
would be able to report only the current user's jobs, not all jobs.)
	So I guess your claim is not true.  I'd appreciate if you have pointers
to prove me wrong.

> You can verify this very simple. Go to the "root-mode" and start
> provray with the highest possible "nice value" of the privileged mode.
> In this mode povray gets *much more* CPU-power than a normal user can
> ever get....

	Could you please backup this second claim with numbers?

	On my monocore machine (AMD Athlon XP), running POV-Ray 3.6.1(a) or 3.7.0.beta.14(b)
as root on a few scenes(c) with either default scheduling priority (nice 0) or highest
priority (-20) and no other cpu-demanding job running, I hardly get one second
speedup.

	So with those limited tests I do *not* observe what you claim above.

	- NC


(a) unofficial build prepared with icc 8.1.
(b) the binary is compiled with icc 9.1; tested using 1 or 2 render threads, see
below.
(c) scenes/advanced/mediasky.pov and grenadine.pov; more are being tested, but the
result
should not depend on the scenes nor the binaries.

===== mediasky.pov

*** 3.7.0.beta14

2 threads,   0:  115.803u 0.012s 1:56.13 99.7%   0+0k 0+0io 0pf+0w
2 threads, -20:  115.091u 0.028s 1:55.36 99.7%   0+0k 0+0io 0pf+0w

1 thread,    0:  115.703u 0.000s 1:56.03 99.7%   0+0k 0+0io 0pf+0w
1 thread,  -20:  115.107u 0.004s 1:55.34 99.7%   0+0k 0+0io 0pf+0w

*** 3.6.1

   0:  118.947u 0.028s 1:59.10 99.8%   0+0k 0+0io 0pf+0w
-20:  118.023u 0.008s 1:58.06 99.9%   0+0k 0+0io 0pf+0w

===== grenadine.pov

*** 3.7.0.beta14

1 thread,    0:   60.591u 0.056s 1:01.06 99.3%    0+0k 0+0io 0pf+0w
1 thread,  -20:   59.947u 0.036s 1:00.24 99.5%    0+0k 0+0io 0pf+0w

Post a reply to this message

Meothuru <nomail@nomail> wrote:
> A normal user have only a limited bandwith of CPU-power and this is far
> away from 100% CPU power.

  Far away? Not really.

  If nothing CPU-intensive is running at the same time, a CPU-intensive
program (such as POV-Ray) will get almost 100% (usually from 99% upwards).
  The OS doesn't need almost any CPU at all for task switching, and if
there isn't anything else using the CPU heavily, then there's nothing
which would require it.

> Because a program/user wich gets realy 100% of
> the  CPU power would block the computer for all other programs/users.

  He said "nearly 100%". That is, not exactly 100%, but a bit lower,
like 99.5%, which by all practical purposes is the same thing.

> And this can not be allowed in a Multiuser-System.

  I think you misunderstand. POV-Ray takes all the CPU time which is
unused. If nothing else is using the CPU, then it takes all of it.
  That doesn't mean that if another CPU-intensive program is started
it would not get its share.

> You can verify this very simple. Go to the "root-mode" and start
> provray with the highest possible "nice value" of the privileged mode.
> In this mode povray gets *much more* CPU-power than a normal user can
> ever get....

  Much more? I would need to see some evidence before I believe that.

-- 
                                                          - Warp

Post a reply to this message

On Mon, 14 Aug 2006 09:29:51 -0400, Warp wrote:

>   I think you misunderstand. POV-Ray takes all the CPU time which is
> unused. If nothing else is using the CPU, then it takes all of it.
>   That doesn't mean that if another CPU-intensive program is started
> it would not get its share.

I think that would depend on the comparitive niceness levels, though,
wouldn't it?  POV-Ray doesn't yield entirely to another process that wants
CPU - they participate in a timesharing system.

If I start a render in POV-Ray and then launch xmoto (a fairly intensive
game), I don't get the same degree of smoothness in running xmoto with
POV-Ray running as I do with it running.  I can either suspend POV-Ray
entirely (ctrl-Z in POV-Ray's term window), or I can change the niceness
levels of either (or both) programs.  I still get some jerkiness in the
graphics in the game, but it's not as pronounced.

I've never observed POV-Ray automatically yielding processor to whatever
other applications are running on the system or tuning it's
niceness/priority level in the system.  If it does that, great, but I'd
love to know how to turn it on because it doesn't seem to be a default
behaviour; it seems to behave like any other application running on the
system.

Jim

Post a reply to this message

> I think that would depend on the comparitive niceness levels, though,
> wouldn't it?

	Of course.

> I still get some jerkiness in the
> graphics in the game, but it's not as pronounced.

	If you give the lowest priority to your POV-Ray job (+20), you should
get nearly the same effect as suspending it.  But not quite, as it would still
get maybe 1-2% of the resources on average.

> I've never observed POV-Ray automatically yielding processor to whatever
> other applications are running on the system or tuning it's
> niceness/priority level in the system.

	AFAIK only the OS - say the user on top of it - can do that in a Unix environment.
	(Honestly I never looked at this possibility.)

	- NC

Post a reply to this message

On Mon, 14 Aug 2006 19:26:56 +0200, Nicolas Calimet wrote:

>> I still get some jerkiness in the
>> graphics in the game, but it's not as pronounced.
> 
> 	If you give the lowest priority to your POV-Ray job (+20), you should
> get nearly the same effect as suspending it.  But not quite, as it would
> still get maybe 1-2% of the resources on average.

Sounds about right.  Doesn't the niceness level adjust the timeslicing
used, or is that controlled by something else?

> 	AFAIK only the OS - say the user on top of it - can do that in a Unix
> 	environment.

That's my understanding as well - and even then, I think it depends on
which part of the OS we're talking about as well.  I have seen user
processes run away with a Linux kernel to the point the machines becomes
nonresponsive on the network (granted, that's probably still too far away
from the kernel, since it's services not responding that would be the
indicator of this behaviour.)

Jim

Post a reply to this message

> Doesn't the niceness level adjust the timeslicing
> used, or is that controlled by something else?

	Best is to ask Google  :-)

http://www.samspublishing.com/articles/article.asp?p=101760&rl=1

> I have seen user
> processes run away with a Linux kernel to the point the machines becomes
> nonresponsive on the network

	I've faced litterally frozen desktops mostly when an user app started to
swap like hell because of too high a memory demand.

	- NC

Post a reply to this message

On Tue, 15 Aug 2006 02:23:20 +0200, Nicolas Calimet wrote:

>> Doesn't the niceness level adjust the timeslicing
>> used, or is that controlled by something else?
> 
> 	Best is to ask Google  :-)
> 
> http://www.samspublishing.com/articles/article.asp?p=101760&rl=1

<G>  Or I could peruse the kernel source, at that. :-)

>> I have seen user
>> processes run away with a Linux kernel to the point the machines becomes
>> nonresponsive on the network
> 
> 	I've faced litterally frozen desktops mostly when an user app started to
> swap like hell because of too high a memory demand.

Yep, I see that on occasion here as well - usually something like
beagled-helper most recently - I need to file a bug on that, but I swap so
infrequently that I thought the monitor applet was broken until that thing
started burning memory up.

Jim

Post a reply to this message