[Swift-devel] Re: Question of wrapper.sh

[Ben Clifford]

The user guide has a section on properties that you can configure - in 
here, 
http://www.ci.uchicago.edu/swift/guides/userguide.php#engineconfiguration 
pretty much anything with the word 'throttle' in it.

If you give me the .log files for runs, I can look at what the rate 
control stuff is doing.

In the past day or so, I've reduced throttle.score.job.factor 
substantially, to be more appropriate for GRAM2 submission - I suspect for 
something like Falkon you should make it much higher. It used to be 4 
(which means 402 jobs executing at once maximum), but is now 0.2 (20 jobs 
at once maximum). For Falkon on a large number of CPUs, you probably want 
to make that higher (maybe number of CPUs divided by about 30)

On Mon, 10 Mar 2008, Ioan Raicu wrote:

> I am a little bit behind here on the emails... based on the Falkon logs, it
> seems that the low throughput we are getting in the latest Swift runs is due
> to throttling.  Where are all the various throttling parameters that we should
> change, to ensure that Swift submits to Falkon as fast as possible with all
> available jobs?  I assume there is a jobs/sec throttle, a maximum number of
> outstanding jobs (i.e. falkon queued jobs + running jobs), and maybe others.
> Thanks,
> Ioan
> 
> Zhao Zhang wrote:
> > well, the tar ball I sent in the last email is from 256 cores, are they from
> > the same cpu? By the way, I tried to find the .log files, but there isn't
> > any in the folder where I started the swift script.
> > 
> > zhao
> > 
> > Ioan Raicu wrote:
> > > Ben,
> > > Those logs are only for 1 CPU, so most things will take less than 1 sec.
> > > In the case where we use 100s of CPUs (a basic scenario for the BG/P),
> > > things will take 10s of seconds, so 1 sec resolution should be OK.  Zhao,
> > > did you re-run that test with 256 CPUs?  Ben should be looking at those
> > > logs, not the 1 CPU case.
> > > 
> > > Ioan
> > > 
> > > Ben Clifford wrote:
> > > > Whichever version of date that you used, it doesn't support more than 1s
> > > > accuracy in its output. That's irksome because its that subsecond
> > > > accuracy that I wanted from these log files.
> > > > 
> > > > date on os x doesn't have that precision, fairly recent (in the past
> > > > couple of years at least) GNU coreutils date does. It would be nice if
> > > > you could find if that is installed and use that instead...
> > > >   
> > > 
> > 
> 
>