[Swift-devel] VDS1 transfer executable

[Mihael Hategan]

On Tue, 2007-07-24 at 15:11 +0000, Ben Clifford wrote:
> On Tue, 24 Jul 2007, Mihael Hategan wrote:
> 
> > It's I/O bound stuff, so the CPU is likely not to be the problem. And 
> > generally the eth card would be fatter than the pipe outside.
> 
> In the case where eg. dCache is 'inside' rather than 'outside', that's 
> different.

Then it wouldn't be going through eth, I'm guessing. They invented lo.
And if it's not lo, then you'd still have a single eth (the source).
Doing single eth to single eth will probably be not much different from
single eth to multiple eths. There's the other possibility where the
source is multi-headed. But we should probably not optimize for 1% of
the scenarios.

> 
> > The local storage on the other hand may be a problem. It's tricky 
> > however. Should a bunch of executables need the same input file, it 
> > would likely be better to transfer it only once on the head node than 
> > multiple times on each worker node.
> 
> Its got to be transferred to the worker nodes anyway (at least as much of 
> it as is read/written) - in the present case using whatever shared posix 
> fs the site-wide scratch space lives on.

Yes and no. Some of the data may be transferred, as needed. Also, there
may be high performance shared FSes, which may beat our puny attempts at
better performance.

> 
> How the two different approaches stack up is probably going to depend on 
> the site layout and its relation to wherever submit-side data lives 
> (which, as I said, may be on-site); and on the app. So I don't think 
> there's one right way to do it.

Yep. But one of the choices is an engineering no no for us. If we can
make the other sufficiently good, we can provide a reasonable solution
at a low cost.

(Note to Ian: we're not implementing anything yet) 

>