мои форки cgminer и bfgminer для bitfury ASIC

[Integ]

У меня выходит: -bash: --bitfury-clockbits=54: command not found

не выходит, потому что это не команда, а параметр цгмайнера.

[1714753944]

1714753944

[Grumlin]

в каком файле это проправить? хочу проверить что будет без вольтмода

libbitfury.c  libbitfury_sendHashData если в оригинальных форках.
По идее на хэшрейт особо не должно повлиять, если нет явной голодовки чипов.

Одна лишь простейшая правка, в области оценки решений от чипа:

Code:

        int dups = 0;
        if (op && o2p && d->job_switched)
          for (i = 0; i < 16; i++) {
            if (oldbuf[i] != newbuf[i] ) {

Дала интересный результат:
1. Хэшрейт моментально стал жестким на всю плату, 24.5 +- 0.2Гх. До этого все плавало, то к 22Гх, то к 26Гх.
2. Количество HW с десятков процентов (от 40%)  свалилось к 0.5% и продолжает убывать...
Проверка проводится на единичной плате Метабанка (8 чипов), с вольтмодом около 1.057В.

ок, только вот теперь не понимаю причем тут переменнная dups если вы её после даже не используете?)))
551 строка насколько я понял

ктонибудь объяснит зачем объясляем переменную dups?

[alpet]

ок, только вот теперь не понимаю причем тут переменнная dups если вы её после даже не используете?)))
551 строка насколько я понял

ктонибудь объяснит зачем объясляем переменную dups?

Да это из моего форка, счетчик дубликатов. Он уже не нужен стал, поскольку дубликатов не стало вообще )
Кстати, правка позволяет безболезненно поднимать частоту SPI. Сейчас я тестирую на 2МГц, показатели HW не изменились, а вот время опроса чипа сократилось с 3 до 2.5 мс. Соответственно можно ещё сильнее разгрузить CPU, или увеличить частоту опроса чипов (ротацию очереди в моем форке).

[bee7]

ок, только вот теперь не понимаю причем тут переменнная dups если вы её после даже не используете?)))
551 строка насколько я понял

ктонибудь объяснит зачем объясляем переменную dups?

Да это из моего форка, счетчик дубликатов. Он уже не нужен стал, поскольку дубликатов не стало вообще )
Кстати, правка позволяет безболезненно поднимать частоту SPI. Сейчас я тестирую на 2МГц, показатели HW не изменились, а вот время опроса чипа сократилось с 3 до 2.5 мс. Соответственно можно ещё сильнее разгрузить CPU, или увеличить частоту опроса чипов (ротацию очереди в моем форке).

Есть ли смысл ее поднимать? Я сейчас опрос произвожу раз в 250 милисекунд: производительность хешрейт тот же, что и если непрерывно опрашивать.

[alpet]

Есть ли смысл ее поднимать? Я сейчас опрос произвожу раз в 250 милисекунд: производительность хешрейт тот же, что и если непрерывно опрашивать.

Раз в 250 миллисекунд, опрашиваете 120 чипов? Что-то не вериться, что такое возможно... у меня такой опрос занимает от 360 мс (3 мс, на чип).
В моем форке цикл лимитирован по времени, т.е. перед выходом из функции scanHash опрашивается произвольное число чипов (сколько успеет за 500 мс), и размер цикла можно регулировать... В целом хорошо, если чип опрашивается 2-3 раза в секунду, но я заметил основное отличие bfgminer от cgminer - максимально частый опрос, и это заметно влияет на хэшрейт (что удивительно, ведь есть буферизация заданий).

[bee7]

Раз в 250 миллисекунд, опрашиваете 120 чипов? Что-то не вериться, что такое возможно... у меня такой опрос занимает от 360 мс (3 мс, на чип).
В моем форке цикл лимитирован по времени, т.е. перед выходом из функции scanHash опрашивается произвольное число чипов (сколько успеет за 500 мс), и размер цикла можно регулировать... В целом хорошо, если чип опрашивается 2-3 раза в секунду, но я заметил основное отличие bfgminer от cgminer - максимально частый опрос, и это заметно влияет на хэшрейт (что удивительно, ведь есть буферизация заданий).

Нет, 40. У мя 40 чипов всего.

[ptty]

Выложил. http://mirrors.linuxoid.in/misc/asic/metabank.asic.rpi.2013.09.26.01.img.xz
Проверьте кто-то на "чистовом" запуске - работу веб-морды, доступ по ssh и тому подобное. Вроде все работает, но мало ли.  Раскатать сейчас образ на чистую флешку, загрузить с нее ASIC и выполнить "обычные пользовательские действия по настройке" сейчас нет возможности.

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

Спасибо большое за образ. Большая просьба, в сл раз либо указывать что это и чем его распаковывать, либо выкладывать в более привычном формате. А то я как дурак лью на флешку и думаю а чего это оно не работает и почему файл такой маленький, не докачался чтоли... Не сказать чтобы я с линуксом на вы, но о существовании XZ не знал. Всякие bzip и gzip как-то более привычные или какой-нибудь 7z\rar

[willrain]

Не сказать чтобы я с линуксом на вы, но о существовании XZ не знал. Всякие bzip и gzip как-то более привычные или какой-нибудь 7z\rar

А при чем тут Linux? LZMA - популярный алгоритм. Упомянутый тобой 7z использует (использовал?) 1-ю версию, это - вторая.
https://ru.wikipedia.org/wiki/XZ

[ptty]

Не сказать чтобы я с линуксом на вы, но о существовании XZ не знал. Всякие bzip и gzip как-то более привычные или какой-нибудь 7z\rar

А при чем тут Linux? LZMA - популярный алгоритм. Упомянутый тобой 7z использует (использовал?) 1-ю версию, это - вторая.
https://ru.wikipedia.org/wiki/XZ

В винде в основном используется RAR и ZIP. Ну 7z еще немного. Не подумай что я претензии предъявляю, просто я ну скажем так близкий к различным компьютерным делам человек не знал такого. Ладно догадался по размеру файла что дело не ладное и пошел гуглить, а хомячки вообще голову всю сломают себе и потом тебе. Лучше добавить ссылку на софт чем это распаковывать.

[ptty]

-

[Integ]

Это только у меня каждая строка пишется в лог дважды? Модифицированная сборка willrain.

А вообще жаль, что bfgminer не пишет в лог long статистику.

[needbmw]

закоммитил вчера изменения в bfgminer, теперь (очень на это надеюсь) HW ошибки обрабатываются максимально правильно.
за ночь сдвоенное устройство показало 4.4%

[needbmw]

Это только у меня каждая строка пишется в лог дважды? Модифицированная сборка willrain.

А вообще жаль, что bfgminer не пишет в лог long статистику.

статистика же через API вся выдается, как раз именно для этого.
самый простой вариант - вызывать по крону раз в 5-10 минут
php /path/to/bfgminer/api-example.php stats >> /var/log/bgminer-api.log
если формат вывода не нравится, никто не мешает свой парсер написать или допилить php или python примеры.

[mall]

закоммитил вчера изменения в bfgminer, теперь (очень на это надеюсь) HW ошибки обрабатываются максимально правильно.
за ночь сдвоенное устройство показало 4.4%

образ от willrain возможно обновить?
если да..напишите список команд

[willrain]

Code:

cd ~/needbmw/bfgminer/
git pull
make clean
make

Можно сохранить это в отдельный файлик и потом вызывать

Code:

bash файлик

Это только у меня каждая строка пишется в лог дважды? Модифицированная сборка willrain.

Не замечал такого. У тебя случайно 2 процесса майнера не запущено? Хотя они передрались бы за чипы...

хомячки вообще голову всю сломают себе и потом тебе

Хомячки обычно ткнут кнопку "Выделить все" - http://freeinstall.ru/image/sistema/7zip2.jpg - что, правда, иногда приводит к казусам (начинают распаковывать архиватором ISO-образы перед записью и так далее) - и файлик у них будет с иконкой архива. С учетом того, что расширения у тех же хомячков обычно скрыты - то как-то и не важно, rar там будет, 7z или xz.

Не подумай что я претензии предъявляю

Да без проблем. Будем считать это троллингом тех, у кого

В винде в основном используется RAR

...бездумно спираченный на какой-то файлопомойке вместо поставленного с оффсайта 7z с тем же функционалом и с поддержкой всех современных форматов .

needbmw, может есть смысл поднять нижнюю границу рестарта чипов по хэшрейту? У себя обычно ставлю 150, т.е., 2 Гх

[alpet]

Вопросик остался незамеченным: если флаг job_switched выставился, то чип не пишет в текущий буфер результатов, от того которое начало выполняться? В том смысле, не возможно затирание результатов, если долго не опрашивали чип?
Или же буфер результатов начинает изменяться лишь после загрузки нового задания?

[bee7]

Раз в 250 миллисекунд, опрашиваете 120 чипов? Что-то не вериться, что такое возможно... у меня такой опрос занимает от 360 мс (3 мс, на чип).
В моем форке цикл лимитирован по времени, т.е. перед выходом из функции scanHash опрашивается произвольное число чипов (сколько успеет за 500 мс), и размер цикла можно регулировать... В целом хорошо, если чип опрашивается 2-3 раза в секунду, но я заметил основное отличие bfgminer от cgminer - максимально частый опрос, и это заметно влияет на хэшрейт (что удивительно, ведь есть буферизация заданий).

Я тут померил даже ради любопытства. Среднее время 1го скана 40 чипов вместе с отправкой nonce 13 милисекунд. 120 чипов было бы 36 милисекунд. а я скан запускаю раз в 250 милисекунд.

Эдит: пробовал и на частоте spi 4000000 и на 400000 - результат не меняется, я б даже сказал, вопреки ожиданиям на 400000 скан занимает 10мс

Эдит: статистика работы за 10 минут:

PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                        
 3505 root      20   0  130m 3984 2584 S      3.9      0.9        0:25.34 bfgminer                                                                                        

[bee7]

Вопросик остался незамеченным: если флаг job_switched выставился, то чип не пишет в текущий буфер результатов, от того которое начало выполняться? В том смысле, не возможно затирание результатов, если долго не опрашивали чип?
Или же буфер результатов начинает изменяться лишь после загрузки нового задания?

Буфер кольцевой. Чип затирает самые старые результаты.

[alpet]

Я тут померил даже ради любопытства. Среднее время 1го скана 40 чипов вместе с отправкой nonce 13 милисекунд. 120 чипов было бы 36 милисекунд. а я скан запускаю раз в 250 милисекунд.

Эдит: пробовал и на частоте spi 4000000 и на 400000 - результат не меняется, я б даже сказал, вопреки ожиданиям на 400000 скан занимает 10мс

Вот это очень любопытный результат, покажите код? У меня четкая реакция на увеличение частоты SPI - среднее время 10 опросов снижается. Использую для замера cgtime, можете посмотреть как вычисляется median_load здесь в строках 1177-1181.

[bee7]

Я тут померил даже ради любопытства. Среднее время 1го скана 40 чипов вместе с отправкой nonce 13 милисекунд. 120 чипов было бы 36 милисекунд. а я скан запускаю раз в 250 милисекунд.

Эдит: пробовал и на частоте spi 4000000 и на 400000 - результат не меняется, я б даже сказал, вопреки ожиданиям на 400000 скан занимает 10мс

Вот это очень любопытный результат, покажите код? У меня четкая реакция на увеличение частоты SPI - среднее время 10 опросов снижается. Использую для замера cgtime, можете посмотреть как вычисляется median_load здесь в строках 1177-1181.

Я с гитом не очень хорошо знаком, всю жизнь на cvs просидел. Если объясните, как "отвязать" то что у меня есть от needbmw и разместить на гитхабе (можно в личке) - покажу