Data Production BARS tag v0.1 on Desktops
Processed data are producing now for seasons 2016, 2017 by BARS tag v0.1 (raw, eventindex, impulse, joint, trigger steps). Three desktops are busy in processing: baikalsnr.jinr.ru (6 cores), angara (159.93.76.242: 3 of 4 cores), baikalcom.jinr.ru (6 cores).
Processed data location: Season 2016: baikal-fs.jinr.ru:/data3/baikal/processed_data/exp16_r01_i01_j01_t01/cluster0 Season 2017, Cluster 1: * Runs 1 - 240 at baikal-fs.jinr.ru:/data2/baikal/processed_data_2016/exp17_r01_i01_j01_t01/cluster0 * Runs 241 - 509 at baikalvm (local JINR address 10.93.221.196):/mnt/cephfs/exp17_r01_i01_j01_t01/cluster0 * Season 2017, Cluster 2: baikal-fs.jinr.ru:/data2/baikal/processed_data_2016/exp17_r01_i01_j01_t01/cluster1
Data production status (11.12.2017): Season 2016: runs 1-133 have been processed by raw, eventindex, joint steps and are being processed by trigger step (baikalsnr). Season 2017, Cluster 1: runs 1-3 have been processed by all steps. Runs 4-21 are being processed now (angara) * Season 2017, Cluster 2: (baikalcom)
Data production status: For Cluster 1 2016: http://baikalsnr.jinr.ru/viewdb/runprocessstatusCluster12016.php For Cluster 1 2017: http://baikalsnr.jinr.ru/viewdb/runprocessstatusCluster1.php * For Cluster 2 2017: http://baikalsnr.jinr.ru/viewdb/runprocessstatusCluster2.php
Benchmarks
Test sample was 5 first files of run 20 cluster 2 2017.
Laptop
- Laptop Core i7 4700HQ (3.4GHz), 12 Gb RAM, SSD, LAN speed to baikal-fs was 2.85 Mb/s, BARS commit 728572bc84c7b364c65dc1a1353ca74f7fd8f352
Two approaches were tested where raw and processed data are located: on baikal-fs:/data3 directory, that was mounted by sshfs, locally on SSD.
| ROOT macros | Time remote, sec | Time local, sec | remote/local | Time local / Total , % |
|---|---|---|---|---|
| readbzip_set.C | 812 | 656 | 1.24 | 9.8 |
| treeindex_set.C | 78 | 103 | 0.75 | 1.5 |
| writesorted.C | 1059 | 273 | 3.88 | 4.1 |
| extractedimpulse_set.C | 1209 | 660 | 1.83 | 9.8 |
| getjointtable.C | 506 | 65 | 7.78 | 1.0 |
| eventbuilder.C | 864 | 108 | 8.00 | 1.6 |
| localtrigger.C | 5091 | 4760 | 1.07 | 71.0 |
| globaltrigger.C | 183 | 62 | 2.95 | 0.9 |
| histtrigger.C | 87 | 20 | 4.35 | 0.3 |
| Total | 9889 | 6707 | 1.47 |
Run 20 cluster 2 2017 (23 hours, rate 43 Hz) has 44 files. Therefore it was processed in 6707 * 44/5 = 59021 sec = 16.4 hours if data are local.
Baikal Virtual Machine
Check different VM hardware:
| VM | # cores | Frequency, GHz | HT |
|---|---|---|---|
| 1 | 14 | 2.2 | NO |
| 2 | 14 | 2.0 | NO |
| 3 | 14 | 2.2 | YES |
Input data: - 15 runs (from 19 to 32), - first 5 files of each run
| ROOT macros | VM1, sec | VM2, sec (VM1/VM2) | VM3, sec (VM1/VM3, (VM2/VM3)) |
|---|---|---|---|
| readbzip_set.C | 1380 | 1007 (1.37) | 1054 (1.31, 0.96) |
| treeindex_set.C | 133 | 159 (0.83) | 133 (1.00, 1.20) |
| writesorted.C | 547 | 532 (1.03) | 503 (1.09, 1.06) |
| extractedimpulse_set.C | 919 | 906 (1.01) | 879 (1.05, 1.03) |
| getjointtable.C | 127 | 102 (1.25) | 92 (1.38, 1.11) |
| eventbuilder.C | 273 | 243 (1.12) | 223 (1.22, 1.09) |
| localtrigger.C | 5768 | 5696 (1.01) | 5631 (1.02, 1.01) |
| globaltrigger.C | 130 | 121 (1.07) | 111 (1.17, 1.09) |
| histtrigger.C | 42 | 37 (1.14) | 34 (1.24, 1.09) |
| Total | 9319 | 8803 (1.06) | 8660 (1.08, 1.02) |
Old Approach for Data Production
Now bash scripts + MySQL database manages data production.
Картинка обработки полная
Пример таблицы
Advanced Approach for Data Production
General requirements: В общем случае, на входе имеем список ранов для обработки. Закачиваем входные данные на локальный диск, храним обработанные данные на локальном диске, и, как только вся совокупность обработанных данных получена, переносим ее на удаленный файл-сервер. Локальный диск небольшого размера (150 Гб), поэтому требуется следить за тем, чтобы он не переполнился. * Выбрать последовательность ранов по приоритету (последний ран, калибровочные раны). * Стараться обработать наиболее приоритетные раны как можно раньше.
Старый подход:
Система Bash скриптов работает очень примитивно. Она обрабатывает всю совокупность ранов без приоритетов, выполняет первый шаг обработки для всех ранов и только после выполнения этого шага переходит к следующему. Поэтому, хотя бы один полностью обработанный ран появится в самом конце обработки. Это значит, что не удастся хранить данные локально.
Ввиду того, что расширять функционал bash скриптов непросто, строим новую систему на python скриптах.
Новый подход: Для того чтобы обработать ран как можно быстрее, требуется распараллелить его обработку.
