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

[Magnus.Lindskog]

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