Hi all,

    I've mentioned that I'm working on a patch to POV-Ray that turns it 
into a render server. However, since a goal is to get authors of 
existing parallel render software to include support for the an XRS 
render slave (XML-RPC Render Server), I've drafted (and attached) a 
protocol spec that I submit for your comments. I have a working patch 
made that uses my protocol, which I am cleaning up and preparing for 
release.

Thanks,
George

-- 
-------------------------
George Pantazopoulos
http://www.gammaburst.net

Post a reply to this message

Attachments:
Download 'us-ascii' (15 KB)

George Pantazopoulos wrote:
> render slave (XML-RPC Render Server), I've drafted (and attached) a
> protocol spec that I submit for your comments. I have a working patch
> made that uses my protocol, which I am cleaning up and preparing for
> release.
> 
Two comments: 

(1) Did I miss anything or is there no client authentication?
    Since the only "render farm" I could use is available to more people 
    than me alone, I'd never use something which does not at least have 
    some challenge-response auth. 

(2) In case we have 20 computers for a render task and parsing + photons 
    (only?) takes 5% of total time, then the complete overhead is 100%, i.e. 
    we spend twice as much CPU*computers as necessary. 
    Overcoming this by having the client doing the parsing and send the 
    internal state to the server, however, is probably really hard to do. 
    This is IMO only a problem when rendering animations (per-frame rendering 
    time normally relatively short) or scenes which need a lot of parsing. 

Wolfgang

Post a reply to this message

Hi Wolfgang!

> Two comments: 
> 
> (1) Did I miss anything or is there no client authentication?
>     Since the only "render farm" I could use is available to more people 
>     than me alone, I'd never use something which does not at least have 
>     some challenge-response auth. 
>

       You are certainly right to bring up this point, and I have 
considered it as well. However, ssh already does this better than 
anything I could code up, so I felt I shouldn't try reinventing the wheel.

       I regurlaly run a MegapovXRS server on a remote machine, which I 
connect to by using ssh port forwarding. For the sake of example, say 
the remote (Server) machine is 'caboose' and the local (client) machine 
is 'megatron', and MegapovXRS listens on port 9000. I would start the 
server on caboose with "ssh -L 9123:localhost:9000 megapovXRS". This 
opens a secure connection to the server, which is reachable by 
connecting to megatron:9123. There is no need for any ports to be opened 
on caboose besides the ssh port (22).



> (2) In case we have 20 computers for a render task and parsing + photons 
>     (only?) takes 5% of total time, then the complete overhead is 100%, i.e. 
>     we spend twice as much CPU*computers as necessary. 
>     Overcoming this by having the client doing the parsing and send the 
>     internal state to the server, however, is probably really hard to do. 
>     This is IMO only a problem when rendering animations (per-frame rendering 
>     time normally relatively short) or scenes which need a lot of parsing. 
> 
> Wolfgang
> 

        Say we have 20 computers, and each task takes 100 minutes total 
(per computer). 5 percent parse overhead means 5 minutes per computer is 
spent parsing, and the remaining 95 rendering. That means that (20 cpus 
* 5 minutes parsing/cpu = 100 ) cpu-minutes are spent parsing and (20 
cpus * 95 minutes rendering/cpu = 1900 ) cpu-minutes are spent 
rendering. So the complete overhead is 100 cpu-minutes out of the 2000 
total, which is still 5%, not 100%. Remember, my patch only parses once 
per machine, not once per tile :)

Also, we have a great program called RendView for anims, I'm aiming this 
   program at accelerating high-quality stills :)

Thanks for your comments!
George




-- 
-------------------------
George Pantazopoulos
http://www.gammaburst.net

Post a reply to this message

George Pantazopoulos wrote:
>        You are certainly right to bring up this point, and I have
> considered it as well. However, ssh already does this better than
> anything I could code up, so I felt I shouldn't try reinventing the wheel.
> 
Yes, okay, tunnelling over ssh is perfectly okay from the security point 
of view. Especially if one can make sure that the POV server port is 
not directly accessible from the internet...

>         Say we have 20 computers, and each task takes 100 minutes total
> (per computer). 5 percent parse overhead means 5 minutes per computer is
> spent parsing, and the remaining 95 rendering. That means that (20 cpus
> * 5 minutes parsing/cpu = 100 ) cpu-minutes are spent parsing and (20
> cpus * 95 minutes rendering/cpu = 1900 ) cpu-minutes are spent
> rendering. So the complete overhead is 100 cpu-minutes out of the 2000
> total, which is still 5%, not 100%. Remember, my patch only parses once
> per machine, not once per tile :)
> 
You're certainly correct here. What I was calculating is: we could render 
one complete image from the produced overhead. So, the overhead is 
100% of the CPU cycles required to render one image. 

> Also, we have a great program called RendView for anims, I'm aiming this
>    program at accelerating high-quality stills :)
> 
So, if you have any suggestions / improvements or find bugs in this program, 
please let me know. 

Wolfgang

Post a reply to this message

> 
> Yes, okay, tunnelling over ssh is perfectly okay from the security point 
> of view. Especially if one can make sure that the POV server port is 
> not directly accessible from the internet...
> 

Yeah, a render farm behind a firewall is the target I have in mind.

> 
>>        Say we have 20 computers, and each task takes 100 minutes total
>>(per computer). 5 percent parse overhead means 5 minutes per computer is
>>spent parsing, and the remaining 95 rendering. That means that (20 cpus
>>* 5 minutes parsing/cpu = 100 ) cpu-minutes are spent parsing and (20
>>cpus * 95 minutes rendering/cpu = 1900 ) cpu-minutes are spent
>>rendering. So the complete overhead is 100 cpu-minutes out of the 2000
>>total, which is still 5%, not 100%. Remember, my patch only parses once
>>per machine, not once per tile :)
>>
> 
> You're certainly correct here. What I was calculating is: we could render 
> one complete image from the produced overhead. So, the overhead is 
> 100% of the CPU cycles required to render one image. 
> 
> 

One subimage (tile), not one full-sized image :)


>>Also, we have a great program called RendView for anims, I'm aiming this
>>   program at accelerating high-quality stills :)
>>
> 
> So, if you have any suggestions / improvements or find bugs in this program, 
> please let me know. 
> 
> Wolfgang
> 

I will, and I've wanted to check out your other cool patches as well. 
I've just been so busy lately that I can't even work on my own stuff. 
You've been super-productive lately. What's your secret? :)


-- 
-------------------------
George Pantazopoulos
http://www.gammaburst.net

Post a reply to this message

George Pantazopoulos wrote:
> Yeah, a render farm behind a firewall is the target I have in mind.
> 
The one I could use is _not_ behind a firewall...
(But it's okay; binding the port to the 127.0.0.1 address and/or rejecting 
connections with non-local sources will give a reasonable amount of 
security.)

>> So, if you have any suggestions / improvements or find bugs in this program,
>> please let me know.
>> 
> I will, and I've wanted to check out your other cool patches as well.
> I've just been so busy lately that I can't even work on my own stuff.
> You've been super-productive lately. What's your secret? :)
> 
:) The "secret"? I'm not (busy with) studying ATM...

Wolfgang

Post a reply to this message