*gminers forks by alpet

[bee7]

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

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

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

[1713413032]

1713413032

[1713413032]

1713413032

[1713413032]

1713413032

[alpet]

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

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

[bee7]

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

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

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

[alpet]

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

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

[alpet]

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

[bee7]

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

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

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

[alpet]

В принципе, та же идея была в форке у Легкодымова сделана - если разница между соседними вычитываниями больше 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%, но на сопоставимый хэшрейт выходит медленно (возможно мешает обильный вывод статистики).

[bee7]

В принципе, та же идея была в форке у Легкодымова сделана - если разница между соседними вычитываниями больше 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%.
За тест спасибо.

[alpet]

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

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

[bee7]

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

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

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

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

[alpet]

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

[AtomicStrike]

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

[alpet]

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

Надо раскоментировать в начале файла driver-bitfury.c строку:

Code:

// #define BITFURY_MONITORING

Только проверьте хэшрейт с включенным и выключенным мониторингом, скорее всего он ухудшиться.

[AtomicStrike]

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

[alpet]

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

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

[core]

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

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

[alpet]

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

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

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

[core]

2. Скорость надо смотреть среднюю за сутки на пуле. С таким вольтмодом 2.83 на чип вроде нормально, хотя нужно скорее смотреть прирост.

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

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

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

[alpet]

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

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

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

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

[alpet]

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