[Swift-devel] fakecnari on ranger without gridftp

[Ian Foster]

Ben:

I like the idea of being able to sleep faster. That could help a lot  
sometimes :)

Zhao and others have been working a lot on BG/P, as you probably know.  
The challenges inherent in file transfers there are in some ways  
comparable. Their solution has been to develop collective I/O  
operations that (a) multicast replicated input files more efficiently  
than multiple independent reads, and (b) apply two-stage methods to  
bundled inputs and outputs, moving them from local disks to the global  
file system via an intermediate file system. I wonder whether similar  
methods could be applied here?

Independently of that, it would be useful to develop a performance  
model for the whole end-to-end system to determine where the  
bottlenecks are, and the peak performance that could be expected for  
each stage (including data movement) so we can see where there are  
opportunities for improvement, and where we are limited by fundamental  
limits.

Ian.


On Sep 28, 2008, at 12:14 PM, Ben Clifford wrote:

>
> I have an app 'fakecnari' that behaves somewhat like the CNARI app  
> that
> skenny has been working on, in order to make it easier for me to  
> look at
> bottlenecks.
>
> So far, that's had similar problems to skenny's real runs where input
> files cannot be staged in to ranger fast enough from UC - this  
> limits the
> number of cores that can be used at any one time on Ranger to around  
> 15.
>
> So I thought in order to see what other bottlenecks might be found,  
> I'd
> make a run with swift running directly on a ranger headnode,  
> submitting
> through coasters and with the input and output files moved around  
> using
> the local copy file provider (the same as happens when you use the  
> default
> local site).
>
> This looks like it manages to use over 100 cores quite a lot. The  
> speedup
> for the run is (including allocation time for coaster workers, which  
> is
> a significant part of this run) about 50000s worth of sleep done in  
> 800s,
> which is sleeping 62 times as fast as on a single core. Discounting
> worker allocation time, this takes about 590s which is sleeping  
> about 84
> times as fast.
>
> Even with local copies instead of ftp, file transfers (limited to 4 at
> once) appear to be a rate limiting factor.
>
> There are full plots here:
>
> http://www.ci.uchicago.edu/~benc/tmp/report-fakecnari-20080928-1134-herl17vf/
>
> -- 
>
> _______________________________________________
> Swift-devel mailing list
> Swift-devel at ci.uchicago.edu
> http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel