Время расчета задания зависит от числа разбиений, которые строятся в результате вычислительного эксперимента. Время также зависит от параметров генератора случайных алгоритмов, индивидуальных для каждого задания, и от архитектуры/тактовой частоты вашего процессора.

Допустим, задание называется wu_e4_n152_ss5000_x93-93_y2147483647-2147483647_w2147483647-2147483647_rs0_b.wu. Различные параметры влияют на время расчета по разному:

• от ограничений (Wmax, Xmax, Ymax) время почти не зависит;
• от N (средний размер алгоритма) время зависит нелинейно: t ~ O(N³) ... O(N⁵);
• от SS (Sample Size, размер выборки, фактически число разбиений) время зависит линейно;
• от метода (b — Baranov, p — PSM) время также зависит (Baranov быстрее как минимум в 1.5 раза);
• в зависимости от процессора время расчета может отличаться в несколько раз.

Время расчета задания можно расчитать лишь очень приблизительно, с точностью до нескольких раз, поэтому данная возможность не реализована. BOINC Manager определяет время расчета задания исходя из среднего времени расчета нескольких предыдущих, что также далеко не всегда оказывается точным.

Теоретически это реализуемо, однако на данный момент поддержки разделения заданий на короткие/длинные у проекта gerasim@home нет. Возможно она появится в будущем...

В настройках проекта gerasim@home на сайте в разделе Project prefs можно установить дневную квоту в размере от 1 до 2000 заданий (Workunits per host per day).

Код программы является в большей степени преобразовательным (большинство решаемых подзадач — различные задачи на графах), а не вычислительным, что не позволяет его реализацию на GPU.

Обсчитываемая часть является программной частью САПР'а (англ. CAD) для проектирования однородных многомодульных систем логического управления (СЛУ). Настоящие задания считаются для того, чтобы определить области применения методов построения разбиений (какой из них лучше себя проявляет в какой области). Так, например, по имеющимся на данный момент результатам можно судить, что параллельно-последовательный метод дает лучшее качество решений в области сильных ограничений, а метод С.И. Баранова — в области слабых. Данные результаты в целом подтверждают выводы, сделанные ранее, расширяя их область применимости на алгоритмы управления с большим числом вершин. Если метод дает более хорошее решение, то соответствующая СЛУ получается либо более быстродействующей, либо менее сложной (в смысле использования аппаратных затрат — дополнительных контроллеров, дорожек, глубин буферов) — разные сферы применения накладывают различные требования. Если СЛУ в базисе программируемых логических мультиконтроллеров (ПЛМК) доберутся до практического использования, то без указанного САПР'а и методов автоматического построения разбиений их будет достаточно сложно проектировать...
Кроме того, еще есть рядом стоящий класс задач по автоматическому распараллеливанию вычислений. Если в качестве исходных данных там выступает граф-схема алгоритма (правда алгоритма вычислительного, а не управляющего), то многие преобразования (н-р, преобразования R-выражений, работа с матрицей отношений) могут быть использованы без существенных переделок. Правильность доказательства их особых свойств и корректность выполняемых на их базе преобразований подтверждается программной реализацией, что вы можете наблюдать при расчете задания — разбиения успешно строятся во всех областях значений параметров.

Текущие расчеты будут проводиться еще как минимум полгода. Область исследования можно бесконечно продолжать в сторону увеличения N (сейчас N < 500-600). В перспективе можно исследовать влияние различных модификаций для известных методов и разрабатывать новые методы — в данный момент все ограничивается наличием свободного времени...

Одной из причин, приводящих к ошибке, может быть заражение машины вирусом (например, Virut или Sality). Во время попытки запуска зараженного расчетного .exe модуля BOINC Manager определяет несовпадение его сигнатуры с эталонной, в результате чего запуск завершается ошибкой. На сайте проекта подобные задания получают статус Invalid с сообщением об ошибке ERR_RESULT_DOWNLOAD.

Входной файл содержит набор значений входных параметров для расчета и его размер составляет менее 1 КБ. Выходной файл представляет собой выборку результатов разбиений и его размер определяется как SampleSize x 54 байта x CompressRatio, где CompressRatio — степень сжатия выходного файла, в худшем случае составляющая 0,5. В большинстве экспериментов SampleSize=5000, CompressRatio~0.5, значит размер выходного файла составляет ~132 КБ.
Месячный объем трафика в интернет определяется главным образом исходящим трафиком и зависит от множества факторов: времени расчета заданий (маленьких заданий считается больше за одно и то же время, поэтому трафик выше), производительности процессора (частота, архитектура, число ядер), наличия других проектов, занимающих процессор, наличия фоновой нагрузки на процессор и др. Общий трафик в месяц в некоторых случаях может достигать нескольких ГБ.

Нет, желательно прервать их выполнение вручную. Подобная ситуация возникает довольно редко и связана с некорректной приостановкой/возобновлением работы процесса на стыке вычислительного кода (separator.exe), wrapper'а и BOINC Manager'а. Теоретически подобная ситуация может возникать при расчете в случае попадания программы в бесконечный цикл, однако на практике подобных ситуаций не наблюдалось (вроде бы все подобные ошибки давно устранены). Если процент выполнения задания не изменяется на протяжении минуты, задание следует прервать... Однако не забывайте, что процент выполнения может перестать меняться из-за появления фоновой нагрузки на процессор (вычислительный поток работает с приоритетом простоя и поэтому практически перестает получать кванты процессорного времени при появлении более приоритетной задачи)