[pwrdesign]

Finally I managed to mount it with:

mount -t cifs //nova.local/data /nova/data

But now if I browse to nova/data that folder is empty

[tom]

I didn't understand .local concept and why did you do that. The only thing you had to do was navigating to the Hosts tab under network settings and add "nova" with its IP. So, the mount line would be:
mount -t cifs //nova/data /nova/data

[pwrdesign]

I didn't understand .local concept and why did you do that. The only thing you had to do was navigating to the Hosts tab under network settings and add "nova" with its IP. So, the mount line would be:
mount -t cifs //nova/data /nova/data

I did, and I've tryed that mount-line 1000 times. But it dosnt work.

Since we dont have any internal DNS here, we added .local, and after that I could mount it. Though nothing is visible in the nova/data folder...

I'm not a linux hacker, and atm im sitting between you, a linux-skilled friend and my IT department Having no clue what I'm doing... hehe

Here is a screen of my host file, admin/network/hosts and whats happening when Im trying to mount.



Are you shure that this can have anything to do with our problem, as long as the data is situated under /nova/data (as when I mount with IP)

The problem seems to be that your MXCL searches locally and my searches on the network. / and //

If we leave the mounting-problem-idea, Isn't there anything else we can try?

[tom]

There's no difference about Maxwell between us. The problem is Ubuntu's error there. I don't know which version you have but I use 7.10 w/ kernel 2.6.22-14-generic here and mount command worked flawlessly. In yours, it says that's not a proper UNC path and that's really ridiculous since it IS a valid UNC path with proper syntax. I'm out out ideas at this point and I'm not a Linux guru, too. I just know Maxwell works here when you could make it accept the mounting process like I described but yours gives a fantastic error that I don't know.

[pwrdesign]

There's no difference about Maxwell between us. The problem is Ubuntu's error there. I don't know which version you have but I use 7.10 w/ kernel 2.6.22-14-generic here and mount command worked flawlessly. In yours, it says that's not a proper UNC path and that's really ridiculous since it IS a valid UNC path with proper syntax. I'm out out ideas at this point and I'm not a Linux guru, too. I just know Maxwell works here when you could make it accept the mounting process like I described but yours gives a fantastic error that I don't know.

I'm running 2.6.22-14-server, could that have to do with it?

I've managed to trick my Linux Guru-friend to get here after he quit work.
Everything is possible when it comes to beer

We'll look into everything again, and also try to install the generic version on one of my other servers, to see if that makes any difference.

I'll report here during the evening

[tom]

It could be something to do with smbfs, because I only tested it and I can confirm it works. Before setting up another version, try to make smbfs mount work.

[pwrdesign]

Hello Tom!

We finally got it to work!
The solution was:

When we added the job, and picked the MXS file, we got a searchpath that was: //Nova/data/Workspace....etc

So we mounted the share with mount -t cifs //192.168.151.84/data /Nova/data

So after this was done we could sucessfully launch a job from my win workstation!

We've seen a few problems now though.

In Maxwell Studio on my Workstation where I always will start jobs, I've changed the search paths for materials and textures to the UNC path.

The strange thing that happened was that we launched a Co-Op job that went through, rendered all the way, and merged the MXI successfully.

Next time we tryed with the same MXS file, the render failed on corvette due to a texture that it couldnt find.

This material that caused the failure was an old material that I've used for years. Though if I look in the material the search path of the texture is y:/

Does that really matter?

What should I do now?
Even if I add the correct UNC path for bitmaps in the Add job dialog I get the same crash.

MXS files without textures renders fine!

When it comes to render speed, my "Dual Quad Core 5335 Win32" machine renders abit faster than the "Dual Quad Core 5345 Linux64" machine. Like 32sec instead of 33 sec, anything that seems strange with that? I guess that the Linux64 version is less optimized than the Win32 version?

/ Patrik

[tom]

The solution was:

When we added the job, and picked the MXS file, we got a searchpath that was: //Nova/data/Workspace....etc

So we mounted the share with mount -t cifs //192.168.151.84/data /Nova/data

That's good to know! I need to test this here, too.

The strange thing that happened was that we launched a Co-Op job that went through, rendered all the way, and merged the MXI successfully.

Next time we tryed with the same MXS file, the render failed on corvette due to a texture that it couldnt find.

This material that caused the failure was an old material that I've used for years. Though if I look in the material the search path of the texture is y:/

Does that really matter?

As there's no Y: available, it had to find it under defined search path or at least in the same folder with the scene. But then how it could render in the first attempt... Interesting.

Even if I add the correct UNC path for bitmaps in the Add job dialog I get the same crash.

OK, we will check this.

When it comes to render speed, my "Dual Quad Core 5335 Win32" machine renders abit faster than the "Dual Quad Core 5345 Linux64" machine. Like 32sec instead of 33 sec, anything that seems strange with that? I guess that the Linux64 version is less optimized than the Win32 version?

Yes, currently Linux version runs slower than Windows one does. More optimizations will be possible later.

[pwrdesign]

Good morning!

When I get to work I'll install the next 2 machines with linux desktop.

But SHOULD it be enough if I change the search-paths in studio + always add the correct searchpath for bitmaps when I add the job? should tht override the searchpaths in the MXM?

/ Patrik

[devista]

When it comes to render speed, my "Dual Quad Core 5335 Win32" machine renders abit faster than the "Dual Quad Core 5345 Linux64" machine. Like 32sec instead of 33 sec, anything that seems strange with that? I guess that the Linux64 version is less optimized than the Win32 version?

Yes, currently Linux version runs slower than Windows one does. More optimizations will be possible later.

I have just installed debian 64 and maxwell 64 and very disappointed . with the BENCHWELL.COM 1.6 escene I have obtained for a core2 6600 win64 time: 48m 57 sc bench 219.30 and with an q6600 debian 64 time: 38 m 01 sc bench 282.34 and with the other one time 34 m 59 sc bench 306.8. Is this normal
saludos
luis
sorry for the offtopic

[tom]

I'm not sure, probably it depends on other factors. You can find my entries for comparison on Benchwell.

[pwrdesign]

Tom atm my linux server is rendering a Co-Op render atm with my other win32 nodes! As long as I specify the bitmap search-path it seems to work!

Regarding the speed, my linux machine is about as fast as my win machine, not a huge differance at all.

I'll install ubuntu desktop on my last 2 servers, and I will do more testing later!

[devista]

I'm not sure, probably it depends on other factors. You can find my entries for comparison on Benchwell.

but one is a core 2 and the other two quads 6600 and it is only 10 difference minutes . in http://www.benchwell.com/ for a quad 600 the time is +/- 23 m.

[tom]

Regarding the speed, my linux machine is about as fast as my win machine, not a huge difference at all.

Very interesting. As I've said, it could be my hardware acting slow with Ubuntu or it's about the edition. Anyway, it's nice to hear it works as fast as Win for you.

devista, sorry I cannot follow what are you pointing at exactly. Can you clearly tell me the usernames of entries you're comparing?

[pwrdesign]

Regarding the speed, my linux machine is about as fast as my win machine, not a huge difference at all.

Very interesting. As I've said, it could be my hardware acting slow with Ubuntu or it's about the edition. Anyway, it's nice to hear it works as fast as Win for you.

Ill do some more controlled tests when i've got the rest machines UR