CapordiaDefinire cosa deve proteggere il calendario
Inizia dalla decisione che non potrà più attendere: una revisione dei risultati, un trasferimento a un'altra squadra o la fine del periodo di locazione. Indica per ogni progetto la persona autorizzata ad accettarne il risultato. Una data di consegna non è semplicemente una data di fine del calcolo: la rilettura e il recupero dei file devono già trovarvi posto.
Distingui poi la disponibilità della macchina da quella delle persone. Un calcolo può talvolta avanzare di notte, ma la tua squadra può richiedere una presenza per un primo avvio o una validazione. Scrivi questo vincolo invece di contare tutte le ore del pacchetto come ore di lavoro intercambiabili. Il calendario è una convenzione interna da confermare, non un impegno di fornitura di Capordia.
Raccogliere una stima utilizzabile, con la sua origine
Per ogni lavoro, annota gli input previsti, l'orario in cui saranno realmente pronti, il numero di GPU simultanee, la memoria per GPU e le esigenze di trasferimento. Aggiungi una stima dell'occupazione della risorsa dall'inizio del caricamento fino al suo rilascio. Separa le attività di preparazione che si possono svolgere prima di questa occupazione: così eviti di riservare una GPU durante un'attesa amministrativa.
Indica se la stima deriva da una prova comparabile, da un'estrapolazione o da una semplice ipotesi. Una durata precedente è comparabile solo se i dati, le versioni, le impostazioni e le risorse utili sono sufficientemente simili. In assenza di un rilevamento, segna un intervallo da convalidare; non mostrare una precisione al minuto che suggerirebbe una misurazione. Riserva una piccola prova di qualificazione quando il suo esito cambia la scelta del calendario.
Passare dal volume totale alle fasce realizzabili
Somma le occupazioni previste per individuare un sovraccarico evidente, poi colloca ogni lavoro su una linea temporale. Un'elaborazione indivisibile di quattro ore non entra in due finestre di due ore, a meno che un'interruzione e una ripresa siano state convalidate. Due lavori che richiedono contemporaneamente lo stesso disco o la stessa persona possono ostacolarsi anche quando resta una GPU disponibile.
La documentazione di Slurm mostra perché il riempimento delle fasce dipende dalle durate e dalle risorse richieste: un'attività meno prioritaria può partire se non ritarda l'avvio previsto di un'attività prioritaria. Questa logica aiuta a leggere il tuo piano; non annuncia la presenza di Slurm in un'offerta Capordia. Qualsiasi utilizzo di uno schedulatore presuppone la sua configurazione reale e una politica decisa dal tuo team.
Esempio fittizio: tre progetti in due giornate
Il team fittizio «Bureau des tracés» dispone, per questo esercizio, di una sola GPU utilizzabile dalle 9 alle 17 durante due giornate, G1 e G2. Nessuna elaborazione condivide la GPU e ogni occupazione include caricamento, calcolo ed esportazione. Le durate seguenti sono ipotesi didattiche: non provengono né da una GPU del catalogo né da un benchmark. La preparazione comune occupa un'ora all'inizio di G1.
Atlas richiede quattro ore e deve essere consegnato prima di G2 alle 13. Balise richiede tre ore; i suoi input arrivano a G1 alle 11 e la consegna è prevista a G1 alle 18. Cadastre richiede cinque ore; diventa pronto a G2 alle 9 e deve essere consegnato prima delle 18. Il fabbisogno è pari a 4 + 3 + 5 = 12 ore. Con un'ora comune e tre ore lasciate libere, il piano utilizza le sedici ore aperte.
| Fascia | Occupazione prevista | Durata | Condizione |
|---|---|---|---|
| G1, 9–10 | Preparazione e controllo comuni | 1 h | Input e versioni disponibili |
| G1, 10–14 | Atlas | 4 h | Lavoro pronto alle 10 |
| G1, 14–17 | Balise | 3 h | Input ricevuti alle 11 |
| G2, 9–14 | Cadastre | 5 h | Input ricevuti alle 9 |
| G2, 14–17 | Riserva non assegnata | 3 h | Margine disponibile solo su G2 |
Collocare il margine prima del rischio che deve assorbire
Le tre ore libere rappresentano il 25% delle dodici ore di lavori. Questa percentuale, tuttavia, non basta a mettere al sicuro Balise: il suo margine si trova il giorno dopo la sua consegna. Se Atlas impiega cinque ore invece di quattro, Balise non può terminare prima delle 17 nella finestra consentita. Il piano regge sulla carta ma la sua prima giornata resta fragile. Questa lettura è più utile di un semplice tasso medio di riempimento.
Il team può allora spostare Atlas in parte o del tutto verso un'altra finestra solo se i suoi vincoli lo consentono, ottenere una finestra aggiuntiva o ridurre un perimetro accettato. Una seconda GPU è un'opzione da esaminare, non la conclusione automatica: deve essere disponibile, compatibile e accompagnata dalle risorse host necessarie. Senza una soluzione convalidata, il responsabile modifica l'impegno del progetto prima del lancio, invece di chiamare «margine» una riserva inutilizzabile.
Arbitrare un conflitto con una regola annunciata
Prepara l'arbitrato prima che due responsabili rivendichino lo stesso slot. Una regola semplice può dare priorità prima a una scadenza esterna confermata, poi a un lavoro i cui input sono pronti, poi all'anzianità della richiesta. Specifica chi può derogare a questa regola e quale team supporterà lo slittamento. Un'urgenza deve avere una conseguenza esplicita sul piano, e non diventare una nuova priorità permanente per chi la richiede.
Mantieni il calendario di riferimento e il motivo delle modifiche: input arrivato tardi, durata osservata più lunga o perimetro ampliato. La guida sulla coda dei lavori tratta la decisione del prossimo avvio; il calendario, invece, protegge le scadenze di più progetti. Il loro coordinamento permette di spiegare perché una scheda momentaneamente libera non è necessariamente disponibile per una lunga elaborazione aggiuntiva.
Verificare il piano e rivederlo con gli scostamenti giusti
Rileggi una giornata procedendo slot per slot. Ogni avvio deve avere i suoi input, i suoi accessi, la sua capacità di memoria e il suo responsabile disponibili. Controlla il trasferimento finale e il tempo di rilettura prima della consegna. Simula poi il ritardo più plausibile e verifica quale margine lo assorbe realmente. Se una sola deriva fa mancare una scadenza importante, presenta il piano come condizionale.
Dopo un'esecuzione reale, distingui l'attesa prima dell'avvio, l'occupazione della scheda e il tempo fino al risultato accettato. Correggi la prossima stima con questa scomposizione. Un ritardo di trasferimento non giustifica da solo una scheda più potente; una preparazione manuale dimenticata non si corregge aumentando il margine di calcolo. Il monitoraggio deve aiutare a eliminare la causa dello scostamento, non a cercare un responsabile a partire da un totale isolato.
Collegare il calendario al pacchetto senza confondere le unità
Una giornata di otto ore in questo esempio è una finestra organizzativa, non una tariffa di otto ore. Il catalogo Capordia propone periodi fissi di 3, 7 o 30 giorni e prezzi per lotto completo. Verifica separatamente la durata del noleggio, il numero di schede del lotto e il calendario di lavoro. Una scheda aggiuntiva non elimina né la preparazione né la validazione umana.
Il deliverable utile è un calendario approvato con le sue ipotesi, i suoi margini posizionati e le sue decisioni in caso di scostamento. Resta da confermare con le risorse effettivamente fornite e una prova rappresentativa. Non trasformare né le sedici ore dell'esercizio né la sua percentuale di riserva in un tempo garantito o in una regola universale di dimensionamento.
Domande per decidere
Posso dividere le ore previste per il numero di GPU?
Solo se i lavori possono procedere in parallelo e se le altre risorse lo consentono. Un'elaborazione indivisibile, una dipendenza o una fase di rilettura possono limitare il calendario. Fai emergere questi vincoli prima di convertire le ore totali in numero di schede.
Quale margine occorre riservare?
Il margine dipende dagli scostamenti plausibili e dalla loro posizione nel calendario. Le tre ore dell'esempio sono fittizie e non proteggono tutte le scadenze. Colloca una riserva prima della consegna che deve tutelare, poi giustificala con le tue osservazioni.
La pianificazione sostituisce il collaudo della macchina?
No. Presuppone risorse e un'applicazione utilizzabili. Il collaudo deve verificare questa ipotesi prima di considerare gli slot come sfruttabili. Se una condizione resta ignota, il calendario deve mantenere uno stato provvisorio e una decisione di ripiego.