POV-Ray : Newsgroups : povray.binaries.images : Operation timed out? Server Time
29 Mar 2024 03:59:40 EDT (-0400)
  Operation timed out? (Message 11 to 20 of 24)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 4 Messages >>>
From: Thorsten
Subject: Re: Operation timed out?
Date: 10 Aug 2020 15:35:43
Message: <5f31a18f$1@news.povray.org>
On 10.08.2020 14:05, William F Pokorny wrote:
> 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... :-)

No, that is pretty much the only answer available.

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

Well, really slow. Remember that this means messages take 10 seconds to 
be passed from one thread to the next. Normally threads should be called 
every few milliseconds. If the operating system needs ten seconds to 
switch threads, something is wrong, or the receiving end is "gone", 
meaning it crashed. The later is way more likely for a simple scene.

> 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'.

Indeed.

> 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.

The code isn't remaining, it is intentionally C code, so it can be 
ported really everywhere and run on a very low level, with some of the 
message passing APIs around and interact with the thread management 
directly. It will also work even if basically all memory is exhausted by 
using some private pool. For those who want a C++ API, there is one, of 
course. It sits on top of the C code.

> 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.

The question is not where the message is sent, but where it should be 
received. The whole POVMS code has extensive debugging support that can 
be enabled by macros.

> 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.

No, this isn't really the case. By the time you get into trouble with 
the message passing, you are already in such a mess that you likely 
cannot recover in a meaningful way. The most likely cause of the message 
passing to stall for a simple scene is actually that the receiving side 
crashed in some way, i.e. by an exception that left the message handler 
in an unexpected way.

> 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.

No, it is also a core of the threading functions. What it really does it 
provide a separation between the frontend and the backend such that you 
can actually render multiple scenes or images of a scene at the same 
time. It also allows you to do this while the frontend GUI and the 
backend(s) run in separate processes. It also is the code used for 
render continuation (that actually works even if you switch systems in 
between) and a bunch of other stuff.

> 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.

Suggestion: If you don't understand some code, it is a clear indication 
you should stay away from it until you do ;-)

VFE is basically a quick solution Chris Cason implemented early in the 
3.7 development because something was needed for the Windows frontend. 
It is by no means required. It is just a collection of stuff that is 
really mostly meant for the Windows frontend, and does not work all that 
well for a command line frontend. Actually, in 3.7 the command line 
frontend used to be in there and would compile by enabling the main 
function - I know because this feature was a major part of the 
development process of 3.7.

> (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,

Well, the code could be added. But you are right that the error handling 
of INI files was not finished in time.

Thorsten


Post a reply to this message

From: Thorsten
Subject: Re: Operation timed out?
Date: 10 Aug 2020 15:36:49
Message: <5f31a1d1$1@news.povray.org>
On 09.08.2020 00:23, Jörg "Yadgar" Bleimann wrote:
> 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

It is a fatal error. And you get it from two threads.

Thorsten


Post a reply to this message

From: Alain Martel
Subject: Re: Operation timed out?
Date: 11 Aug 2020 12:13:07
Message: <5f32c393$1@news.povray.org>

> On 10.08.2020 14:05, William F Pokorny wrote:
>> 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... :-)
> 
> No, that is pretty much the only answer available.
> 
>> Reasons could be many. Paging (using too much memory). Systems is 
>> otherwise overloaded etc - or just slow.
> 
> Well, really slow. Remember that this means messages take 10 seconds to 
> be passed from one thread to the next. Normally threads should be called 
> every few milliseconds. If the operating system needs ten seconds to 
> switch threads, something is wrong, or the receiving end is "gone", 
> meaning it crashed. The later is way more likely for a simple scene.
> 
>> 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'.
> 
> Indeed.
> 
>> 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.
> 
> The code isn't remaining, it is intentionally C code, so it can be 
> ported really everywhere and run on a very low level, with some of the 
> message passing APIs around and interact with the thread management 
> directly. It will also work even if basically all memory is exhausted by 
> using some private pool. For those who want a C++ API, there is one, of 
> course. It sits on top of the C code.
> 
>> 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.
> 
> The question is not where the message is sent, but where it should be 
> received. The whole POVMS code has extensive debugging support that can 
> be enabled by macros.
> 
>> 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.
> 
> No, this isn't really the case. By the time you get into trouble with 
> the message passing, you are already in such a mess that you likely 
> cannot recover in a meaningful way. The most likely cause of the message 
> passing to stall for a simple scene is actually that the receiving side 
> crashed in some way, i.e. by an exception that left the message handler 
> in an unexpected way.
> 
>> 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.
> 
> No, it is also a core of the threading functions. What it really does it 
> provide a separation between the frontend and the backend such that you 
> can actually render multiple scenes or images of a scene at the same 
> time. It also allows you to do this while the frontend GUI and the 
> backend(s) run in separate processes. It also is the code used for 
> render continuation (that actually works even if you switch systems in 
> between) and a bunch of other stuff.
> 
>> 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.
> 
> Suggestion: If you don't understand some code, it is a clear indication 
> you should stay away from it until you do ;-)
> 
> VFE is basically a quick solution Chris Cason implemented early in the 
> 3.7 development because something was needed for the Windows frontend. 
> It is by no means required. It is just a collection of stuff that is 
> really mostly meant for the Windows frontend, and does not work all that 
> well for a command line frontend. Actually, in 3.7 the command line 
> frontend used to be in there and would compile by enabling the main 
> function - I know because this feature was a major part of the 
> development process of 3.7.
> 
>> (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,
> 
> Well, the code could be added. But you are right that the error handling 
> of INI files was not finished in time.
> 
> Thorsten
> 
> 

where two or more processes or threads are asking for the same resource 
at the same time and each is waiting for the other to finish using that 
resource.


Post a reply to this message

From: Thorsten
Subject: Re: Operation timed out?
Date: 11 Aug 2020 13:29:40
Message: <5f32d584@news.povray.org>
On 11.08.2020 18:13, Alain Martel wrote:

> where two or more processes or threads are asking for the same resource 
> at the same time and each is waiting for the other to finish using that 
> resource.

No, this is not how POVMS is written. I am its author ;-)

Thorsten


Post a reply to this message

From: William F Pokorny
Subject: Re: Operation timed out?
Date: 12 Aug 2020 10:13:34
Message: <5f33f90e$1@news.povray.org>
On 8/10/20 3:35 PM, Thorsten wrote:
> On 10.08.2020 14:05, William F Pokorny wrote:
...
> 

The additional information is appreciated Thorsten. Thank you.

Bill P.


Post a reply to this message

From: Alain Martel
Subject: Re: Operation timed out?
Date: 12 Aug 2020 13:09:00
Message: <5f34222c$1@news.povray.org>

> On 11.08.2020 18:13, Alain Martel wrote:

>> condition where two or more processes or threads are asking for the 
>> same resource at the same time and each is waiting for the other to 
>> finish using that resource.
> 
> No, this is not how POVMS is written. I am its author ;-)
> 
> Thorsten

One of the process may not be POV-Ray related.


Post a reply to this message

From: Thorsten
Subject: Re: Operation timed out?
Date: 12 Aug 2020 13:23:55
Message: <5f3425ab$1@news.povray.org>
On 12.08.2020 19:08, Alain Martel wrote:

>> On 11.08.2020 18:13, Alain Martel wrote:

>>> condition where two or more processes or threads are asking for the 
>>> same resource at the same time and each is waiting for the other to 
>>> finish using that resource.
>>
>> No, this is not how POVMS is written. I am its author ;-)
>>
>> Thorsten
> 
> One of the process may not be POV-Ray related.

The error message "Operation timed out" comes from inside POV-Ray.


Post a reply to this message

From: Jörg "Yadgar" Bleimann
Subject: Re: Operation timed out?
Date: 13 Aug 2020 22:10:23
Message: <5f35f28f$1@news.povray.org>
Hi(gh)!

On 10.08.20 14:05, William F Pokorny wrote:

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

Where - in the command line? This results in an error: "Failed to parse 
command line option"

See you in Khyberspace!

Yadgar


Post a reply to this message

From: William F Pokorny
Subject: Re: Operation timed out?
Date: 14 Aug 2020 07:06:46
Message: <5f367046$1@news.povray.org>

> Hi(gh)!
> 
> On 10.08.20 14:05, William F Pokorny wrote:
> 
>> Use -cc so the state file work does not get done.
> 
> Where - in the command line? This results in an error: "Failed to parse 
> command line option"
> 
> See you in Khyberspace!
> 
> Yadgar

OK. Expect this means you are running v3.7?

This option was added to v3.8 by Christoph to re-enable continuation 
capability available in earlier the v3.7 versions of POV-Ray.

Bill P.


Post a reply to this message

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

On 14.08.20 13:06, William F Pokorny wrote:

> OK. Expect this means you are running v3.7?

Yes, I do... this probably means I have to do POVEarth animation loops 
manually! Ars longa, vita brevis...

See you in Khyberspace!

Yadgar


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 4 Messages >>>

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