RE: SV: [Gimle-users] Behov av job klasserpåGimle

Sat Feb 21 14:11:35 CET 2009

Instead of simply distributing the nodes according to how much each group pays, we could use NSC's old idea of "areas", that is the product of number and nodes and time requested. Each user can then decide to start a short job on many nodes, or a long job on a few nodes. This makes the system a little bit more flexible than just time or just #nodes, and would also allow users such as M to start their jobs now and then.

/Klaus

> -----Original Message-----
> From: Lindskog Magnus
> Sent: Saturday, February 21, 2009 10:38 AM
> To: Meier Markus
> Cc: Wyser Klaus; Undén Per; gimle-users at nsc.liu.se
> Subject: Re: SV: [Gimle-users] Behov av job klasserpåGimle
> 
> Hi all,
> 
> Keep in mind,
> Although a group pay a small fraction of the cost for gimle (like foua)
> the researchers of that group might need more nodes at the rare times
> they are using gimle.
> 
> In addition we have a couple of users from M-department that pay for
> gimle through yearly payments to FoU. They need approximately 2-4 nodes
> every now and then.
> 
> Regards,
> Magnus
> 
> 
> On Sat, 2009-02-21 at 01:33 +0100, Meier Markus wrote:
> > Dear all (this time in English for Robinson)
> >
> > many of you wish to have an updated queue sytem on Gimle to secure
> > both a fair assess and
> > optimal usage of the resource. OK let's try to find one. The problem
> > is that the needs of the different
> > groups differ substantially. For illustration 2 extremes:
> > 1) for FoUp it is important to have quick assess and many short
> > restarting jobs with a small number of nodes
> > 2) for FoUo it is important to have maybe just one job with many nodes
> > (say 31) continously running
> > That is what you have seen during the last weeks. As FoUo:s
> > application is very heavy (it takes
> > quite a long time even with a high number of nodes), we try to keep
> > basically one job running
> > all the time. In the development and analysis of this job about 5
> > people are involved.
> >
> > To quarantee the continous work for all of us I see only one solution
> > for a queue system. Each group will
> > get there own queue with  a maximum number of nodes according to the
> > cost share of Gimle:
> > FoUrc 13, FoUp 32, FoUo 32 , FoUl 6, FoUa 1
> > Every group can decide how to organize the work within their own queue
> > (either just one job with many
> > nodes or several smaller jobs but never more than the node limit
> > together).
> > In addition there should be a risk queue that all groups can
> > use together in addition to their "own" nodes.
> > That would allow to use empty nodes without blocking anybody. Maybe we
> > need a few rules also for the risk queue like maximum cpu (e.g. 3
> > hours) and a limited number of jobs per group (not per user).
> > However there should not be too many rules that it is still possible
> > to understand the queue system.
> >
> > Does this sounds fair?
> >
> > Best wishes
> > Markus
> >
> >
> >
> >
> > ______________________________________________________________________
> > Från: gimle-users-bounces at lists.nsc.liu.se genom Wyser Klaus
> > Skickat: to 2009-02-19 13:18
> > Till: Undén Per; gimle-users at nsc.liu.se
> > Ämne: RE: [Gimle-users] Behov av job klasser påGimle
> >
> >
> > Hej Per och alla andra---
> >
> > Ditt förslag med olika köer är värt att följa up, men jag skulle gärna
> > vilja se en riskkö utöver de som du förslår. Ditt förslag har nämligen
> > 2 nackdelar: 1) varje användare kan skicka jobb till alla köer och
> > helt enkelt fylla upp maskinen med olika jobb, och inget kan stoppa
> > dem. 2) En användare kan inte utföra fler än säg 2 normala jobb även
> > om maskinen står tom.
> >
> > Med en riskkö kan man lösa det smidigt, eftersom jobb som går på
> > riskkö stannar om nån annan behöver resursen. De startas igen (från
> > början) när det åter blir tid över för dem. Man kan skicka obegränsad
> > med riskjobb, och därmed utnyttja maskinen bättre när den inte används
> > för annat.
> >
> > Sist men inte minst: riskjobb är perfekt för att lägga upp långa
> > körningar över helgen eller semester där användare inte kan nås och
> > ombes ta bort sina långa tunga jobb.
> >
> > /Klaus
> >
> >
> > > -----Original Message-----
> > > From: gimle-users-bounces at lists.nsc.liu.se [mailto:gimle-users-
> > > bounces at lists.nsc.liu.se] On Behalf Of Per.Unden
> > > Sent: Thursday, February 19, 2009 12:30 PM
> > > To: gimle-users at nsc.liu.se
> > > Subject: [Gimle-users] Behov av job klasser påGimle
> > >
> > > Hej allihop,
> > > Jag skulle vilja se att det införs ett system med olika köer och
> > > begränsningar på Gimle för att det är ett återkommande problem för
> > våra
> > > användare och vad jag hört även på Rossby.
> > > Jag tror att vi får ta nackdelen av ett viss underutnyttjande mot
> > att
> > > våra forskare inte kan få igenom sina korta utvecklingsjobb eller
> > vänta
> > > orimligt länge för varje cykel i experimenten. Det leder till sämre
> > > produktivitet och otrivsel i allmänhet och arbetstiden är faktiskt
> > > dyrare än alla CPU tider tillsammans.
> > > Detaljerna får experter utforma och beror på vad som är praktiskt
> > > möjligt, men något som:
> > >
> > > Class  / priority
> > >
> > > Ultra-long    > 2 days   < 48 nodes    on special requests /
> > weekends ?
> > > Low prio     < 2 days   < 48 nodes     max 1 per user
> > > Normal      < 1 day    < 24 nodes    max 2 per user
> > > High        < 1 hour   < 48 nodes    max 1 per user
> > > Very short  < 10 mins  < 24 nodes    max 2 per user
> > >
> > > Detta är ett exempel och man bör arbeta ut vad gränserna bör vara
> > > utifrån användarerfarenhet.
> > >
> > > Mvh
> > > Per Unden
> > >
> > >
> > > _______________________________________________
> > > Gimle-users mailing list
> > > Gimle-users at lists.nsc.liu.se
> > > http://www.nsc.liu.se/mailman/listinfo/gimle-users
> >
> > _______________________________________________
> > Gimle-users mailing list
> > Gimle-users at lists.nsc.liu.se
> > http://www.nsc.liu.se/mailman/listinfo/gimle-users
> >
> >
> >
> >
> > _______________________________________________
> > Gimle-users mailing list
> > Gimle-users at nsc.liu.se
> > http://www.nsc.liu.se/mailman/listinfo/gimle-users