It realy is irritating in PovRay 3.6 how it can hang entire system (in 3.5 
also, but in 3.6 this effect is stronger).

Just create a simpel scene complicated enought that it will want to use say 
1.5 GB memory in shooting photons pahse.

Even on render priority low, it will cause most machines to hang, i.e. 
my Athlon 2200 512 RAM WinXP was hanign for about 15 minutes before 
responding to alt+f4 and other keys to finaly kill povray application.

In this time no other process could get CPU time, so all internets 
connections broke (because server/clients programs was also hanging) and 
even after each move of mouse pointer user has to wait 15-20 seconds for 
reaction on (GeForce 4 Fx 128 ram card).


Now for some constructive critics / sugestions,
- pov 3.5 did better job with priority settings and was more nice with 
sharing thime with other processes

- I suggest adding an ini options:
  +meml 128  memory limit in MB, render will stop with an error if it will   
    try to alocate more memory  
  +old CPU cycle (80%, 90%) - I suggest it should also be an ini option
  +old priority - it should be also an ini option

- new duty cycle / priority settings - for memory, i.e. that PovRay will 
delay for i.e. 1 second every second of memory swapping. 
Explanation - if povray will detect that each memory operations took to 
much time, say simply allocation of 4 mb buffer tooks almost 1 second, it 
will assume that it is causing heavy swapping in system, and will sleep for 
several seconds if told to do so, to give user a change to kill povray


- I think that photons related code does not check if STOP button was 
pressed (or it does it rearly)

Post a reply to this message

In article <Xns9498E9DB12C0Braf256com@203.29.75.35>, "Rafal 'Raf256' Maj" 
<spa### [at] raf256com> wrote:

> It realy is irritating in PovRay 3.6 how it can hang entire system (in 3.5
> also, but in 3.6 this effect is stronger).

The effect you describe is not something POV-Ray is causing  If your OS is
too stupid to correctly give priority to other processes while one
application requires a lot of swap space, change your OS.  You cannot blame
POV-Ray is your hardware and OS are not up for the scenes you want to
render.  In fact, there is absolutely nothing POV-Ray could do about it
other than refusing to render the scene at all.  Sorry!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <Xns9498E9DB12C0Braf256com@203.29.75.35>, "Rafal 'Raf256' Maj" 
<spa### [at] raf256com> wrote:

> my Athlon 2200 512 RAM WinXP

Try one of the systems below.  They will not exhibt any of the problems you
are describing, even if your scene takes 20 GB of memory:

<http://www-1.ibm.com/servers/eserver/pseries/hardware/workstations/>

I am serious, this is no joke.  If you seriously have scenes the size you
are talking about on a regular basis, these systems will be a good solution.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

tho### [at] trfde news:403a7989$1@news.povray.org

>> It realy is irritating in PovRay 3.6 how it can hang entire system
>> (in 3.5 also, but in 3.6 this effect is stronger).
 
> The effect you describe is not something POV-Ray is causing  If your
> OS is too stupid to correctly give priority to other processes while
> one application requires a lot of swap space, change your OS.  You
> cannot blame POV-Ray is your hardware and OS are not up for the scenes
> you want to render.  In fact, there is absolutely nothing POV-Ray
> could do about it other than refusing to render the scene at all. 
> Sorry! 

Yes, I agree that OS should handle this situation better.

But - PovRay could take this into accound and allow an option to correct 
stupid OS behavior.

Setting hard memory limit could be step one, and I guess it's realy easy to 
implement. It will just refuse to render, but it will save stress frome 
users who set to high quality/photons (by mistate) or mis-calculated needed 
memory limit.

Second thing - detecting to stron swapping and forcing sleeping then also 
is something that can be done probably?

I'll try to implement hard memory limit, can I download code of pov 3.6 for 
VC++? If I'll implement this in next 2 weeks (much real-life) will it has 
chance of beeing in final 3.6?

Btw my friend with start to play with Pov, find simillar problem very 
iritating, 

#local I=1; While (I<1000)
  box { ... }
#local I=I-1;  #end

this infine loop (made by mistake -1 instead of +1) wil cause simmilar 
problems, and adding memory limit, and more often check if STOP button was 
pressed in POV_ALLOC (afair) parsing, and photons code will help


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Rafal 'Raf256' Maj wrote:

> I'll try to implement hard memory limit, can I download code of pov 3.6 for
> VC++? If I'll implement this in next 2 weeks (much real-life) will it has
> chance of beeing in final 3.6?

The code for v3.6 is not available to the public.

-- 
Ken Tyler - POV-Ray Technical Assistance Group

Post a reply to this message

On 23 Feb 2004 16:59:34 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> It realy is irritating in PovRay 3.6 how it can hang entire system (in 3.5 
> also

In the next thread you said you are able to fix it. Sources of 3.5 are
available, you claimed you are programmer. What do you need more ?

> but in 3.6 this effect is stronger).

There is povray.beta-test group. Rules for reporting problems are clear. There
is a warning about risk using beta versions. Please, read second part of
second sentence of POV-Ray 3.6 beta announcement at http://www.povray.org/

> Now for some constructive critics / sugestions,

Thanks, constructive critics are welcome.

> - pov 3.5 did better job with priority settings and was more nice with 
> sharing thime with other processes

Minimal sample + statistics comparison 3.5 vs 3.6 from the same machine ?

> I suggest adding an ini options:
> +meml 128  memory limit in MB, render will stop with an error if it will   
>   try to alocate more memory  

My personal opinion is that POV-Ray is not for dummies: if you type +W8000
+H6000 then you know it will be large image, when you type
media{}/isosurface{}/parametrics{} then you know it will slow down, when you
turn on photons you should be ready for memory/CPU usage. Moreover "6.10.2
Using Photon Mapping in Your Scene" describes techinics about limiting number
of photons aka memory usage in photons{}.

> +old CPU cycle (80%, 90%) - I suggest it should also be an ini option
> +old priority - it should be also an ini option

where is explanation what it does ?

> - new duty cycle / priority settings - for memory, i.e. that PovRay will 
> delay for i.e. 1 second every second of memory swapping. 

How do you want to fix memory swapping in POV-Ray for Windows if you do not
understand that it is not a task of POV-Ray ?

> Explanation - if povray will detect that each memory operations took to 
> much time, say simply allocation of 4 mb buffer tooks almost 1 second, it 
> will assume that it is causing heavy swapping in system, and will sleep for 
> several seconds if told to do so, to give user a change to kill povray

IIRC current beta expires in middle of March. Until then can you write
universal function based on 3.5 sources which recognizes than next line of
code takes 4 mb ?

> - I think that photons related code does not check if STOP button was 
> pressed (or it does it rearly)

That's the only sensible sentence if real. Please provide (povray.beta-test)
script so others could confirm it.

ABX

Post a reply to this message

Rafal 'Raf256' Maj wrote:
> - I think that photons related code does not check if STOP button was 
> pressed (or it does it rearly)
try using alt+g instead of pressing the button in the user interface. i 
had the experience that the response was much faster, sometimes the 
button didn't respond until the render was finished. i guess the reason 
is that the interface has a lower priority.
bye,
	Marc


-- 
---------------------------------
and god said: let there be a light_source { location SUN look_at EARTH, 
rgb SUNLIGHT }

Post a reply to this message

abx### [at] abxartpl news:pq3m30ldlcikqc9kfo4mm1tljdiqefkqji@4ax.com

> In the next thread you said you are able to fix it. Sources of 3.5 are
> available, you claimed you are programmer. What do you need more ?

Time :) *If* no new jobs / personal life probles will apear I can start in 
about week from now.
 
> My personal opinion is that POV-Ray is not for dummies: if you type
> +W8000 +H6000 then you know it will be large image, when you type

But if You have just  photons { spacing 0.001 } it is not quite easy to 
calculate memory usage. OFcourse You can use i.e.  1.0  0.5 0.25 assuming 
it will tke (AFAIR) x2 more memory (x3 for modeia), but...

> techinics about limiting number of photons aka memory usage in
> photons{}. 

Well, right... but memory limit imho can be still usefull.
 
>> +old CPU cycle (80%, 90%) - I suggest it should also be an ini option
>> +old priority - it should be also an ini option
> where is explanation what it does ?

I ment "old" (current in 3.5 and 3.6) options.

>> - new duty cycle / priority settings - for memory, i.e. that PovRay
>> will delay for i.e. 1 second every second of memory swapping. 
> How do you want to fix memory swapping in POV-Ray for Windows if you
> do not understand that it is not a task of POV-Ray ?

Ofcourse I do understand it is not responsibility of Pov, but users will be  
heapy if it will do something extra. 
 
> IIRC current beta expires in middle of March. Until then can you write
> universal function based on 3.5 sources which recognizes than next
> line of code takes 4 mb ?

There was function linke afir POV_ALLOC that allocated memory and btw. 
calculates peek usage ustatistics. Changing it should help, like

void* pov_alloc_function( size_t size) {
  
  if ( statistics_memory_allocated += size  > max_mem_size )  
    povray_error(...)
  else malloc( ... )

Post a reply to this message

One day......   I'll spend 20.000 euro's for something like that or better
:P

Post a reply to this message

On 24 Feb 2004 11:07:24 -0500, "Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote:
> But if You have just  photons { spacing 0.001 } it is not quite easy to 
> calculate memory usage.
>
> > techinics about limiting number of photons aka memory usage in
> > photons{}. 
>
> Well, right... but memory limit imho can be still usefull.

How, if you just said "it is not quite easy to calculate memory"?
If you can't calculate memory usage yourself, how can you choose value for
memory limit for option ??????

> > > +old CPU cycle (80%, 90%) - I suggest it should also be an ini option
> > > +old priority - it should be also an ini option
> > where is explanation what it does ?
>
> I ment "old" (current in 3.5 and 3.6) options.

3.6 threading is almost completly rewritten. It's simply impossible.

> > > - new duty cycle / priority settings - for memory, i.e. that PovRay
> > > will delay for i.e. 1 second every second of memory swapping. 
> > How do you want to fix memory swapping in POV-Ray for Windows if you
> > do not understand that it is not a task of POV-Ray ?
>
> Ofcourse I do understand it is not responsibility of Pov, but users will be  
> heapy if it will do something extra. 

Sure, just give us a reference to msdn where possibilities of installing
callback function for memory managers of all versions of Windowses are
designed. Or better, give it to yourself and provide ready solution.

> > IIRC current beta expires in middle of March. Until then can you write
> > universal function based on 3.5 sources which recognizes than next
> > line of code takes 4 mb ?
>
> There was function linke afir POV_ALLOC that allocated memory and btw. 
> calculates peek usage ustatistics.

How does it affects storing local variables ?

Really, if you do not want memory to swap, just turn swap file off. Otherwise
such limit is useless since that's not management of POV-Ray but OS. In other
words if you have 512 MB RAM, render which uses 300 MB, 10MB of PDF in Acrobat
Reader, Open Office large document and a few other things, your memory still
will be swaped. You are free to install memory usage monitor (and usually one
is already within Windowses) to verify amount of memory POV-Ray used and you
can kill POV-Ray then.

Again, the only valid point (which does not excuse "fu*ing" word in the world
of volunteers) is that perhaps photons stuff does not leave thread with
photons calculation often enough. If you think it is the case please provide
(follow-up set) script so somebody could confirm your observation. Not every
photon usage can be affected by such issue.

Before next "bug report" please read:
  Date: Wed, 28 Jan 2004 06:39:19 -0800
  From: Ken <ken### [at] tagpovrayorg>
  Newsgroups: povray.beta-test
  Subject: Beta-test Bug Report Requirements

ABX

Post a reply to this message