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