Topic: *gminers forks by alpet - page 5. (Read 8371 times)

Ситуация даже страннее, данные как правило портятся на пересылке "оттуда", и в основном однократно при опросе. Чтобы докопаться до сути, пришлось по совету Bitfury тупо дампить все решения, и смотреть на аномалии.
 Сделал фикс на это дело тяжелый, и теперь HW считаются совсем по другому (18% сейчас на стоковом). Хотя их преобладание на первых 8 платах очевидно, пока нельзя сделать вывод что они влияют на хэшрейт (если задания чипу не повреждаются). Предварительно думается у меня сейчас новый рекорд по производительности, но нужно проверить поведение забастовщиков.
Твой форк несколько позже смогу проверить.

Я думаю, что в случае когда приходит подряд много неправильных ответов одной серией, это означает, что порча случилась на передаче "туда", т.е. посчитал чип вовсе не то, что мы хотели. Но я у себя таких серий не вижу.

Кстати, я тут обновил свой форк еще раз. Попробуй его, если не сложно.

2.5-3% 3.9% (в среднем на все 40 чипов)

Еще, кстати, на 5ms сократил, смотрю что получилось

А сколько у тебя сейчас HW % ?

Странно. У меня правда только три платы в вольтмоде, и всего их 5. Отвал чипов конечно случается, но не часто. Не чаше чем раньше.

У меня без дополнительных задержек теперь тоже быстрый опрос, т.к. сделал переключение мультиплексора "по необходимости", но отваливание чипов чаще случается. Поэтому задержки оставил, и как видишь 208 мс на 120 чипов...

Я тут еще чуток почистил/пооптимизировал.

Снизил в 4 раза время опроса: на 4MHz 40 чипов опрашиваются 25ms вместо 100

свой форк обновил

Не помогает, как и задержки оказалось через более долгий тест. Зато выяснилось, что set_oe выполняется чертовски долго - несколько миллисекунд. Так что для отдельных плат возможно стоит единожды вызывать эту функцию...

[edited]
Ещё один ньюанс с засилием HW. Оказывается чаще всего ими оказывается заполнен весь буфер (ну или 13-14 из 16), что подразумевает затирание решений и вообще отбраковку задания. Тут есть вопрос, а не пропустит-ли таким образом устройство искомый nonce с блоком?
Как видно на картинке, страдают от ошибок более всего первые 8 плат к контроллеру (они у меня физически так-же установлены по индексам):

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

Проблема скорее всего в плохом согласовании линии и отражении сигнала. Почитал немного, есть как минимум два способа терминирования SPI линии, причем резисторы в конце - самый плохой. Советуют ставить в начале. Достаточно развернутое описание по этой теме. Нужно попробовать переделать согласование линии и посмотреть к чему это приведет.

Там не вторая плата виновата, а скорее всего резисторы терминаторы на ней. Они либо подобраны неправильно по номиналу (волновому сопротивлению линии не соответствуют), либо с ними ещё какая-то проблема. У меня сегодня была ситуация, когда кулером слегка их погнул, даже не допуская замыкания: так перестали чипы определяться сходу некоторые. Пока не догадался выпрямить, ничто другое не помогало (жаль не впаяли изначально SMD). Думаю надо будет проверить что с фронтами сигналов, особенно на конце линии. Отключать вторую плату на устройствах с 15-платами, это мягко говоря "не вариант" )

Есть мнение, что автоподбор неэффективен по причине накопления лишних hw_errors в слотах 0..7. Причина их возникновения кроется, вероятно, в реализации шины SPI - отключение второй платы помогает ( https://bitcointalksearch.org/topic/m.3267249 ). Нужно научиться их как-то фильтровать чтобы собирать реальные значения.

Сегодня было обновление bfgminer до версии что дает у меня наиболее высокую производительность: 315-320Гх для строенного устройства. Можно экспериментировать теперь с разными параметрами )

Если честно, у меня нет возможности тестировать альтернативные устройства, кроме как от Метабанка. Наверное этот форк только с ними и будет работать...

invader
Самая большая проблема этого подбора на сейчас, не сложность алгоритма отбора. Слишком маленькие периоды для тестов, при том что в них включается период "холодного хэширования".
Что-же до логики, попытаюсь описать насколько помню.
1. В массиве rbc_stat собираются четыре значения хэшрейта, за четыре раунда брутфорса. У каждого раунда выбирается соответственно своя частота осциллятора, в этом суть брутфорса.
2. Что касается csum, если было три соревнования, то наверняка определится две наилучших частоты, между которыми потом будет сравнение происходить. Для двух вариантов вроде как нет смысла делать четыре раунда.

[edited]
Сейчас несколько другая идея по оптимизации. Программа научилась собирать статистику по чипам в гистограммы, и записывать в отдельные файлы.
Так что вольтмодим, гоняем день на 54, день на 53 (сохраняем файлы отдельно). Потом из таблицы в консоли выбираем те чипы, у которых прям замечательные результаты на 54 и сверяем для них файлы. Несколько больше ручной работы, но надежность наверняка выше будет.
Чтобы файлы начали дампиться в /var/log/bitfury необходимо раскомментировать #define BITFURY_CHIP_STAT.
Кстати стоит сделать скрипт их архивации/бэкапа, поскольку в полночь они превращаются в тыквы затираются.

Ковыряю driver-bitfury.c, точнее пытаюсь в нем разобраться для начала. Так и не понял, что именно сломалось в текущей версии автоподбора, но уже возникает стойкое желание понять текущую реализацию алгоритма и переписать его, ибо функция freq_bruteforce() мне пока напоминает какую-то черную магию.

определяем переменную, вроде как гхэши
float best = 3; // extremum Ghz for 54 clk

следующей строчкой тут же присваиваем значение этих гхэшей из статистики объекта "чип" (dev) .. а предыдущая строчка зачем тогда, проинициализировать переменную? relative_bits_index() возвращает номера [0..3] считывая текущую частоту из dev?
best = dev->rbc_stat[ridx];

определяем еще одну переменную
int test_count = 4;

складываем количество "раз" выбора различных частот
for (i = 0; i < 4; i ++) csum += dev->cch_stat[ i ];

вот здесь уже начинается непонятно, почему 2 ...
    if ( csum > 2 )
         test_count = 2;

... или почему 4
if ( csum > 4 ) optimal = dev->cch_stat[ridx]; // probably best choice

И так далее. Изучаю. Конечно, код говорит сам за себя и его надо только осознать со временем, но если автора не сильно затруднит и он хотя бы попытается описать на словах алгоритм - дело пойдет несколько быстрее. Как уже говорил, как только разберусь боле-менее в коде, попробую переписать эту функцию и вынести некоторые параметры в виде опций.

закомментировал и открыл строку с // #define BITFURY_NEEDBMW_NOMUX 1
запустил билд.сш, запустил сгмайнер, идет очень долгий очень долгий поиск чипа и на 9 слоте он его находит.
Пока что ошибок очень много и скорость всего 400 мхешей

nano bitfury-config.h

так,это понял, а дефайны можно самому исправить, если да то где ?