Новости проекта RakeSearch
Заканчивается расчёт сразу двух больших по объёму партий задач - с именами wu_e1072_* и wu_e1074_*. Несколько дней будут в наличии ещё задания вида wu_e43_*, а потом - недели три будем считать только wu_e1056_*.
Цитата: Шмяка от 01.01.2025, 16:29странно что хотябы в месяц раз не пересчитывается автоматом вообще для всех...
Идея неплохая. Можно ещё в 0 сбрасывать. 
А пока написал скриптик и обновил ручным запуском. Вид первой 20-ки поменялся весьма сильно!
RakeSearch на GRID'2025!
Эдуардом Ватутиным, в рамках доклада "Modification of the load balancing method in a desktop grid for solving problems of constructing Latin square spectra" прочитанном на 11-й конференции "Distributed Computing and Grid Technologies in Science and Education" (GRID'2025) в Дубне, были представлены новые результаты в деле исследования мира латинских квадратов, добытые в том числе и в проекте RakeSearch. Запись доклада - пока ожидаем, а вот слайды от презентации можно посмотреть уже сейчас - файл с ними прикреплён.
Около 2.5 месяцев в проекте считались очень длинные задания вида wu_e1074_* - на Ryzen 3900X на каждое уходило где-то от 3 до 5 суток. Несколько дней назад они досчитались и это было не зря!
Также, как вы могли заметить, некоторое время были только задания вида wu_e1056_*, но сейчас снова есть и более длинные (в среднем) - wu_e43_* и wu_e1072_*.
Чуток статистики и графиков! (Ну ведь все же любят графики?)
После завершения недавнего эксперимента с длинными заданиями вида wu_e1074_* (считавшимися до 5 и более дней), появилась возможность дополнить архив по заданиям, обработанным в проекте и, соответственно, статистические показатели.
Первые два графика - за всё время работы проекта. № 1 - процессорное время, подаренное проекту участниками, выраженное в днях CPU time за день. То есть, по сути, среднее число вычислительных потоков работавших на проект в течении суток. График № 2 - производительность в TFLOPS, вычисленная по следующему принципу: (Credit за сутки/22500) * 0.5, где 22500 - средняя выработка CPU Ryzen 3900X в проекте, а 0.5 - это его производительность в TFLOPS в Linpack-е, судя по статьям (на самом деле она чуток выше).
Поскольку во время самого первого эксперимента использовалось оптимизированное приложение, позволявшее зарабатывать больший credit в единицу времени, то при изучении левой части графика с TFLOPS с очень высокими показателями это надо учитывать. График с процессорным временем, как вы понимаете, такой погрешностью не страдает, чем и полезен.
Загруженные файлы:
Следующие два графика охватывают время с экспериментами Эдуарда Ватутина (на них нет поисков R9, R10 и Олега Заикина). Поскольку это по сути, новая инкарнация проекта со своими приложениями, этот промежуток времени имеет смысл рассматривать отдельно.
В учёт процессорного времени внесено важное изменение - для заданий вида wu_e* (т.е. как раз экспериментов Эдуарда) теперь учитывается не CPU time, а Elapsed time. Сделано это потому того, что из-за особенностей взаимодействия приложения с wrapper-ом (насколько я понимаю), для ряда задач CPU не учитывается полностью, а вот Elapsed time (равный ему в случае остальных заданий с погрешностью в секунды) - фактически затраченное время отображает хорошо.
Добавлю ещё, что если присмотреться внимательно на шкалу времени, то можно увидеть что на ней пропущены отдельные интервалы времени, когда проект был неактивен.
Итак, снова "Время CPU в днях за день (или количество потоков)" и TFLOPS-ы, но уже за время экспериментов Эдуарда:
Загруженные файлы:
Просто красивое число из статистики: счётчик workunit-ов в RakeSearch превысил 100 000 000. Но тут надо пару примечаний:
- В диапазоне этих номеров есть пропуски, связанные с неправильно созданными workunit-ами и, затем, сразу же удалёнными. Но таковых мало, может быть менее 0.1% или даже ещё меньше;
- В истории проекта, этот счётчик как минимум один раз сбрасывался и в эти 100 миллионов не входит 23 миллиона WU самого первого поиска - перестановочных квадратов среди ДЛК 9-го порядка. Так что полное количество workunit-ов, обработанных в проекте, на самом деле стремится где-то к 125 миллионам.
Но всё равно - число! >:D
Основные новости, связанные с проектом сейчас поступают от Эдуарда в ветке об исследовании Латинских квадратов, а здесь просто отмечу, что в проекте снова есть все три вида заданий, иногда ещё появляются и очень короткие - буквально на минуту-две и с очень маленьким сроком - в 30 .. 20 минут. Считаем!
Из жизни проекта. 2025.11.24.
В некоторых экспериментах бывают бывают партии из коротких заданий - около 1..2 минут на CPU уровня Ryzen 3900X. При этом общий объём вычислений в рамках партии - довольно большой - в сотни и тысячи заданий. Для пусть и небольшого проекта - это пустяк, а вот для домашнего компьютера - расчёты на сутки.
А поскольку в этих экспериментах ещё и следующая партия заданий зависит от предыдущей, то считать их надо бы побыстрее. В данный момент пришли к тому, что для таких самых коротких был задан срок в 20 минут. Как оказалось - очень вовремя, потому что новые партии заданий приходилось считать одну за другой. Если ранее циклов вида "посчитали - сделали новые - посчитали - ..." требовалось несколько штук, то в случае одного из недавних поисков их получилось несколько десятков. В один из дней (благо с Эдуардом были на связи) провели более десятка таких итераций.
Должен отметить, что задания считались действительно влёт. Столь малый срок приводил к тому, что задания получались, сразу же считались и отправлялись. Получались компьютерами в небольших количествах, но так как шли в расчёт сразу, то просроченных почти не было, а те, что таковыми становились (ну, выключил человек компьютер спустя 30 секунд после получения такого) - быстро пересчитывались.
На днях обсчитывали уже большую партию из таких задачек - более 100 000. И вот тут уже появились недовольные >:D . Кого-то пугает просто сама величина срока, кто-то считает, что RakeSearch бессовестным образом образом отпихивает другие беззащитные проекта от "кормушки" с CPU Time за счёт аг-г-р-р-р-ессивно-агрессивных сроков.
Попробовал объяснить людям, что если на компьютере более одного проекта, то в среднем, на больших интервалах, слопать больше положенного по приоритету - особо не получится - клиент BOINC просто не будет запрашивать задания у проекта, который исчерпал свою долю. Успокоило ли это недовольных или нет - не знаю, но сама ситуация - занятная. На дворе уже у кого 50, у кого 100 МБит/с, а у кого - уже и оптика, а вот привыкли к срокам в неделю-другую и пугаются.
P.S. Впрочем, сейчас вот считаем охапку из 5987 заданий длительностью до 20 часов. Почти 2/3 посчитали, пока никто не жалуется. В целом проект получается для весьма лихих кранчеров. >:D
Предыдущая охапка из 5987 длинных заданий благополучно посчиталась несколько дней назад, а сегодня отправили в расчёт следующую - уже из 9856 задачек. Первые результаты будут не ранее, чем через несколько часов, а пока по компьютерам разошлась примерно 1/4 от заданий, остальные пока в очереди.