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