 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all
We plan to release a "peer to peer" Povray using the Xtremweb
(http://xtremweb.net) global computing Platform.
So can think it as SETI@Home meets PovRay.
Idea is to use the idle time of computers to render scenes provided by
any one.
Xtremweb allows the distribution of applications and the computing of
tasks without to much effort, and there are clients available for Linux
and Windows.
Povray is for us a good test case for the platform.
So what do you think about the usefulness of such a project ?
Will some of you be agree to participate by providing computing
ressource and scenes to render?
Are there already similar projects (I've sent a mail to internet movie
project but didn't get any response)?
Do you see special difficulties relative to PovRay. We are not very
familiar with raytracing.
Thanks for the tips and the response.
Gilles
--
Gilles Equipe Architectures Paralleles Tel 33 01-69-15-42-25
FEDAK LRI bat 490 Fax 33 01-69-15-65-86
------ Universite Paris-Sud email: fed### [at] lri fr
F-91405 ORSAY Cedex http://www.lri.fr/~fedak
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Fedak" <fed### [at] lrifr> wrote in message
news:3AA8F99B.3697F6F9@lri.fr...
>
<SNIP>
This sound great!
What version are you going to run? Also, presumably you won't allow any
external files (image maps and hfs, etc.) or i/o access.
BTW, is everyone in France called Gilles? ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Fedak wrote:
>
> [...]
>
> So what do you think about the usefulness of such a project ?
> Will some of you be agree to participate by providing computing
> ressource and scenes to render?
> Are there already similar projects (I've sent a mail to internet movie
> project but didn't get any response)?
> Do you see special difficulties relative to PovRay. We are not very
> familiar with raytracing.
>
> Thanks for the tips and the response.
>
One problem is that many povray scenes that take long to render also use
quite a lot of memory. You must whve th whole scene on each computer
involved and therefore need a lot of memory or you have to split up the
rendering process itself which would result in a lot of network traffic.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Fedak" <fed### [at] lrifr> wrote in message
news:3AA8F99B.3697F6F9@lri.fr...
>
Sigh - as C.H. has pointed out, there are a few problems.
Suggestions:
Apart from excluding any files with i/o operations, you would probably want
to test-parse any files on the server and only distribute those files that
parsed within a fixed time limit. You might also want to exclude any files
over a certain file size.
You would need to exclude files with radiosity (or warn submitters that the
results will be unreliable).
Still, this could be very nice for some kinds of scenes, such as nice big
isosurfaces or photons.
If you get far enough, I'd be happy to donate some cycles - provided you can
ensure that file i/o is prevented (didn't the guy who runs the render farm
have problems with some bu%$er submitting a pov-virus?)
BTW when using $%£ for censorship, should one be consistent? For example,
should it be bu%%er or is bu$%er okay?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly wrote:
>
> "Gilles Fedak" <fed### [at] lrifr> wrote in message
> news:3AA8F99B.3697F6F9@lri.fr...
> >
>
> <SNIP>
>
> This sound great!
>
> What version are you going to run? Also, presumably you won't allow any
> external files (image maps and hfs, etc.) or i/o access.
Well, we can support several versions as I understand there are
currently two main versions of PovRay, PovRay 3.1 and Patched or
MegaovRay.
Concerning I/O, actually we work as this: if you want to submit a task
(of an application in general) you give a file which is the stdin file,
a zip file which is a compressed directory containing all the files
requested for the execution of the task, and the command line.
The worker (remote PC) unzips the dir, jumps into, execute the command
line, inject the stdin file. So you see that's it is quite simple and ad
hoc. Right now we don't support some kind of "throttle" mecanism for
limiting bandwith, or size of
the genrated files.
> BTW, is everyone in France called Gilles? ;)
No, we have Jacques Pierre Paul etc...
Gilles Equipe Architectures Paralleles Tel 33 01-69-15-42-25
FEDAK LRI bat 490 Fax 33 01-69-15-65-86
------ Universite Paris-Sud email: fed### [at] lrifr
XtremWeb F-91405 ORSAY Cedex http://www.lri.fr/~fedak
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
>
> Gilles Fedak wrote:
> >
>
> One problem is that many povray scenes that take long to render also use
> quite a lot of memory. You must whve th whole scene on each computer
> involved and therefore need a lot of memory or you have to split up the
> rendering process itself which would result in a lot of network traffic.
Well, our first thought was to support animation rather than big and
complex scene.
Idea is that animation for wich the calculation of each frame takes few
(up to 10) hours would certainly be
the best suited calculation. It is clear that over Internet, you cannot
think of a parallelisation
of PovRay a la PVM. So maybe, in a fisrt case, only some scene with
strict requirements would be authorize.
How much memory consumes PovRay ?
--
Gilles Equipe Architectures Paralleles Tel 33 01-69-15-42-25
FEDAK LRI bat 490 Fax 33 01-69-15-65-86
------ Universite Paris-Sud email: fed### [at] lrifr
XtremWeb F-91405 ORSAY Cedex http://www.lri.fr/~fedak
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly wrote:
>
> Suggestions:
> Apart from excluding any files with i/o operations, you would probably want
> to test-parse any files on the server and only distribute those files that
> parsed within a fixed time limit.
Exectly, this is our current work in progress :) I have contacted one of
the PovRay farm Render to get some of their scripts, if they have some.
But I didn't get any response. So what we are doing now it's first we
split an animation in calculation of frames and one task=one frame. So
we're looking for this kind of scripts, even now part are already done.
For the i/o point of view, we can easly restrict the size of the input
file to few Ko :)
> You might also want to exclude any files
> over a certain file size.
> You would need to exclude files with radiosity (or warn submitters that the
> results will be unreliable).
Ah, ok I don't know that problem. Why should we exclude radiosity.
> Still, this could be very nice for some kinds of scenes, such as nice big
> isosurfaces or photons.
>
> If you get far enough, I'd be happy to donate some cycles
Thank you very much :) I hope you will !
> - provided you can
> ensure that file i/o is prevented (didn't the guy who runs the render farm
> have problems with some bu%$er submitting a pov-virus?)
Gasp, do you mean some kind of buffer overrun in the parameterS? We
think about using
sndboxing technique like subterfugue
(http://subterfugue.sourceforge.net/). But right now it is not implented
but we can restrict the user able to submit task. You're right it is a
big issue.
> BTW when using $%£ for censorship, should one be consistent? For example,
> should it be bu%%er or is bu$%er okay?
--
Gilles Equipe Architectures Paralleles Tel 33 01-69-15-42-25
FEDAK LRI bat 490 Fax 33 01-69-15-65-86
------ Universite Paris-Sud email: fed### [at] lrifr
XtremWeb F-91405 ORSAY Cedex http://www.lri.fr/~fedak
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Fedak wrote:
>
> Well, our first thought was to support animation rather than big and
> complex scene.
Might have a look at:
http://sabix.etdv.ruhr-uni-bochum.de/RenderFarm/
> Idea is that animation for wich the calculation of each frame takes few
> (up to 10) hours would certainly be
> the best suited calculation. It is clear that over Internet, you cannot
> think of a parallelisation
> of PovRay a la PVM. So maybe, in a fisrt case, only some scene with
> strict requirements would be authorize.
>
> How much memory consumes PovRay ?
>
Povray itself nearly nothing, but when rendering, scenes can easily
require a lot.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 09 Mar 2001 19:47:45 +0100, Gilles Fedak wrote:
>> - provided you can
>> ensure that file i/o is prevented (didn't the guy who runs the render farm
>> have problems with some bu%$er submitting a pov-virus?)
>
>Gasp, do you mean some kind of buffer overrun in the parameterS? We
Nothing so difficult as a buffer overrun. He's talking about things like
#fopen, #fwrite, etc. and the pre/post frame shellouts.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Assuming you had a sufficient number of users running the client, I would
like to see this split single frames into different rendering jobs, then
stitch the image back together when it was done.
For example, I have a set of four machines (450, 500, 702, 822MHz), and I
have one scene which takes these machines three solid days to render, and
I've only done a low quality image so far: 640x480, no animation, no AA,
povwin set to highest priority (there's a lot of glass involved). That's
about 280 hours, about 30 minutes per line. With 480 clients out there on
the net, I could have my image in a half hour instead of 3 days...
I don't recommend this in place of animation rendering, but rather in
addition to it. In fact, it would be just as beneficial to animation tasks.
Elsewhere this conversation had turned to hacking, and you should pretty
much assume this will instantly fall under attack as soon as it is publicly
available. The world is full of deviants, and it looks like a lot of them
own computers now. As was already mentioned, file IO would be an issue, but
worse than that, you will see people purposely return false results. The
SETI project had a terrible time with that. Imagine, you send off your
wonderfully detailed Louvre script, and you get back an image of Miss
November. (Ok, maybe it wouldn't be completely bad, but...)
As far as I can tell, there wouldn't be a way to really detect a
false-results hack, unless the system maybe randomly submitted test renders
to clients (with a known one-row return image) to see who wasn't behaving
and killed their account if they sent back gibberish.
Also, denial attacks will be common -- particularly in the case of something
like POV, it wouldn't take much effort to submit a bunch of files that would
effectively prevent anybody from ever getting anything else processed. The
script I mentioned earlier takes about two hours to render as just a 160x100
thumbnail and lengthy rendering times definitely wasn't my goal...
Actually, to bring this commentary full-circle, I bet farming out rendering
as single-line tasks would do much to alleviate the false-results problem.
It simply wouldn't be much "fun" for a hacker to just mess up one row in a
1200-line image, and the script owner could perhaps re-submit a single line
for re-rendering.
--j.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"Gilles Fedak" <fed### [at] lrifr> wrote in message
news:3AA91F44.CF4CF8F6@lri.fr...
> Tom Melly wrote:
> > What version are you going to run? Also, presumably you won't
> > allow any external files (image maps and hfs, etc.) or i/o
> > access.
> Well, we can support several versions as I understand there are
> currently two main versions of PovRay, PovRay 3.1 and Patched or
> MegaovRay.
At least three versions of MegaPOV.. :-) Things like particle
systems, cloth simulation, procedural texturing, aren't there yet..
> Concerning I/O, actually we work as this: if you want to submit a
> task (of an application in general) you give a file which is the
> stdin file, a zip file which is a compressed directory containing
> all the files requested for the execution of the task, and the
> command line.
The issue here is that Povray in and of itself allows you to
directly open files, execute command, etc..
> The worker (remote PC) unzips the dir, jumps into, execute the
> command line, inject the stdin file. So you see that's it is quite
> simple and ad hoc. Right now we don't support some kind of
> "throttle" mecanism for limiting bandwith, or size of
> the genrated files.
But thats the kicker.. I can then have a script that opens any
file, and can read and write from/to it. I could make a .rhosts
entry.. :-(
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBOqk1bE93h3x1fgJJEQLDrwCg5684QC55mgMyAZlxMQBFtxpFgnwAn1Eq
Uu/AnXhDpxS+w1Qo+spA+Bl5
=A2kd
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I appreciate your considering POV, but I wouldn't use this. It's way too
dangerous, and would take too much of my resources.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Fedak wrote:
>
> For the i/o point of view, we can easly restrict the size of the input
> file to few Ko :)
>
Restricting the size of the input file is not enough, because even a tiny input
file can easily generate a massive scene if it uses iterative elements such as
loops and recursive macros. Disallowing such elements is probably not an option,
because many people rely on them quite heavily.
As far as I can see, running a parse test on the server is the only reliable way
of evaluating a submitted scene. The test sould check that both parse time and
(more importantly IMO) memory usage are within acceptable limits. Of course with
animations, a test parse must be performed for every frame, because different
clock values can execute different branches in the script. All this may or may
not put too much stress on the server...
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" wrote:
>
> I appreciate your considering POV, but I wouldn't use this. It's way too
> dangerous, and would take too much of my resources.
On the point of the ressources, you should keep in mind that the machine
is used only when there are no interactive activity (screensaver) or
when the CPU is idle ( an activity under a low treshold ).
--
Gilles Equipe Architectures Paralleles Tel 33 01-69-15-42-25
FEDAK LRI bat 490 Fax 33 01-69-15-65-86
------ Universite Paris-Sud email: fed### [at] lrifr
XtremWeb F-91405 ORSAY Cedex http://www.lri.fr/~fedak
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> With 480 clients out there on
> the net, I could have my image in a half hour instead of 3 days...
That's the point.
> The world is full of deviants, and it looks like a lot of them
> own computers now.
C'est la vie :)
> Also, denial attacks will be common -- particularly in the case of something
> like POV, it wouldn't take much effort to submit a bunch of files that would
> effectively prevent anybody from ever getting anything else processed. The
> script I mentioned earlier takes about two hours to render as just a 160x100
> thumbnail and lengthy rendering times definitely wasn't my goal...
Yes, an idea was to calculate few pixels, that could serve both as
predicting the rendering time of the scene, and as certificate for
correctness of the computations.
BTW I have one question about the way you distribute the rendering on
your different PCs. How does the distribution handles the various
frequency of the processors. I mean how the load is distributed to the
processors, statically or dynimically ?
--
Gilles Equipe Architectures Paralleles Tel 33 01-69-15-42-25
FEDAK LRI bat 490 Fax 33 01-69-15-65-86
------ Universite Paris-Sud email: fed### [at] lrifr
XtremWeb F-91405 ORSAY Cedex http://www.lri.fr/~fedak
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> But thats the kicker.. I can then have a script that opens any
> file, and can read and write from/to it. I could make a .rhosts
> entry.. :-(
I mean that you don't have access to files outside of a temporary
directory.
--
Gilles Equipe Architectures Paralleles Tel 33 01-69-15-42-25
FEDAK LRI bat 490 Fax 33 01-69-15-65-86
------ Universite Paris-Sud email: fed### [at] lrifr
XtremWeb F-91405 ORSAY Cedex http://www.lri.fr/~fedak
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Fedak wrote:
> Idea is to use the idle time of computers to render scenes provided by
> any one.
> Xtremweb allows the distribution of applications and the computing of
> tasks without to much effort, and there are clients available for Linux
> and Windows.
> Povray is for us a good test case for the platform.
> So what do you think about the usefulness of such a project ?
While I've no doubt about Povray being a good test case for this, the main
problem is about the usefulness of it for end users - a least for those who
create stills. Scenes that render slowly (let's say below 10 pps - roughly
an overnight render at 800*600) and that could benefit from it are often
(but not always) ones that also use large amounts of memory and disc space,
which would make their distribution uneasy. While there's usually no formal
relationship between render speed and memory/storage space requirements,
there's a practical one which is the price to pay for scene complexity :
several reflective/refractive objects in a scene involving high-quality
radiosity will make the scene crawl and the memory use rise.
Typically, people who have to meet deadlines for certain raytracing
competitions would be in cases like this ;-)
G.
--
**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Fedak" <fed### [at] lrifr> wrote in message
news:3AAA1D58.311A36C5@lri.fr...
> > With 480 clients out there on
> > the net, I could have my image in a half hour instead of 3 days...
> That's the point.
I didn't gather from your original explanation that you intended to break up
the render, it sounded more like you were talking about farming out
animation frame rendering. But if we agree, hey, great!
> Yes, an idea was to calculate few pixels, that could serve both as
> predicting the rendering time of the scene, and as certificate for
> correctness of the computations.
I see two problems with that plan as a test of fitness. First, if they can
figure out where you do the test renders, they can *easily* make that area
render quickly -- maybe even if you use multiple areas (for example, by
carefully placing bounding boxes). The second problem is the converse -- I
think it would be easy to make the small-area test-render take a very, very
long time. For example, layers of transparency, lots of lights, fog, high
max trace level, etc. Then I slam a few of those into your server and the
test-renders shut it down.
And trust me, I hate being the devil's advocate on this. I would love to
have distributed rendering...
> BTW I have one question about the way you distribute the rendering on
> your different PCs. How does the distribution handles the various
> frequency of the processors. I mean how the load is distributed to the
> processors, statically or dynimically ?
My distribution method is a little something I call "doing it by hand". :)
There isn't anything automated about how I do it now (unfortunately), other
than copying files around on the network and using remote control software
to kick off rendering on the other machines. I am toying with a couple ideas
but I haven't actually written any code yet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2001-03-10 03:06, Margus Ramst <mar### [at] peakeduee> wrote:
>Gilles Fedak wrote:
>>
>> For the i/o point of view, we can easly restrict the size of the input
>> file to few Ko :)
>>
>
>Restricting the size of the input file is not enough, because even
>a tiny input file can easily generate a massive scene if it uses
>iterative elements such as loops and recursive macros. Disallowing such
>elements is probably not an option, because many people rely on them
>quite heavily.
You would have to put restrictions on the process. Most Unixes offer
quite a few "resource limits" which you can set. For distributed povray
the most important are IMHO:
RLIMIT_CPU
(limits the total CPU usage for one job)
RLIMIT_DATA, RLIMIT_STACK, RLIMIT_CORE
(limits the memory usage of a single process not all unixes have all
of these)
RLIMIT_NPROC
(limits the number of processes per user)
RLIMIT_NOFILE
(limits the number of open files per process)
Together with quotas, a chrooted environment and a positive nice factor,
the povray process(es) would be restricted from disturbing their host
computer.
What is sorely missing in standard Unix is a way to restrict network
connections: There are some approaches to that problem, but nothing
wide-spread yet (I'm guessing that a capability-based system will win
out, though). As long as a locally installed version of povray is run,
this isn't a problem, though, since povray doesn't talk across the net.
>As far as I can see, running a parse test on the server is the only
>reliable way of evaluating a submitted scene. The test sould check that
>both parse time and (more importantly IMO) memory usage are within
>acceptable limits. Of course with animations, a test parse must be
>performed for every frame, because different clock values can execute
>different branches in the script.
You can leave this to the slave servers: They can check whether there is
some output produces within a given time. If there isn't, they'll kill
the process and report failure.
hp
--
_ | Peter J. Holzer | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR | which is our implementation of Linux.
| | | hjp### [at] wsracat |
__/ | http://www.hjp.at/ | -- Scott McNealy, Dec. 2000
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2001-03-09 15:41, Gilles Fedak <fed### [at] lrifr> wrote:
>We plan to release a "peer to peer" Povray using the Xtremweb
>(http://xtremweb.net) global computing Platform.
I have downloaded the program, but I couldn't find much information on
how it works, and - most importantly - no source code on the site.
I don't like to run servers on my machines unless I have a clear idea of
what they do - of course some are just too large to audit completely
even if the source code is available, but the small size of the .jar and
.so make this entirely feasible.
hp
--
_ | Peter J. Holzer | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR | which is our implementation of Linux.
| | | hjp### [at] wsracat |
__/ | http://www.hjp.at/ | -- Scott McNealy, Dec. 2000
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" <tra### [at] inapginrafr> wrote in message
> While I've no doubt about Povray being a good test case for this, the main
> problem is about the usefulness of it for end users - a least for those
who
> create stills. Scenes that render slowly (let's say below 10 pps - roughly
> an overnight render at 800*600) and that could benefit from it are often
> (but not always) ones that also use large amounts of memory and disc
space,
> which would make their distribution uneasy.
For scenes that are reasonable in terms of memory use, images, etc,
non-radiosity -- eliminating all the major issues - then the next thing to
have to develop a user interest would be to let the end users view the
renderings that their machines are computing.
This way when you return to your computer you can see something partially
rendered and link back to a centrally controlled website that has stats on
all the parts of the scene, the author, originating IP of the job, and so
on.
In this way a community could be built up primarily using this network for
final-output of high resolution images or some such.. or test renders at
high res that will be completed relatively quickly
In fact don't even link back to a website, but just have a little status
window available that shows the information, and perhaps a link back to that
users home page and email address if they choose to provide it :)
The user can optionally provide access to his 'rendering' directory so that
others can view the completed images, or past renderings. In this way you're
relatively detached from the web and there is no central repository as such
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Peter J. Holzer" wrote:
> I have downloaded the program, but I couldn't find much information on
> how it works, and - most importantly - no source code on the site.
You're right. I will put an access to the source code throught CVS this
week.
You'll see that it's quit simple to get in the code.
Keep in mind that it is still under development.
Gilles Equipe Architectures Paralleles Tel 33 01-69-15-42-25
FEDAK LRI bat 490 Fax 33 01-69-15-65-86
------ Universite Paris-Sud email: fed### [at] lrifr
XtremWeb F-91405 ORSAY Cedex http://www.lri.fr/~fedak
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Peter J. Holzer" wrote
> RLIMIT_CPU
> (limits the total CPU usage for one job)
>
> RLIMIT_DATA, RLIMIT_STACK, RLIMIT_CORE
> (limits the memory usage of a single process not all unixes have all
> of these)
>
> RLIMIT_NPROC
> (limits the number of processes per user)
>
> RLIMIT_NOFILE
> (limits the number of open files per process)
>
> Together with quotas, a chrooted environment and a positive nice factor,
> the povray process(es) would be restricted from disturbing their host
> computer.
An other approach we are concidering is to confine the execution in a
sandbox.
Last week we have played with user-mode-linux.
(http://www.user-mode-linux.sourceforge.net)
Idea is to boot a virtual os only to run the application (povray). So
even if Povray is compromised, the user
is still in the sandbox and don't have access to the hosting machine.
Some preliminary test show that this solution
is quite easy to use. More, it has cool features such as defining the
amount of memory (physical and swap)
the process may use, the amount of disk and so on... So it is a very
appealing solution.
But we are still checking security and performance issues.
We are also comparing it to other solution also PTRACE oriented like
Janus or subterfugue (http://subterfugue.sourceforge.net)
> You can leave this to the slave servers: They can check whether there is
> some output produces within a given time. If there isn't, they'll kill
> the process and report failure.
>
Yes, it's the only way, unless that the server could be constantly
overloaded.
--
Gilles Equipe Architectures Paralleles Tel 33 01-69-15-42-25
FEDAK LRI bat 490 Fax 33 01-69-15-65-86
------ Universite Paris-Sud email: fed### [at] lrifr
XtremWeb F-91405 ORSAY Cedex http://www.lri.fr/~fedak
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
