Anyone come across this error when rendering with Mantra?

'UT_NetPacket::read: No such file or directory
mantra: Network Error Missing data in read – possible remote crash'

Any idea what it means or how to reslove it? Thanks.

I'm getting this same problem, and it happens randomly but reasonably often – about 25% of the time. For me, it only seems to manifest itself during network rendering, and thus far I've only had multi-core machines in my render farm – another forum post seemed to indicate that someone rendering on a single dual-core machine was also getting these problems, so maybe multi-core is the problem?

Would be great if someone had a good idea on how to fix it – there are some other threads on the forum that touch on it, but the things suggested there (like making sure that /etc/hosts is consistent across all hosts) haven't helped me fix my problems yet.

Anyone else seen this and had any success in fixing it for good? Or if any devs are reading this, it would be great if you gave me a shout and I can provide you with any other info you might want to help track it down.

I have this problem too, multiple cores, mantra crashes all the time.

I'm turning off the max threads and set mantra -n 4, so this way 1 core renders 1 tile. It's fine this way just a bit annoying.

Sending frames per core on a render farm recently crashed every time without fail using MR

Well, MR aside for the moment because that would(I think) be unrelated, what particular version are you guys using? Any reason you're not using -j to multithread? We've been using the latter for the last couple of weeks in production and haven't noticed anything that could be traced back to mantra. I know that the the thread setting doesn't allow rendering across machines, but I've always had issues with ‘-n’ anyway. You are aware that when you use that each thread needs it's own mantra session along with duplicity in memory and network usage, etc.? Any chance you're pushing the machines too hard?

Cheers,

J.C.

I know that -n gives a “shock”. Also I try here always the latest build.
Will give -j a go, thanks for input.

First, make sure hserver is the same version on all machines. Next, if you check “Use Max Processors”, it will use all processors (multithread) on the machine. So, you can do the following:
mantra -H localhost,machine1,machine2,machine3
This will run on all four machines using max processors (multithreading).

I'm rendering this way on 9 machines & it rocks!

Houdini 9.0.743, SuSe 9.3

Cheers!
steven

Hey Steven, on linux, how is hserver started? When I use -H localhost, everything works as expected, but when I try -H snake, I get mantra: Network Error Unable to contact remote hserver
That's obviously because hserver isn't running on the host snake. When I start hserver on snake manually, everything works.
My question is: can I start hserver on remote hosts automatically when using mantra -H, or do I always have to log in and start it manually? Mind you, what login to the remote host and start mantra (without -H option) then hserver gets running automatically.
I would have thought that running hserver -h snake would start it, but that gives me: Existing server found at localhost:1714, it doesn't start hserver on snake.

I would love to know the mechanism for this.

No, you can't. When you run mantra locally, it can start hserver because it's already running on the same machine. Mind you, I don't see why you can't just install hserver on snake and have it start automatically whenever the machine starts up.

edward
Mind you, I don't see why you can't just install hserver on snake and have it start automatically whenever the machine starts up.

I have to further investigate, but my impression was that when hserver is started up as root, mantra running as a different user, was unable to connect. It could totally be the setup I tried it on, privileges probably. I'll let you know.

we solve it and we just put off our fire wall, so that hserver and mantra can communicate. By the way we raise the bucket size to 32 it works well.

i hope i helped you all.

Disabling fire wall? Bad Mainframe, bad Mainframe twisted

You'd better pierce a little hole in it