POV-Ray : Newsgroups : povray.binaries.images : Operation timed out? Server Time
28 Mar 2024 16:24:36 EDT (-0400)
  Operation timed out? (Message 1 to 10 of 24)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Jörg "Yadgar" Bleimann
Subject: Operation timed out?
Date: 8 Aug 2020 18:23:13
Message: <5f2f25d1$1@news.povray.org>
Hi(gh)!

Meanwhile I got the rendering of ASTER tile terrain reliefs running once 
more - albeit only with Earth as a simple sphere, if I add realistic 
flattening, the scene remains empty except for the ocean and basic Earth 
sphere - strange!

But when I try to render a sequence of consecutive images, such as

+ipovearth.pov +ogeorgia_panorama-.png +w1024 +h768 +a0.3 +ki0 +kf719 
+kfi0 +kff719 (a simple camera rotation pull)

after completing the first frame, I get:

Operation timed out
Operation timed out
Render failed

Why?

See you in Khyberspace!

Yadgar


Post a reply to this message

From: Alain Martel
Subject: Re: Operation timed out?
Date: 9 Aug 2020 17:39:04
Message: <5f306cf8$1@news.povray.org>
Le 2020-08-08 à 18:23, Jörg "Yadgar" Bleimann a écrit :
> Hi(gh)!
> 
> Meanwhile I got the rendering of ASTER tile terrain reliefs running once 
> more - albeit only with Earth as a simple sphere, if I add realistic 
> flattening, the scene remains empty except for the ocean and basic Earth 
> sphere - strange!
>> 
> Yadgar

When you add the flattening or oblatenes, how do you do it ?

Normally, just adding a scale after the modelling should do the trick.

scale<Oblatenes, 1, Oblatenes>


Post a reply to this message

From: Jörg "Yadgar" Bleimann
Subject: Re: Operation timed out?
Date: 9 Aug 2020 18:14:03
Message: <5f30752b$1@news.povray.org>
Hi(gh)!

On 09.08.20 23:39, Alain Martel wrote:

> When you add the flattening or oblatenes, how do you do it ?

With the calculation of the mesh2 vertices:

#declare V_vec_Arr[c] = 
(rd+hval)*<sin(radians(-longstart-(b/xdim)*longsize))*(1-flattening)*cos(radians(latstart+(a/ydim)*latsize)),

(1-flattening)*sin(radians(latstart+(a/ydim)*latsize)), 
cos(radians(-longstart-(b/xdim)*longsize))*(1-flattening)*cos(radians(latstart+(a/ydim)*latsize))>;

> 
> Normally, just adding a scale after the modelling should do the trick.
> 
> scale<Oblatenes, 1, Oblatenes>

Worth a try...

See you in Khyberspace!

Yadgar


Post a reply to this message

From: Jörg "Yadgar" Bleimann
Subject: Re: Operation timed out?
Date: 10 Aug 2020 06:15:00
Message: <5f311e24$1@news.povray.org>
On 10.08.20 00:14, Jörg "Yadgar" Bleimann wrote:

>> Normally, just adding a scale after the modelling should do the trick.
>>
>> scale<Oblatenes, 1, Oblatenes>
> 
> Worth a try...
> 
> See you in Khyberspace!
> 
> Yadgar

Did not work either - no terrain relief visible in the scene!


Post a reply to this message

From: jr
Subject: Re: Operation timed out?
Date: 10 Aug 2020 06:50:00
Message: <web.5f3125c248fcdfd64d00143e0@news.povray.org>
hi,

=?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
> On 10.08.20 00:14, Jörg "Yadgar" Bleimann wrote:
> ...
> Did not work either - no terrain relief visible in the scene!

have never seen an "Operation timed out" error, and searching the (installed)
documentation gave no clue.  it would be useful to hear from people who know the
code, in which circumstances/situations that error can happen.


regards, jr.


Post a reply to this message

From: Bald Eagle
Subject: Re: Operation timed out?
Date: 10 Aug 2020 07:25:00
Message: <web.5f312e1a48fcdfd61f9dae300@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:

> it would be useful to hear from people who know the
> code, in which circumstances/situations that error can happen.

Is there a way to grep the source code to find out where that gets spit out, as
a starting point for backtracking?
(I'd recommend 3.6 source, as IIRC 3.7 has all the complicated, hard-to-follow
multithreading.  If it's in 3.6, and it's still a mystery, then what is learned
from studying the code can be used as a roadmap to 3.7)


Post a reply to this message

From: jr
Subject: Re: Operation timed out?
Date: 10 Aug 2020 07:50:01
Message: <web.5f3133c148fcdfd64d00143e0@news.povray.org>
hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > it would be useful to hear from people who know the
> > code, in which circumstances/situations that error can happen.
>
> Is there a way to grep the source code to find out where that gets spit out, as
> a starting point for backtracking?

sure.  something like
  $ find /path/to/povray/src -type f -exec grep -Hn 'search term' {} \;

('-H' to make 'grep' report the file name, '-n' for line number; add '-i' to
make the search case insensitive)

> ...

meanwhile I found two relevant threads in the newsgroups:

<http://news.povray.org/povray.general/thread/%3C52dcd2b3$1@news.povray.org%3E/>
<http://news.povray.org/povray.general/thread/%3C56a2bec2%241%40news.povray.org%3E/>


regards, jr.


Post a reply to this message

From: William F Pokorny
Subject: Re: Operation timed out?
Date: 10 Aug 2020 08:05:22
Message: <5f313802$1@news.povray.org>
On 8/10/20 6:47 AM, jr wrote:
...
> 
> have never seen an "Operation timed out" error, and searching the (installed)
> documentation gave no clue.  it would be useful to hear from people who know the
> code, in which circumstances/situations that error can happen.
> 
...

Something is running too slow is the non helpful, short answer, I didn't 
post yesterday - because it sound to me ears a little snarky despite 
being accurate... :-)

Reasons could be many. Paging (using too much memory). Systems is 
otherwise overloaded etc - or just slow.

If the message hasn't somewhere been assembled from parts and pieces, 
it's probably a 'kTimeoutErr' using a 10 (second?) default set 
indirectly by 'kDefaultTimeout'.

The only use of kTimeoutErr sits in a chunk of remaining 'c' code inside 
the message passing system (source/povms/povms.c). If it is this error, 
it can happen when sending a stream of data - somewhere.

If you can compile yourself, there looks to be a _DEBUG macro in the 
message code which when set extends the timeout to 100 (seconds?) if 
running that bit of code under a debugger. Other debugging / workarounds 
would require much more twiddling.

Aside: I've been digging around again in the frontend code and looking 
some at this message passing system. Error wise, all over in the 3.7 
code, there is a fair bit of error handling that looks to have been left 
hanging - incomplete / not fully flushed out. It would certainly be 
helpful in this case to know more about the 'message' being sent on the 
timeout.

Possible Workarounds:

Try it again.

Be sure your machine isn't 'at all' busy with anything else when you 
kick off the animation.

If your machine supports >1 work thread use fewer or one (+wt1) and see 
if you get the error.

If you're running large render block sizes, shrink them.

Use -cc so the state file work does not get done.

Use a ramdisk (or if not that a faster disk) for all input and output 
files if possible.

Aside 2:
I don't much understand the message passing system code, but it looks 
like most information internally is getting passed around using it. I 
think the idea was to eventually be able to support rendering remotely 
on a large cluster of machines with a single controlling gui/entity.

The remote capability doesn't especially interest me with povr, and I'm 
carrying the question: Should I try replace it / change it / simplify 
the vfe/povms stuff... Don't know. Some conceptual parts are OK - ini / 
command line parsing mostly in the vfe, but then the truth is the 
reality for unix/linux is this common *x parsing is quite weak and has 
open bugs. One of which I recently ran down - only to find another right 
behind it... Many flag / file command line parsing errors end up as ini 
file not found errors... (1)

(1) - On unix/linux, if you are not running 'povr,' you are mostly not 
seeing any actual command line / ini parsing errors except a catch all 
thing which, IIRC, I think Jerome added at some point during v3.7 
development which returns the command line with a generic message 
something went wrong. Anyway, guess my mind is drifting from the 
original subject - but another tangled in error reporting not being that 
helpful.

Bill P.


Post a reply to this message

From: jr
Subject: Re: Operation timed out?
Date: 10 Aug 2020 09:00:09
Message: <web.5f31433748fcdfd64d00143e0@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/10/20 6:47 AM, jr wrote:
> ...
> > have never seen an "Operation timed out" error, and searching the (installed)
> > documentation gave no clue.  it would be useful to hear from people who know the
> > code, in which circumstances/situations that error can happen.
> >
> Something is running too slow is the non helpful, short answer, I didn't
> post yesterday - because it sound to me ears a little snarky despite
> being accurate... :-)
>
> Reasons could be many. Paging (using too much memory). Systems is
> otherwise overloaded etc - or just slow.

after having read through the threads referenced in earlier post, I'm
almostready to add a rant of my own.  about how people who migrate to GNU/Linux
are often unaware that now they must, on occasion, don the system administrator
hat.  but I won't.  ;-)

> ...

snipped the explanatory part, for which thanks.

> Aside 2:
> I don't much understand the message passing system code, but it looks
> like most information internally is getting passed around using it. I
> think the idea was to eventually be able to support rendering remotely
> on a large cluster of machines with a single controlling gui/entity.

that is interesting.  if instead of "large cluster" one had this capability for
the LAN.  I'm sure that many users, like me, have more than one computer on the
LAN, and it would be way cool if POV-Ray could exploit that.

> ...

regards, jr.


Post a reply to this message

From: MichaelJF
Subject: Re: Operation timed out?
Date: 10 Aug 2020 13:36:26
Message: <5f31859a@news.povray.org>
Am 09.08.2020 um 00:23 schrieb Jörg "Yadgar" Bleimann:
> Hi(gh)!
> 
> Meanwhile I got the rendering of ASTER tile terrain reliefs running once 
> more - albeit only with Earth as a simple sphere, if I add realistic 
> flattening, the scene remains empty except for the ocean and basic Earth 
> sphere - strange!
> 
> But when I try to render a sequence of consecutive images, such as
> 
> +ipovearth.pov +ogeorgia_panorama-.png +w1024 +h768 +a0.3 +ki0 +kf719 
> +kfi0 +kff719 (a simple camera rotation pull)
> 
> after completing the first frame, I get:
> 
> Operation timed out
> Operation timed out
> Render failed
> 
> Why?
> 
> See you in Khyberspace!
> 
> Yadgar
I have no real idea why this happenes time and again. I expierenced it 
time and again myself. In most cases restarting the rendering with +c at 
the command line helps. And in this cases saving and loading radiosity 
data can save some hours.

Best regards
Michael


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.