Re: [BLASTTALK] buds and being nice

From: Tancredi Botto (tancredi@lns.mit.edu)
Date: Fri Sep 10 2004 - 10:36:10 EDT


Hi chi,
surely you can just use bud20-24. Although on the list for crunching the
are very rarely used (indeed 16 spuds are enough most of times) and you
can just leave them there. If it makes feel safer, than go ahead and switch
them off.

-- tancredi
________________________________________________________________________________
Tancredi Botto, phone: +1-617-253-9204 mobile: +1-978-490-4124
research scientist MIT/Bates, 21 Manning Av Middleton MA, 01949
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Thu, 9 Sep 2004, Chi Zhang wrote:

>
> Hi,
>
> I just came across one of the message in elog mentioning that on Sept 2nd,
> there was a lrd process on bud20 slowing down online crunching.
>
> I could not remember exactly if that was my process but I have been quite
> good at submitting my jobs to pretty much all the buds. Most of the time,
> I nice my jobs on bud01-13 and bud20-24 but sometimes I forgot, sometimes
> I choose to be greedy a little bit.
>
> My apologize if I came into the way of online crunching.
>
> However, may I also propose that bud20-24 be used only as backup CPUs for
> online crunching, that they be only used when cruncher has died for a long
> period of time and we have serious backlog. In this case shift crew can
> change the 0's to 1's in spuds_list.txt and they be changed back to 0 as
> soon as all the runs in the waiting list are sent to the CPUs. My
> impression is the 16 spud nodes are well sufficient for normal data rate.
>
> I would like to be able to use bud20-24 with not too low priority, since I
> frequently need to recrunch whole month worth of data for my calibration
> program. though I have modified my program to reduce the CPU demand by a
> LOT, there is still a not insignificant crunching time. BTW, I think it is
> well worth it as I started to see improved momentum resolutions.
>
> Thanks.
>
> Chi
>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST