Problem with uniformity of DB12 results
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 38/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- performance
Direzione di ricerca
Iniziare esaminando il calcolo referenziato nella descrizione dell’issue alla riga 66 di dirac_wms_cpu_normalization.py e l’uso di os.times() descritto nell’issue. Riprodurre l’istogramma dei valori DB12 con la simulazione Python fornita, quindi verificare che i valori di normalizzazione risultanti non presentino più lacune o concentrazioni dovute agli arrotondamenti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Recently I was analyzing the job execuiton and noticed quite a strange situation.
There are two problems with uniformity:
- In the area around 54 DB12. It looks like some DB12 results are impossible to get. Like 52.8, 53.7, 54.4, 55.0 and so on.
- In the area around 38 DB12. On the other hand, it looks like some values have considerably higher probability to appear.
So, I decided that the problem is with rounding and here what I got.
- When we calculate DB12, we are using
os.times(), but this function gives values rounded by 2 numbers after comma. Example: 4.58, 4.59, 4.6 and so on. - When DB12 benchmarks results are saved by dirac, they are also rounded by 1 number after comma (https://github.com/DIRACGrid/DIRAC/blob/c0afdba5ded29e72f1db144d71df3918313a28cb/src/DIRAC/WorkloadManagementSystem/scripts/dirac_wms_cpu_normalization.py#L66).
To simulate that I generated DB12 results which could be received from 50000 tests with test duration distributed uniformly:
df = pd.DataFrame({
'duration': [3.00 + x * 0.0001 for x in range(50000)],
'result': [round((250.0 / round(3.00 + x * 0.0001, 2)) / 1.0, 1) for x in range(50000)],
})
And draw a histogram counting different values of results (that is how CPUNormalizationFactor ius calculated for every job).
(Interactive plot with results: DB12_freq.html)
Obviously there is a problem with uniformity of the results. It is not only for high DB12 values, but also for lower one. It is just not so visible for low values of DB12.
- Lingua principale
- Python
- Stelle
- 5
- Fork
- 8
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di DIRACGrid/DB12
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Corrections for python 3.11Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 40/100
Tutte le issue di DIRACGrid/DB12
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
btclib-org/btclib-node#2132 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
freelawproject/juriscraper#2367 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
infra tech-debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
docs(k8s-api-proxy): name the service-account-token Secret path in the read-write mode commentApertaneeds-triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
gke-labs/kube-agents#4190 ·
I maintainer di solito rispondono entro 1 giorno