Bitcoin Forum

Для всех заинтересованных в инструменте для исследования, предлагаю свою версию cgminer (https://github.com/alpet83/cgminer) и bfgminer (https://github.com/alpet83/bfgminer).
Пока ещё не самая производительная, скорее заточенная на сравнение чипов и сбор статистики по работе чипов в устройствах от Метабанка.
Сегодня наконец была исправлена основная утечка памяти. Настолько большой ради неё квест пришлось пройти, что я морально готов к маленьким донейтам )

Программа отражает краткосрочную статистику с гистограммой, если собирать по умолчанию:
http://savepic.org/4483063m.png (http://savepic.org/4483063.htm)

Подскажите, пожалуйста, как уже установленный cgminer обновить, а то я в линуксе на уровне чайника пока.

Надо выполнить следующую инструкцию, для моего случая:
Перевести на более понятный язык смогу позже, сейчас очень уж устал.

Извините, неправильно выразился. Вашу версию я уже установил по этой инструкции, как теперь ее правильно обновлять - заново все шаги делать (ну кроме создания папок, естественно) или есть другой способ?

cd /home/pi/test2
git pull
./build.sh

профит

Именно так. Но поскольку добавил файл memutils.c, нужно ещё раз выполнить autogen.sh с параметрами известными, перед build.

ошибка после запуска файла билд.сш

configure: error in '/home/pi/cgminer:
configure: error: C compiler cannot create executables

Вы в папке /home/pi/cgminer собираете? Там вроде оригинальные исходники от Легкодымова.

---

To all: Похоже стоит пока заблокировать автоподбор, закомментировав #define BITFURY_AUTOCLOCK в файле driver-config.h. Пока я другие моменты исправлял, он видимо сломался и стал неэффективным.

Исправил дамп гистограммы. Кстати сейчас по чипам ведется так-же индивидуальная статистика в папку /var/log/bitfury, аналогично с гистограммами.

сколько выдает с автоподбором через часов 5?

У меня больше 100 не вышло.

В ветке needbmv прочитал, что вам удалось найти течь в цгмайнере от легкодымова. посмотрел ваш форк, но понял что поиск займет слишком много времени из-за того, что вы зачекинили весь код с отладочным аллокатором. Не подскажете, где именно течет?

Спасибо

Нет, в тест2/сгмайнер
Я вообще его собираю не в сборке от метабанка. А в обычной от распри ос

Вызовы bin2hex в libbitfury.c, их надо закомментировать.

Добавил себе форк bfgminer (https://github.com/alpet83/bfgminer), теперь он работает с выводом статистики в консоль (скорость как у форка needbmw).
Рекомендуемый порядок сборки (первую строку ввести, чтобы работать под root):
Файлы angel.sh, mine.sh и mine_start.sh можно переместить в /usr/local/sbin
Исходники драйвера у меня теперь совместимы для компиляции под cgminer и bfgminer, при минимальных модификациях. Однако код от bfgminer в составе cgminer почему-то беспощадно тормозит, если работает более чем 1 плата.
Всем кто пытается оптимизировать этот драйвер, предлагаю объединиться для создания документации и описания различий разных версий. У меня пока получается лишь оптимизация вслепую, т.к. алгоритмы понятны очень поверхностно.

Обратите внимание на одну особенность: если хоть один чип не детектируется (кроме нулевого), программа выходит. При автоматическом перезапуске это помогает часто найти все чипы, но если проблема "аппаратного" рода и часть чипов невидна стабильно... майнинг не запуститься вообще.

после твоих апдейтов, у меня перестало видеть чип при запуске сгмайнера и бфгмайнера.
Bitfury slot:0x00, chip #1 not detected !!!!
Bitfury slot:0x00, chips  detected: 00
=1
For slot - detected only 1 vhips from 8

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

как сделать чтоб он чекал чип на слоте 0х01 ?

У меня сейчас на 5 устройствах нормально видит все чипы. Основное отличие от форка needbmw, это по умолчанию все заточено под устройтства Метабанка:
1. Задана частота 500000 в spidevc.c
2. Заданы соответствующие дефайны

Как я понимаю, все остальные майнеры у вас определяют 8 чипов для слота 0?

У меня один чип.

Тогда надо в bitfury-config.h закоментировать строку:
#define BITFURY_METABANK
Потом выполнить ./build.sh

У меня с таким дефайном программа ожидает не менее 8 чипов на каждый слот. Интересно, а на старой версии у вас работал мониторинг температуры и напряжения?

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

nano bitfury-config.h

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

Ковыряю 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

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

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

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

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

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

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

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

Я собственно из-за них и отключал.
Проверить с твоим оборудованием будет проще, у меня осцил доисторический ::)
На конце линии, как ни парадоксально, все работает без hw :-\

Проблема скорее всего в плохом согласовании линии и отражении сигнала. Почитал немного, есть как минимум два способа терминирования SPI линии, причем резисторы в конце - самый плохой. Советуют ставить в начале. Достаточно развернутое описание по этой теме. (http://electronics.stackexchange.com/questions/33372/spi-bus-termination-considerations) Нужно попробовать переделать согласование линии и посмотреть к чему это приведет.

Тут ещё и земляная петля в наличии, при том что земля на основной плате ещё и под мощным перегрузом (греется при вольтмоде).

Занимаюсь ещё одним явлением, более неприятным чем обилие HW: отваливание чипов. На одной платке стабильно отваливался один чип, и кажется удалось с этим справиться, вставив паузы 85 микросекунд, до и после вызова tm_i2c_set_oe(slot). Делаю промежуточный вывод, что микросхемы мультиплексоров на некоторых платах тормознутые, вот только как-бы задержку теперь подобрать поменьше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если данные портятся на пересылке оттуда - это не беда. следующее вычитывание должно (может) принести ранее испорченные данные правильными, а ранее правильные может испорченными. По сути это негативно влияет только на HW, так как в результате вычитав данные 3-4 раза за задание мы теоретически должны "поймать" правильно все нонсе (исходя из предположения, что внутри чипа всё что лежит в буфере - действительно не испорченные нонсе).

По сути я так и делаю. Если данные текущего буфера кардинально отличаются от предыдущего, просто пропускаю цикл (он сейчас менее 100мс), а в следующий раз они как правило приходят в норме.

Да смысла нет пропускать. Ну накручивает оно HW и что? Тем более, что это именно HW. Если на следующем вычитывании оно всё доберет - и славно!

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

Вот кстати дамп результатов (https://www.dropbox.com/s/olopsrg96q7zy1n/HW_dump.png), что сейчас выводится для чипов с слишком низким хэшрейтом. Подчеркнута строка где от чипа вернулась грязь вместо nonce, я подозреваю туда один лишний бит затесался (сдвинулись все двойные слова соответственно), либо наоборот выпал из-за помех на шине SPI. Теоретически можно сделать сдвиговый механизм восстановления нужных значений, но стоит-ли овчинка выделки (вероятность выпадения решения все равно мала)?  Так вот, заметно что подобных убитых строк многовато для чипов, которые дают маленький хэшрейт. Вполне вероятно что повреждаются и задания при отправке чипам. Нужно как-то отладить передачу данных, при подключенной второй плате: изменить номинал резисторов, убрать земляную петлю... нужны идеи )
Кстати у меня сейчас по наблюдением все ещё нет чипов, чей хэшрейт безнадежно до нуля угасает и их приходится передергивать. Впрочем, некоторые ещё в процессе падения форк умудряется перехватить.

В принципе, та же идея была в форке у Легкодымова сделана - если разница между соседними вычитываниями больше 4 слов, то он тут же перечитывал чип.

Меня очень интересует, что покажет мой форк на твоей железке. У меня с последнего перегруза она набрала 61 тысячу HW ошибок (3.6%) на 2.7 миллиона сгенерированных local work.

Вот сборка по умолчанию, слишком много жалоб на чипы: https://www.dropbox.com/s/og7mj35r5o4icey/miner-panic.png
Понизил её порог реакции до 130МГц, теперь лучше: https://www.dropbox.com/s/2xrcqc5n87huhc6/bee7_improved.png
Хэшрейт отличный, а вот пересчет ошибок очевидно большой. Моя самая последняя сборка считает меньше 15%, но на сопоставимый хэшрейт выходит медленно (возможно мешает обильный вывод статистики).

Нда. Видимо мне повезло с устройством. разогнал еще одну плату HW подросли, но суммарно всё еще 3.9%.
За тест спасибо.

У тебя это значение все-же ещё избыточно, одна и та-же ошибка наверняка много раз считается. Проверь на простом тесте, если при росте частоты опросов (для этого уменьшить задержку с 250 мс до 50 мс например), число HW будет так-же расти заметно, то это прирост ложных оценок. Сейчас уже понятно стало окончательно, что на устройствах с двумя мат. платами основной источник HW далеко не чипы, и соответственно их влияние на хэшрейт стремиться к нулю.

Да нет, меня 4% ошибок устраивают, если наши предположения об их источнике верны. А твой результат на моем форке (50%) явно за это говорит: шум в SPI привносит очень много ошибок. Тем более, что ошибки передачи - это тоже HW ошибки.

Едит: И, это, одна и та же ошибка у меня считается только 1 раз. Если при следующей передаче возникла ошибка в том же слове но другая - да она будет посчитана. но если ошибка в самом содержимом в буфере в чипе, то она будет учтена только 1 раз.

В последних ревизиях исправил проблему с ложной оценкой факта job_switched. На сейчас наблюдается средний хэшрейт 319 для строенного устройства и менее 2% HW. По показаниям пула хэшрейт ещё выше, видимо из-за учета Stale.

alpet
Подскажите, пожалуйста, как сделать, чтобы ваш bfgminer в статистике выводил еще и напряжение питания плат? У меня почему-то показывает все, кроме этого.

Надо раскоментировать в начале файла driver-bitfury.c строку:
Только проверьте хэшрейт с включенным и выключенным мониторингом, скорее всего он ухудшиться.

Как ни странно, хешрейт с мониторингом особо не ухудшился, даже параметр u: подрос немного, с 204 до 208 Гх/с на двойном метафурике.

Возможно на 10 платах будет нормально. У меня на 15 вроде как снижается. В любом случае, это число стоит оценивать на периоде час-два, оно от удачи вроде как плавает.

попробовал я ваш форк. В целом вроде немного быстрее чем форк от нидбмв. Но при этом есть небольшие непонятные глюки. В веб морде в разделе чип инфо почему-то сбрасываются счетчики ошибок на 0. Т.е. показатель errors почти всегда на 0%. Хотя сам майнер считает хардвары нормально.

Потом скорость у меня получилась 158-159 гх на 7 плат при 1,0В на чипах. Это нормально или мало?

1. У меня счетчик HW действительно обнулению подвергается. Чтобы выяснять частоту возникновения ошибок за период. Как-нибудь переделаю этот алгоритм.
2. Скорость надо смотреть среднюю за сутки на пуле. С таким вольтмодом 2.83 на чип вроде нормально, хотя нужно скорее смотреть прирост.

Скорость за сутки устаканилась в меньшую сторону  :( Теперь 157-158 показывает. На пуле за пол дня 158 стабильно держится.
До этого было 145-146, т.е. где-то 2,6 гх/чип. Я так понимаю до 3 гх с чипа конкретно этим платам не суждено дотянуть...

Температуру нормально измерить не получается, но палец держать на чипе терпимо. Так что по ощущениям 60-70 градусов. Охлад я максимум как можно улучшил, разве только радиаторы на чипы не лепил. Думаю как все остальные замоддю, то на балкон их вытащу и попробую 1,05 выставить.

Кстати как bits выставлять? Это где-то в сырцах править? У меня сейчас 54, а для 1.05 лучше 53?

1. Скорость усредняется медленно, плюс разные условия влияют (например холодный запуск).
2. Выставить можно через командную строку, т.к. я сливал свой код с форком от needbmw. Вроде как --biftury-clockbits="53," должно работать.

Сделал обновление с более-менее честным подсчетом аппаратного хэшрейта (скорости перебора нонсов) с вычетом плохих решений. Он более стабилен, чем расчет по шарам и акцептованным шарам, поскольку не зависит от удачи. Стало-быть можно тестировать будет скоро и автоподбор частоты осциллятора. Так-же теперь в короткой статистике честно указывается процент аппаратных ошибок, что позволяет улучшить вольтмод при тонкой подстройке.

сейчас я задаю стандартно клок 53 для всех чипов, а как активировать автоподстройку. чтобы например прога погоняла чипы под 53 и 54, и выбрала для каждого чипа самый лучший результат? или типо того

кстати. сделай вывод каждые 10 минут по рестартанутым чипам, чтобы видеть, 1_2 чип был рестартанут 3 раза, и 3_5 - 1 раз за все время работы майнера(это для удобности выставлять клок для чипов часто отваливающихся)

1. Надо раскомментировать в driver-config.h строку содержащую #define BITFURY_AUTOCLOCK. Правда в дефолтном релизе будет перебираться 53, 54, 55, 56, что довольно большой стресс для устройств с вольтмодом.
Если сделали вольтмод желательно так-же раскомментировать #define FAST_CLOCK1, тогда будет перебираться 51, 52, 53, 54. Перед полным автоподбором желательно удалить файл bitfury_opt.conf
2. Каждые 10 минут в консоль это излишне, я пожалуй лучше дополню в вывод логов по чипам это дело. Так можно будет обычным файловым поиском выяснить барахлящие чипы.

[edited]
Правки сделал, можно пробовать.

правки обновил, куда пишутся логи по чипам? и как сделать чтобы перебор ишел в диапазоне 53 и 54?

и что значит блок ниже?
#ifdef FAST_CLOCK1
        #define BASE_OSC_BITS 51
        #define LOW_HASHRATE 2.2
#else
        #define BASE_OSC_BITS 53
        #define LOW_HASHRATE 1.5
#endif

1. Логи по чипам пишуться в /var/log/bitfury. Каждый 16 дамп short stat примерно.
2. Перебор для двух значений я не проверял, но попробовать можно если заменить #define RANGE_MASK 3 на #define RANGE_MASK 1. При этом #define FAST_CLOCK1 нужно оставить закомментированным.
3. Блок с ветвлением означает выбор настроек для устройств с вольтмодом и стоковых.

т.е. для стоковых устройств по умолчанию выставляется 51 битклок? и сброс чипов при падении до 2,2?
соответственно нижняя для вольтмода? 53 и 1.5?

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

и что значит надпись #PERF: chip 3_1 work_time = 2.467 sec

у меня чип 3_1 так и сыплет этими надписями

а ещё при инициализации чипов начало выдавать вот так

 [2013-10-09 12:05:13.167] #PERF: no prefetched works.
 [2013-10-09 12:05:13.178]  for slot 1 chip 1, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.201]  for slot 1 chip 5, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.218]  for slot 2 chip 1, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.237]  for slot 2 chip 5, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.256]  for slot 3 chip 2, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.270]  for slot 3 chip 5, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.290]  for slot 4 chip 5, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.313]  for slot 0 chip 4, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.324]  for slot 0 chip 6, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.340]  for slot 1 chip 3, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.376]  for slot 2 chip 2, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.395]  for slot 2 chip 6, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.404] #PERF: no prefetched works.
 [2013-10-09 12:05:13.426]  for slot 3 chip 4, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.448]  for slot 4 chip 2, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.469]  for slot 4 chip 7, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.622] #PERF: no prefetched works.
 [2013-10-09 12:05:13.640]  for slot 1 chip 6, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.729]  for slot 3 chip 7, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.837] #PERF: no prefetched works.
 [2013-10-09 12:05:13.900]  for slot 2 chip 3, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.934]  for slot 4 chip 0, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:13.947]  for slot 4 chip 3, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:14.019]  for slot 4 chip 1, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:14.048]  for slot 0 chip 1, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:14.074] #PERF: no prefetched works.
 [2013-10-09 12:05:14.112]  for slot 3 chip 1, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }
 [2013-10-09 12:05:14.159]  for slot 0 chip 2, osc6_bits changed from 54 to 53, csw_count =   0, cch_stat = {  0  0  0  0 }

1. Не так. Для стоковых выставляется 54, для устройств с вольтмодом 53 (см. функцию init_devices). А базовое значение используется как минимальное в случае автоматического подбора.
2. Тест на каждом клоке длиться 16 дампов по 20 секунд. Сейчас шансы выбрать неправильный поменьше, но тем не менее остается заметное тепловое влияние предыдущих прогонов (что малозначительно при хорошем охладе).
3. Значит что чип довольно редко загружает задания, и соответственно должен малый хэшрейт иметь. Отчасти это время используется для сброса чипов, но по превышению 120 с.

ага, т.е. получается после того, как тест пройден например на 4 клоках, а это 20 сек * 16 * 4 =1280 секунд(чего так мало, это же 20 минут всего... или этого достаточно?)потом прога ставит жестко клоки для каждого чипа, а дальше она как нибудь отслеживает свой выбор? т.е. проверяет, насколько часто чип отваливается на выбранном ей клоке, насколько большой хешрейт у чипа и т.д.?

и ещё насколько я понимаю для того чтобы логи начались туда писаться, нужно раскоментить?
// print by chip stats in log files in /var/log/bitfury
// #define BITFURY_CHIP_STAT

и ещё, майнер сделает по 16 прогонов на каждом клоке и "успакоится"? или его нужно заставить как то успакоится и использовать полученные данные?

1. По идее с нынешней оценкой хэшрейта должно хватать, там только первый период усреднения требуется большой (32 дампа). Потом какое-то время идет выбор между лучшими, если хэшрейт спадает. По некоторым критериям отбор начинается заново.
2. Да
3. На самом деле на дефолтном хэшрейте он сделает больше прогонов, для лучшего усреднения после холодного старта. Переключаться начнет вроде как с 80 дампа. Когда определиться наилучший результат, должен успокоиться на время его удержания.

я просто про то имею ввиду, у вас слишком все автоматизировано, что это даже мешает. Как например запустить майнер, он там сделал все что ему нужно, первых 32 дампа прогрев, по 16 дамов на каждый прогон, итого 96 дампов. потом он например выключается и жестко запускается с этими клоками. Иначе он начинает переливать из одного в другое, что только мешает.

расскажите пожалуйста как формируется файл bitfury_opt.conf
slot_0=0:[0,0,0,0]@{0.00,0.00,2.97,2.90};

что значят цифры в квадратных скобках и фигурных

в фигурных насколько я понял по клокам 51 52 53 54 и средняя скорость ЗА ВЕСЬ ТЕСТ по ним?
потому как открываю один раз, вижу slot_0=0:[0,0,0,0]@{0.00,0.00,2.97,2.90};
открываю минут через 10, пока тест идет на данном клоке slot_0=0:[0,0,0,0]@{0.00,0.00,2.97,2.87};, получается здесь постоянно обновляется средняя скорость за тест?

Подключил одну плату напрямую к raspi для опытов, с ходу заметил следующие странности:
- без правок (сразу после git clone) bfgminer работает хуже чем старая редакция cgminer - через какое-то время, а иногда и почти сразу, отваливаются некоторые чипы и суммарный хэшрейт постепенно падает.
- изменение частоты spi ощутимо влияет на результат и меняет картину отваливающихся чипов, на более высоких частотах чаще имеют тенденцию отваливаться последние 4 чипа, при понижении в некоторых случаях сводится к одному. сопоставимая с cgminer картина была достигнута в диапазоне spi_clock =  62500 .. 125000
Есть мнение, что это как-то связано с отсутствием корректного согласования, попробую поставить резисторы разного номинала последовательно потом в качестве эксперимента.
Заставил в API работать как надо функцию set_clock_bits. Не понимаю, как оно работало раньше, но проблема была в начальной обработке входного param. Сделал аналогично функции addpool. Еще вынес внешние опции связанные с частотой SPI, автоподстройкой и логированием, чтобы не пересобирать каждый раз. В общем-то, изменения незначительные, но если нужно выложу.

1. По идее после нескольких раундов соревнования, накопиться статистика в файле о выборе наилучшей частоты. Соответственно после перезапуска уже не будет производится новое тестирование.
2. В квадратных скобках собственно единственные используемые параметры - содержимое массива cch_stat. В этом массиве находятся простые счетчики, сколько раз в результате соревнования была выбрана соответствующая частота. Если для какой-то частоты накопиться 3 и больше, то дальнейший автоподбор должен заблокироваться (он будет происходить в пределах одной частоты). В фигурных скобках исключительно информационная оценка хэшрейта.
 
invader
Выкладывайте, постараюсь внести правки.

Нашел баг отсутствие символа "=", не позволяющее устанавливать через --bitfury-clockbits значение для нулевого чипа
строчка в driver-bitfury.c

Сейчас еще пока редактирую исходники и тестирую, насчет выложить могу предложить 2 варианта.
1) выложить diff отредактированных файлов или вообще все целиком куда-нибудь.
2) сделать еще один форк форка в свой гит и залить изменения, но сразу предупрежу что с гитом общаюсь не на регулярной основе.

Спасибо, поправлю. Мне хватит и архива с измененными файлами, я найду какие строки изменились.

что это значит?
на разные чипы такое выскакивает почти каждый вывод
 [2013-10-09 16:36:45.900] #WARNING: Chip at 2 x 4 has low median hashrate, auto-clock reset
2 х 4???

update
разобрался, пришлось коды проштудировать, а лень как было))))

здесь кстати можно было бы добавить для какого клока такая фишка
applog(LOG_WARNING, "#WARNING: Chip at %x x %x has low median hashrate, auto-clock reset. clock=%x", dev->fasync, dev->slot, dev->osc6_bits);

applog(LOG_WARNING, "Slot %X chip %X, work_time = %.0f ms, FREQ CHANGE-RESTORE, osc6_bits = %d, chip recovers = %d, total recovers %d", dev->slot, dev->fasync, work_time * 0.001, dev->osc6_bits, dev->recovers, recovers);

и надо было уже к одному виду привести, а то в одном месте в одном формате выводит, в другом месте в другом.

кстати, если не убирать автоподборклока и указать в конфиге
"bitfury-clockbits": "53,0:4:54,0:5:54,2:4:54,3:3:54,4:1:54,4:3:54,4:5:54,4:6:54",

и удалю твой файл в руте
подбор клоков прекратится?

Нет. Будет начинать с твоих установок, первые десятки дампов только. Прекратиться он лишь при заполнении массива cch_stat фиксирующими значениями для чипа. Например [3,0,0,0] зафиксирует на 53 (или точнее на базовой частоте).
Думаю вот как улучшить автоподбор, чтобы избежать лишних тестов. Возможно надо оценивать прирост HW при каждом увеличении частоты - по критическому значению прекращать тест и прирост.

а как же случаи, когда хв возрастала пропорционально приросту хешрейта?

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

Обновил на репозитории, добавлены правки от invader, спасибо ему ) Плюс я добавил стабилизатор хэшрейта, который себя почему-то показывает лишь на устройствах без вольтмода. Уже часов 12 как работает одна ферма на 15 плат, стабильно на 319Гх и 1.6% HW.

сегодня ночью майнер 3 раза завершался аварийно с ошибкой которую увидел через screen -r
bash: line 1: 12106 Bus error               /home/pi/bfgmineralpet/bfgminer -c /home/pi/.cgminer/cgminer.conf --queue 200

кто знает что это?

Сейчас словил какой-то совершенно не понятный глюк  :o
Холодный рестарт и 20  из 96 чипов остались стоять. Потребовалось 4 раза рестартануть bfgminer, что бы все чипы начали работать.
Что это было ?  ???

У меня подобное бывает после нередких в последнее время отключений энергий (то здание вырубят, то УЗО сработает). Программа в течении некоторого времени лечит чипы, если они просто забастовкой занимаются. Но если ещё и детект осложняется, что нередко в случае вольтмода, приходится шаманить подолгу...

Как раз вольтмод значительно облегчает детект чипов.
У меня подобные проблемы были только на девайсах с 2 мамами, на одном вылечилось ликвидацией второй, на другом проблемы были во время манипуляций с длиной шлейфа, сейчас более-менее стабильно детектятся с шлейфом 25см. С необрезанным тоже бывало такое.

Вот такая запись в логе. Девайс сам перезагружается и продолжает работать.
Вопрос - а собственно зачем и почему ?

Скорее всего какой-то внешний скрипт воздействует. У меня под сутки аптайма, и то лишь потому что вчера переключал питание.
[edited]
Вот пруф стабильности (https://www.dropbox.com/s/r7rkoraqoyik5fo/Stable_319Gh.png), более 1.5 суток ферма выдает 319Гх. В данном случае real из-за флуктуации удачи показывает 316, но иногда бывает и 330. По версии пула ghash.io средняя за день скорость 319.8Гх. Вообще я сделал вывод такой, что программно из чипов более ничего выжать. Для ферм в которых больше 120 чипов конечно нужно реализовать опрос как у bee7 - с обменном данных для одного слота каждый раз. Но я пока не слышал что Метабанк такие производить собирается...

А где находится файл bitfury_opt.conf?

don_sergio
/.bfgminer/bitfury_opt.conf

не путайте людей, он находится тут
/root/.bfgminer/bitfury_opt.conf

Смотрим на заголовок окна.

http://i59.fastpic.ru/thumb/2013/1015/09/f6aad1f1ee7d86024e6becaede9c7a09.jpeg (http://fastpic.ru/view/59/2013/1015/f6aad1f1ee7d86024e6becaede9c7a09.png.html)

Я не смог... Там такие задницы вокруг... :D

http://i59.fastpic.ru/big/2013/1015/09/f6aad1f1ee7d86024e6becaede9c7a09.png
Достаточно крупно?

Брр. О каких задницах идет речь ?

Ну я нажал на картинку, что бы покрупнее было - меня перебросило на сайт, где она находится, на сайте вокруг картинки всякая реклама...

Я тоже не сразу понял.. пока не дошло!

Поставьте себе adblock

вообщем спи...ли мы оба, т.к.

Grumlin
Вот строчка из лога майнера

bee7
Оказывается еще встречаются люди у которых не стоит adblock  ::)

Я честно говоря не заморачиваюсь, т.е. оно конечно раздражает слегка, но иксплорером и виндовсом я пользуюсь только для доступа к кое-каким корпоративным приложениям (не работают иначе). А под линухами оно как-то всё безобиднее. Да и потом, если жопа красивая, почему бы на нее не посмотреть :D

так я не про то, что не туда пишется. а что оно пишется в зависимости от пользователя либо если скрипт отрабатывает не от пользователя то в корень

bee7
заранее прошу прощения за вопрос  ::)
посмотрел в гите на твой форк...ммм...а если вот твои файлы из конфига просто перекинуть в папку с собранным другим форком, заработает?
я примерно понял, что твои наработки в гите обозначены модификацией от 1-2 октября.
охота понять, можно ли выжать что-то еще не собирая очередной форк.

anatolikostis, Да не вопрос. Они собственно не мои, это я из бмвшного цгмайнера портанул, так как он почему-то не стал.

думаю, api.c можно просто скопировать. из driver_bitfury.c выдрать функцию, которую я туда поместил, что бы остальной код как можно меньше знал про внутренности этого драйвера для динамического выделения памяти под массив чипов и уменьшения зависимостей при компиляции.

Насчет выжать еще что-либо, не знаю, какие нибудь проценты-доли ппроцентов может и можно, но принципиально софтом на мой взгляд ничего не сделать. Т.е. качественно лучше чем существующие реализации не выйдет. Выход есть вроде бы, но он требует редизайна платы: нужно внешний клок подавать, тогда можно выжать из чипа около 4Gh, со слов одного америкоса (burnin, кажется). Но это сложно на такой частоте. А сейчас на эти эксперименты уже нет времени.

походу изза скачка напряжения часть чипов отвалилась с нулевым хешрейтом. перзапуск по питанию не помогает.
оданако рестарт майнера - раз 20 наверно, возвращает все в норму.
нельзя ли както детектить совсем отвалившиеся чипы и резетить именно их до полного изнеможения?

Уважаемый alpet!
Так как я ни разу не линуксоид, то снова прошу совета: как правильно обновлять ваш bfgminer под метабанковские устройства с github'а? После того, как вы написали о внесенных правках, я в каталоге с исходниками ввел команду "git pull", но она написала, что обновленных файлов не обнаружено. Тогда я удалил всю папку с исходниками и сделал заново "git clone https://github.com/alpet83/bfgminer", но скачалась та версия, которая не дает устанавливать клок для 0 чипа (это где в исходнике = пропущено). Хотя я читал в теме, что это исправлено. Подскажите, пожалуйста, что сделать для скачивания последней версии.

qdi
Тут конечно эксперименты нужны, чтобы научиться реанимировать нестабильные чипы. Как мне показалось, им надо несколько секунд давать отдыхать после shutdown сигнала. Во всяком случае с двух-трех принудительных рестартов bfgminer большая часть чипов начинает работать почему-то (надо в консоли завершать по Ctrl+C, и сразу-же заново пускать).

AtomicStrike
Я там сам немного запутался с бранчами, но последний обновлял вроде как metabank. Соответственно клонировать ветку должна команда "git clone -b metabank https://github.com/alpet83/bfgminer". Варианты есть и другие, но этот вроде самый лаконичный.

У меня, кстати, тоже чипы сразу не стартуют некоторые. Тоже несколько раз подряд запускаю bfgminer.

Спасибо за помощь с ветками, я тут с помощью яндекса нашел как обновить уже установленные исходники, чтобы не клонировать заново:

Снова вопрос!
bfgminer не показывает в короткой статистике (в длинной показывает) данные по 3-м чипам, клок которых через конфиг установлен в 52. В гистограмме вместо 80 чипов показывает 77. Суммарный хешрейт платы при этом показывает верно. fast_clock не задан, так как разогнанная плата пока всего одна. веб-морда метабанка эти 3 чипа видит нормально. Подскажите, пожалуйста, где в исходниках подправить настройки видимости чипов в статистике?
Вот скрин проблемы:
http://i59.fastpic.ru/thumb/2013/1021/75/176d38f251501db1f7e3f5985502cd75.jpeg (http://fastpic.ru/view/59/2013/1021/176d38f251501db1f7e3f5985502cd75.jpg.html)

UPD! Понял, что копать надо файл driver-bitfury.c, но моих знаний не хватает, чтобы найти ошибку...

alpet

А можно как-нибудь уменьшить количество выводимой статистики ?  Т.е. зарезать короткую статистику совсем и оставить только полную раз в 900 секунд

С этим вопросом я помогу. Нужно в файле "driver-config.h" поменять строчку
на
и пересобрать майнер

Подсчет делается строчкой 988: Но только для тех чипов, у которых клок вписывается в диапазон ridx 0..3

Спасибо за ответ! В принципе, я догадывался, что это связано с диапазоном в 4 клока, поэтому просто раскомментил сегодня FAST_CLOCK1, чтобы диапазон стал 51-54. У меня все равно сейчас чипов с клоком выше 54 нету. Теперь все нормально считается! Автоклок позже попробую, когда сделаю вольтмод всех плат.

Отвечаю сам себе чтобы поделиться наблюдениями.
Взял 2 резистора на 510 Ом (их у меня неприлично много и использую я их порой даже не по прямому назначению...), попробовал воткнуть их сначала от ног MISO и MOSI в землю - стало только хуже, чипы перестали определяться на частотах меньше 250000. Потом воткнул их в разрыв тех же линий - результат удивил, чипы перестали отваливаться и появилась такая-то стабильность. Частота 125000, на других не пробовал пока что. Уточню еще раз, что подключал одну метабанковскую плату напрямую к raspi, питание от обычного БП - 5v в распи и 12v на плату.

Уважаемый alpet, пожалуйста, помогите советом!
Что-то у меня опять непонятное происходит - автоклок не срабатывает и статистика по чипам в /var/log/bitfury не пишется, хотя все строчки раскомментировал. Завтра попробую всю папку удалить и заново склонировать, может заработает тогда.
UPD. Удалил папку с bfgminer, склонировал заново сразу с ветвью метабанк. Скомпилировал заново по инструкции с первой страницы, раскомментировав строки BITFURY_AUTOCLOCK, FAST_CLOCK1
 и BITFURY_CHIP_STAT. При запуске, bfgminer выставляет клок всем чипам 53, статистику в /var/log/bitfury не пишет, автоподбор клоков не начинает (прошло уже 220 дампов короткой статистики с последнего запуска).
Подскажите, пожалуйста, где проверить исходники?

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

А кстати, никто не пробовал "не непрерывные" битовые последовательности? Ну типа изобразить не "51бит", а "51 c половиной" ?

51,5 бит, это как 1,5 атома водорода что ли?

Спасибо, все получилось теперь! Просто нигде не увидел информации о командной строке... А частоты я потом все равно вручную буду править, просто хотелось, чтобы основную статистику автоклок собрал.

Ну типа если мы выбираем из ....11110000.... и ...11100000.... то промежуточным вариантом может быть ...11101000... А может и не быть промежуточным вариантом... В зависимости от того как реализована обработка этого регистра в чипе.

Не может. Бит это бит. Он неделим. 54 и 53 - может, а 53,5 - нет.

Бит конечно неделим. Просто если привыкли характеризовать значение этого регистра "в числе бит", то такая формулировка более-менее адекватна. Если бы этот регистр использовался  как начальное значение какого-то счетчика (или делитель), то это бы работало. Но так как при изменении 51-52-53-54 частота каждый раз не прыгает вдвое, то и реализация какая-то другая.

А с чего вы взяли, что частота должна прыгать вдвое?

Собрал bfgminer с автоматическим подбором битов (51-52-53-54). В результате получил суммарную скорость на ~7GH/s меньше, чем при фиксированных 53 битах. Возникает резонный вопрос о целесообразности автоматического подбора клока.

Аналогично думаю. Потенциально очень небольшое улучшение, т.к. немногие чипы на других частотах лучше выдают хэш-рейт. А вот из-за плохой статистической оценки, могут быть назначены и худшие частоты. Так что я свои устройства давно оставил в дефолте (53 для разогнанных).