Trabalho compartilhado

Como a fila decide quem roda primeiro

São 6 GPUs para muita gente. Quando há mais trabalho na fila do que o cluster consegue rodar, o fairshare ordena a fila para que ninguém monopolize as máquinas mas também não deixe ninguém fique esperando indefinidamente.

O essencial em 30 segundos

Fairshare só ordena a fila. Ele nunca cancela nem interrompe um job que já está rodando.
Quem usou menos do cluster nos últimos dias tem prioridade sobre quem usou mais.
Se o cluster está vazio, você pode usar tudo (dentro dos limites abaixo). Nada fica reservado e parado.
As métricas de uso “esfriam” com o tempo: uma semana pesada pesa menos depois de 7 dias e quase deixa de influenciar após um mês.

A fatia é do grupo do(a) orientador(a)

O cluster é dividido por orientador(a), não por pessoa. Cada grupo recebe a mesma fatia, não importa se tem 1 ou 10 alunos; os alunos dividem entre si a fatia do grupo. Orientador novo com mais alunos não ganha mais máquina, o que mantém a conta justa entre grupos de tamanhos diferentes.

Seu orientador é registrado no seu cadastro quando o acesso é criado. Se estiver errado, abra um chamado.

O que é incluído na métrica de uso

Recurso	Peso relativo
1 hora de CPU (core)	1
1 hora de GPU	32
Memória reservada	0,25 por GB-hora

O uso é contado pelo que você reservou, não pelo que usou de fato. Pedir 4 GPUs e usar 1 custa 128 por hora, não 32. Reserva esquecida (um salloc aberto) também custa.

Aluno externo de disciplina? Você tem uma cota fixa de horas-GPU, que usa esta mesma tabela de pesos. Veja Cota de horas-GPU.

Limites do dia a dia

Além da ordem na fila, há tetos para ninguém ocupar o cluster inteiro de uma vez:

QoS	Máx. por usuário	Tempo máx.	Para quê
`normal` (padrão)	96 CPU, 192 GB, 2 GPU, 50 jobs rodando	2 dias	trabalho comum
`long`	48 CPU, 96 GB, 1 GPU, 8 jobs	7 dias	execuções que realmente passam de 2 dias - peça liberação por chamado
`interactive`	8 CPU, 32 GB, 1 GPU, 2 jobs	4 h	depuração que precisa responder rápido

Sem --time seu job recebe 4 h na fila l40s. Peça memória e tempo realistas: pedido que nunca cabe é recusado na hora, com mensagem clara.

Como ser um bom vizinho

Peça só o que vai usar (GPUs, memória, tempo) - lembre-se que a prioridade cai para usuários que reservam mais.
Sempre use --time e feche sessões interativas quando terminar.
Divida um experimento enorme em vários jobs menores: entram em vagas livres mais cedo.
Teste na fila debug (sem GPU) antes de gastar GPU.
Prazo apertado (qualificação, submissão)? Abra um chamado com antecedência; a equipe pode ajudar a planejar.

Como ver sua posição

sshare -U -u $USER        # seu uso e seu fator de fairshare (0 a 1; maior = passa antes)
squeue                    # seus jobs; a coluna REASON diz por que um job espera
sprio -l -j <jobid>       # prioridade de um job pendente, fator por fator

Um fator perto de 0,5 significa que você usou exatamente a sua parte. Acima disso, você usou menos e tem vantagem; abaixo, usou mais e espera um pouco mais quando há disputa.

Prefere ver em gráfico? O painel do cluster (login com sua conta LABIC) tem a seção Fairshare: o fator de cada usuário agora e ao longo do tempo, e o direito (a fatia de cada um) e uso recente em gráficos separados.

Meu job está “pending” - será que é bug? Quase nunca. Priority = há alguém na frente; Resources = esperando vaga; QOSMax… = você bateu num teto da tabela acima. Dúvidas: suporte.labic.ct.utfpr.edu.br.