![]() |
Привіт Гість ( Вхід | Реєстрація )
![]() |
Некто |
![]() ![]()
Пост
#1
|
![]() кранчер з фермою ![]() ![]() ![]() ![]() ![]() ![]() ![]() Група: Trusted Members Повідомлень: 762 З нами з: 16-May 08 З: Київ Користувач №: 745 Стать: Чол Парк машин: Q6600 @ 2600 MHz ![]() |
В этой теме отписываемся о новых челленджах. Будущие челенджи. Итоги 2012 1 Ross* Sicituradastra. 9575.00 2 Lennart SM5YMT PrimeSearchTeam 9118.75 3 tng* Sicituradastra. 8363.75 4 nyabe Team 2ch 8161.75 5 Scott Brown Duke University 7931.00 6 ThrasherX-17 Keep The Fire Alive! 7847.25 7 peppert* Sicituradastra. 7355.00 8 288larsson Sicituradastra. 6772.25 9 Carat@precure@poverty Team 2ch 6632.25 10 tiss Ukraine 6207.25 ![]() Развернутая индивидуальная статистика 1 Sicituradastra. 5385.00 2 SETI.Germany 4966.50 3 Czech National Team 4759.00 4 Team 2ch 4747.00 5 PrimeSearchTeam 4421.25 6 Ukraine 4332.25 ![]() 7 Dutch Power Cows 4228.75 8 Aggie The Pew 4049.50 9 Keep The Fire Alive! 3756.00 10 TeAm AnandTech 3690.50 Развернутая командная статистика (Show/Hide) (Show/Hide) http://www.charleygielkens.nl/pg/index.php...r=2012&team=343 Це повідомлення відредагував tiss: Dec 30 2012, 17:49 |
![]() ![]() |
amdk8 |
![]()
Пост
#2
|
![]() кранчер-новачок ![]() ![]() ![]() Група: Trusted Members Повідомлень: 55 З нами з: 2-February 12 З: м. Липецьк Користувач №: 2 900 Стать: Чол Free-DC_CPID Парк машин: Загалом 32 ядра (в т.ч. Deneb, Thuban, Zen) під управлінням Арч Лінукс. ![]() |
В преддверии Winter Solstice Challenge поискал оптимальные настройки карт на чипе Tahiti в проекте GFN-21 под Linux.
Пока что получилось сократить время расчёта на Radeon 280x до 1. Арч Линукс, открытые драйверы amdgpu, opencl-amd 18.10 (скорее всего версия неважна). 2. Параметр ядра amdgpu.vm_fragment_size= 3.Частота видеопамяти 1500 МГц. Оптимальные тайминги памяти, в случае Hynix: (Show/Hide) 4. 2 потока на GPU. В app_config.xml: ...<app> <name>genefer</name> <max_concurrent>2</max_concurrent> <!-- заменить 2 на количество чипов GPU*2, спасибо eugeny за замечание --> <gpu_versions> <gpu_usage>0.5</gpu_usage> <cpu_usage>0.05</cpu_usage> </gpu_versions> </app>... 5. Этот пункт актуален на момент публикации поста, но через некоторое время (ориентировочно год) скорость OCL на Tahiti упадёт ниже уровня других алгоритмов. Подробнее в последнем абзаце поста. Всегда использовать быстрый алгоритм OCL. Для этого запускать задачи с параметром -x OCL. В app_config.xml: ...<app_version> <app_name>genefer</app_name> <plan_class>openclatiGFN21</plan_class> <cmdline>-x OCL</cmdline> </app_version>... Без этого параметра каждая задача тратит полминуты на выбор оптимального алгоритма, а при переразгоне и появлении ошибок переключается на другие алгоритмы, что увеличивает время расчёта. С этим параметром при появлении ошибок (прогресс выполнения остановится) задачу следует отменить вручную и снизить частоту GPU. 6. Запускать задачи с переменными среды, предотвращающими ошибку CL_OUT_OF_HOST_MEMORY. Для этого редактируем юнит systemctl edit --full boinc-client и добавляем: [Service] Environment=GPU_SINGLE_ALLOC_PERCENT=100 Environment=GPU_MAX_HEAP_SIZE=100 Environment=GPU_FORCE_64BIT_PTR=1 Environment=GPU_USE_SYNC_OBJECTS=1 Environment=GPU_MAX_ALLOC_PERCENT=100 ... 7. Андервольтинг. Частота ядра maxErr exceeded for 299652^2097152+1, 0.5000 > 0.4500 Errors occurred for all available transform implementations Waiting 10 minutes before attempting to continue from last checkpoint... В этом случае следует прервать выполнение задачи и понизить частоту или повысить напряжение. Затем запросить новую задачу. Так можно найти рабочие настройки. Если не ориентироваться на низкое тепловыделение, то можно добиться более быстрого расчёта. P.S. По мере накопления нового опыта вношу правки. 5. Если в процессе челленджа "b" выйдет за пределы возможности алгоритма OCL, то будет ОЙ Исходя из данных тех задач GFN21, которые я наблюдал, "b" последовательно и непрерывно увеличивается в ходе выдачи задач. По мере роста "b" последовательно увеличивается показатель ошибок "err". Если значение "err" не превышает 0.5, то задача успешно выполняется с правильным результатом (это не касается случая переразгона GPU). Единственным негативным эффектом увеличения "err" (при отсутствии переразгона GPU) является замедление выполнения задачи примерно на (err*100)%. Таким образом, момент выхода "за пределы возможности алгоритма OCL" легко прогнозируем, и уже задолго до этого момента OCL будет проигрывать в скорости другим алгоритмам. На момент Winter Solstice Challenge 2017 значение err для OCL выросло с ~0.07 до ~0.09, но оно не могло вырасти до уровней, близких к 0.5.-------------------- Обчислюю до Сяну від Дону.
(Show/Hide) ![]() |
![]() ![]() |
![]() |
Lo-Fi Версія | Поточний час: 3rd August 2025 - 20:36 |