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

[needbmw]

Кто может прояснить суть strange решений или HW ошибок, более-менее развернуто? Мне интересно, как в целом эта ситуация алгоритмически обрабатывается: чипу дается второй шанс на выполнение задания, или задание вообще вылетает?

а вот хобот её знает.
я переделал подсчет HW ошибок (теперь считает всё), и их реально очень много, почти 80%.
вопрос почему.

[1715113582]

1715113582

[1715113582]

1715113582

[HappyS]

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

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

Респект тебе. Залил на флешку - зашел на веб морду вбил пул и заебись. Никакой ебли.

Спасибо.

А как запускать то, автостарт есть?

да вообще вроде ничего не надо кроме как пул настроить.

[alpet]

а вот хобот её знает.
я переделал подсчет HW ошибок (теперь считает всё), и их реально очень много, почти 80%.
вопрос почему.

Обновишь на github?
У меня пока подозрение падает, что число таких решений зависит от частоты опроса чипов. Если она слишком чрезмерная, то счет или сбивается, или ещё что-то происходит.
Например, в своем форке я добавил между опросом каждого чипа паузу в 500 мкс, и HW упало с 50% к 34% примерно.
Сейчас порядка 5Гх выигрываю на устройстве с вольтмодом, только из-за более частого внеочередного опроса "хороших" чипов.

Думаю из-за HW просто не получается все опросы за 480 мс своевременно провести, поэтому готовых чипов (у которых job_switched != 0) к моменту опроса довольно большое количество.  А с таким флагом надо думать, если чип ждет ещё сколько-то мс, он может и второе задание решить - запросто опять переключит буфера. Так что гипотеза сейчас такая, свести время опроса каждого чипа к оптимуму, чтобы успевать и не торопить одновременно )

[Integ]

Залил еще на один майнер сборку от willrain и провел пару экспериментов.

В этом майнере чип 8_4 вечно болтался около 0.5Гх или вообще выпадал. Так он и повел себя с bfg.
Я стал наблюдать и вот оно долгожданное - chip 8:4 reinit to 54...
Дальше самое интересное - чип заработал как подорванный, 2.7Гх стабильно и ни одного hw больше уже полчаса как.

Собственно эксперимент - на другом аппарате с 11 платами, который сыпал 60% и выше hw на первых слотах, я стал последовательно вынимать платки второго ряда. С каждой вынутой % HW уменьшался, но не напротив убранных, что могло бы говорить о перегреве, а "в целом по больнице". Когда осталось 8 плат первого ряда, статистика позеленела.
Также в этом майнере есть "веселый" чип 9_3, который также быстро скатился на 0.2Гх и был переинициализирован. Дальше стабильная работа на 2.8Гх, правда, в отличие от 8_4, редкие HW проскакивают. Перед реинитом их было больше 90%, сейчас около 10%.

А теперь ложка дегтя - хотя форк bfg от needbmw и не течет, хешрейт за сутки просаживается где-то 0.7-1Гх на плату. Перезапуск решает проблему.

Мораль - автоподнималку надо настроить хотя бы на 2Гх. Я бы настроил вообще на 2.4.

[needbmw]

а вот хобот её знает.
я переделал подсчет HW ошибок (теперь считает всё), и их реально очень много, почти 80%.
вопрос почему.

Обновишь на github?

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

[Grumlin]

Залил еще на один майнер сборку от willrain и провел пару экспериментов.

В этом майнере чип 8_4 вечно болтался около 0.5Гх или вообще выпадал. Так он и повел себя с bfg.
Я стал наблюдать и вот оно долгожданное - chip 8:4 reinit to 54...
Дальше самое интересное - чип заработал как подорванный, 2.7Гх стабильно и ни одного hw больше уже полчаса как.

Собственно эксперимент - на другом аппарате с 11 платами, который сыпал 60% и выше hw на первых слотах, я стал последовательно вынимать платки второго ряда. С каждой вынутой % HW уменьшался, но не напротив убранных, что могло бы говорить о перегреве, а "в целом по больнице". Когда осталось 8 плат первого ряда, статистика позеленела.
Также в этом майнере есть "веселый" чип 9_3, который также быстро скатился на 0.2Гх и был переинициализирован. Дальше стабильная работа на 2.8Гх, правда, в отличие от 8_4, редкие HW проскакивают. Перед реинитом их было больше 90%, сейчас около 10%.

А теперь ложка дегтя - хотя форк bfg от needbmw и не течет, хешрейт за сутки просаживается где-то 0.7-1Гх на плату. Перезапуск решает проблему.

Мораль - автоподнималку надо настроить хотя бы на 2Гх. Я бы настроил вообще на 2.4.

вот, меняй наздоровье, как изменить исходники, сделай make, и всё

зы. я себе сделал 110, посчитал 1.54 гх нормой

[alpet]

needbmw
Правильно я понял, что нужно инкрементировать счетчик ошибок, если found < 3 в конце проверки?

Похоже на 15 платах стабилизировался хэш-рейт, без вольтмода плавает 315-318Гх... надо ещё поколдовать задержки.

[needbmw]

needbmw
Правильно я понял, что нужно инкрементировать счетчик ошибок, если found < 3 в конце проверки?

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

[willrain]

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

[Integ]

если после реинита хэшрейт этого чипа не поднимется, попробуй уменьшить частоту его генератора (53, 52 бита), иногда это дает положительный результат.
можешь попробовать и увеличить до 55 и даже 56, но скорее всего это ни к чему хорошему не приведет.

подскажи, где что менять индивидуально для чипа.

[bee7]

Кто может прояснить суть strange решений или HW ошибок, более-менее развернуто? Мне интересно, как в целом эта ситуация алгоритмически обрабатывается: чипу дается второй шанс на выполнение задания, или задание вообще вылетает?

а вот хобот её знает.
я переделал подсчет HW ошибок (теперь считает всё), и их реально очень много, почти 80%.
вопрос почему.

Эти то не учитываете как ошибки?

Code:

if ((pn & 0xFFC00000) == 0xDF800000) continue;

[needbmw]

если после реинита хэшрейт этого чипа не поднимется, попробуй уменьшить частоту его генератора (53, 52 бита), иногда это дает положительный результат.
можешь попробовать и увеличить до 55 и даже 56, но скорее всего это ни к чему хорошему не приведет.

подскажи, где что менять индивидуально для чипа.

давно уже с командной строки задаются

- реализована опция командной строки --bitfury-clockbits для настройки фиксированных индивидуальных клок-битов без перекомпиляции.

формат:
--bitfury-clockbits={global},{slot1}:{chip1}:{bits1},{slot2}:{chip2}:{bits2},...
примеры:
--bitfury-clockbits=54 - всем чипам установить 54 бита
--bitfury-clockbits=54,0:4:53,1:2:52 - всем чипам 54, кроме слот 0 чип 4 53 бита, и слот 1 чип 2 52 бита
и т.д., если опущен первый глобальный параметр он принимает значение 54 по умолчанию.

[needbmw]

Эти то не учитываете как ошибки?

Code:

if ((pn & 0xFFC00000) == 0xDF800000) continue;

я сейчас вообще полностью изменил процесс обработки possible nonce.
хуже не стало, стало ли лучше - разбираюсь..
с HW ошибками странная картина - их количество пляшет от запуска к запуску, и хэшрейт немного тоже.
т.е. запускаю, 5-10 минут поработало, HW > 80% -> перезагружаю, поработало, HW<30% и хэшрейт подрастает на 1-2Гх/c.
почему так пока непонятно 

[Integ]

давно уже с командной строки задаются

- реализована опция командной строки --bitfury-clockbits для настройки фиксированных индивидуальных клок-битов без перекомпиляции.

формат:
--bitfury-clockbits={global},{slot1}:{chip1}:{bits1},{slot2}:{chip2}:{bits2},...
примеры:
--bitfury-clockbits=54 - всем чипам установить 54 бита
--bitfury-clockbits=54,0:4:53,1:2:52 - всем чипам 54, кроме слот 0 чип 4 53 бита, и слот 1 чип 2 52 бита
и т.д., если опущен первый глобальный параметр он принимает значение 54 по умолчанию.

О, спс, я это пропустил, буду пробовать.
Если не вручную, а в автозагрузку, куда пихать?

[Integ]

блин, не запустишь это из командной строки, только как параметр при рестарте cgminer, видимо?

[willrain]

А ты на ходу хотел, что ли? Можно и при ручном запуске, и правкой стартовых скриптов

[Integ]

А ты на ходу хотел, что ли? Можно и при ручном запуске, и правкой стартовых скриптов

да, на ходу, рестарт цг не тот эффект

[alpet]

На ходу вроде через API можно менять.

[Integ]

клок 53 и 55 для слабых чипов (=< 2Гх) особого эффекта не дало, 55 оказалось даже предпочтительнее.
Но, конечно, править каждый раз конфиг и рестартить это не вариант.
Нужна возможность менять клок "на лету".

[alpet]

клок 53 и 55 для слабых чипов (=< 2Гх) особого эффекта не дало, 55 оказалось даже предпочтительнее.
Но, конечно, править каждый раз конфиг и рестартить это не вариант.
Нужна возможность менять клок "на лету".

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