bee7
|
|
October 01, 2013, 04:43:43 PM |
|
Я думаю, что в случае когда приходит подряд много неправильных ответов одной серией, это означает, что порча случилась на передаче "туда", т.е. посчитал чип вовсе не то, что мы хотели. Но я у себя таких серий не вижу. Кстати, я тут обновил свой форк еще раз. Попробуй его, если не сложно.
Ситуация даже страннее, данные как правило портятся на пересылке "оттуда", и в основном однократно при опросе. Чтобы докопаться до сути, пришлось по совету Bitfury тупо дампить все решения, и смотреть на аномалии. Сделал фикс на это дело тяжелый, и теперь HW считаются совсем по другому (18% сейчас на стоковом). Хотя их преобладание на первых 8 платах очевидно, пока нельзя сделать вывод что они влияют на хэшрейт (если задания чипу не повреждаются). Предварительно думается у меня сейчас новый рекорд по производительности, но нужно проверить поведение забастовщиков. Твой форк несколько позже смогу проверить. Если данные портятся на пересылке оттуда - это не беда. следующее вычитывание должно (может) принести ранее испорченные данные правильными, а ранее правильные может испорченными. По сути это негативно влияет только на HW, так как в результате вычитав данные 3-4 раза за задание мы теоретически должны "поймать" правильно все нонсе (исходя из предположения, что внутри чипа всё что лежит в буфере - действительно не испорченные нонсе).
|
|
|
|
alpet (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 01, 2013, 04:53:36 PM |
|
Если данные портятся на пересылке оттуда - это не беда. следующее вычитывание должно (может) принести ранее испорченные данные правильными, а ранее правильные может испорченными. По сути это негативно влияет только на HW, так как в результате вычитав данные 3-4 раза за задание мы теоретически должны "поймать" правильно все нонсе (исходя из предположения, что внутри чипа всё что лежит в буфере - действительно не испорченные нонсе).
По сути я так и делаю. Если данные текущего буфера кардинально отличаются от предыдущего, просто пропускаю цикл (он сейчас менее 100мс), а в следующий раз они как правило приходят в норме.
|
|
|
|
bee7
|
|
October 01, 2013, 04:57:17 PM |
|
Если данные портятся на пересылке оттуда - это не беда. следующее вычитывание должно (может) принести ранее испорченные данные правильными, а ранее правильные может испорченными. По сути это негативно влияет только на HW, так как в результате вычитав данные 3-4 раза за задание мы теоретически должны "поймать" правильно все нонсе (исходя из предположения, что внутри чипа всё что лежит в буфере - действительно не испорченные нонсе).
По сути я так и делаю. Если данные текущего буфера кардинально отличаются от предыдущего, просто пропускаю цикл (он сейчас менее 100мс), а в следующий раз они как правило приходят в норме. Да смысла нет пропускать. Ну накручивает оно HW и что? Тем более, что это именно HW. Если на следующем вычитывании оно всё доберет - и славно!
|
|
|
|
alpet (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 01, 2013, 05:32:45 PM |
|
Да смысла нет пропускать. Ну накручивает оно HW и что? Тем более, что это именно HW. Если на следующем вычитывании оно всё доберет - и славно!
Может и есть. Уже битый час пытаюсь дождаться когда чипы в забастовку пойдут, но все неожиданно стабильно. Похоже на шине SPI иногда случается "выброс" аномальной энергии и его нужно переждать ))
|
|
|
|
alpet (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 02, 2013, 06:52:29 AM |
|
Вот кстати дамп результатов, что сейчас выводится для чипов с слишком низким хэшрейтом. Подчеркнута строка где от чипа вернулась грязь вместо nonce, я подозреваю туда один лишний бит затесался (сдвинулись все двойные слова соответственно), либо наоборот выпал из-за помех на шине SPI. Теоретически можно сделать сдвиговый механизм восстановления нужных значений, но стоит-ли овчинка выделки (вероятность выпадения решения все равно мала)? Так вот, заметно что подобных убитых строк многовато для чипов, которые дают маленький хэшрейт. Вполне вероятно что повреждаются и задания при отправке чипам. Нужно как-то отладить передачу данных, при подключенной второй плате: изменить номинал резисторов, убрать земляную петлю... нужны идеи ) Кстати у меня сейчас по наблюдением все ещё нет чипов, чей хэшрейт безнадежно до нуля угасает и их приходится передергивать. Впрочем, некоторые ещё в процессе падения форк умудряется перехватить.
|
|
|
|
bee7
|
|
October 02, 2013, 07:09:43 AM |
|
Вот кстати дамп результатов, что сейчас выводится для чипов с слишком низким хэшрейтом. Подчеркнута строка где от чипа вернулась грязь вместо nonce, я подозреваю туда один лишний бит затесался (сдвинулись все двойные слова соответственно), либо наоборот выпал из-за помех на шине SPI. Теоретически можно сделать сдвиговый механизм восстановления нужных значений, но стоит-ли овчинка выделки (вероятность выпадения решения все равно мала)? Так вот, заметно что подобных убитых строк многовато для чипов, которые дают маленький хэшрейт. Вполне вероятно что повреждаются и задания при отправке чипам. Нужно как-то отладить передачу данных, при подключенной второй плате: изменить номинал резисторов, убрать земляную петлю... нужны идеи ) Кстати у меня сейчас по наблюдением все ещё нет чипов, чей хэшрейт безнадежно до нуля угасает и их приходится передергивать. Впрочем, некоторые ещё в процессе падения форк умудряется перехватить. В принципе, та же идея была в форке у Легкодымова сделана - если разница между соседними вычитываниями больше 4 слов, то он тут же перечитывал чип. Меня очень интересует, что покажет мой форк на твоей железке. У меня с последнего перегруза она набрала 61 тысячу HW ошибок (3.6%) на 2.7 миллиона сгенерированных local work.
|
|
|
|
alpet (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 02, 2013, 10:28:06 AM |
|
В принципе, та же идея была в форке у Легкодымова сделана - если разница между соседними вычитываниями больше 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
|
|
October 02, 2013, 10:53:58 AM |
|
В принципе, та же идея была в форке у Легкодымова сделана - если разница между соседними вычитываниями больше 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 (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 02, 2013, 11:07:49 AM |
|
Нда. Видимо мне повезло с устройством. разогнал еще одну плату HW подросли, но суммарно всё еще 3.9%. За тест спасибо.
У тебя это значение все-же ещё избыточно, одна и та-же ошибка наверняка много раз считается. Проверь на простом тесте, если при росте частоты опросов (для этого уменьшить задержку с 250 мс до 50 мс например), число HW будет так-же расти заметно, то это прирост ложных оценок. Сейчас уже понятно стало окончательно, что на устройствах с двумя мат. платами основной источник HW далеко не чипы, и соответственно их влияние на хэшрейт стремиться к нулю.
|
|
|
|
bee7
|
|
October 02, 2013, 11:12:55 AM |
|
Нда. Видимо мне повезло с устройством. разогнал еще одну плату HW подросли, но суммарно всё еще 3.9%. За тест спасибо.
У тебя это значение все-же ещё избыточно, одна и та-же ошибка наверняка много раз считается. Проверь на простом тесте, если при росте частоты опросов (для этого уменьшить задержку с 250 мс до 50 мс например), число HW будет так-же расти заметно, то это прирост ложных оценок. Сейчас уже понятно стало окончательно, что на устройствах с двумя мат. платами основной источник HW далеко не чипы, и соответственно их влияние на хэшрейт стремиться к нулю. Да нет, меня 4% ошибок устраивают, если наши предположения об их источнике верны. А твой результат на моем форке (50%) явно за это говорит: шум в SPI привносит очень много ошибок. Тем более, что ошибки передачи - это тоже HW ошибки. Едит: И, это, одна и та же ошибка у меня считается только 1 раз. Если при следующей передаче возникла ошибка в том же слове но другая - да она будет посчитана. но если ошибка в самом содержимом в буфере в чипе, то она будет учтена только 1 раз.
|
|
|
|
alpet (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 07, 2013, 04:13:21 AM |
|
В последних ревизиях исправил проблему с ложной оценкой факта job_switched. На сейчас наблюдается средний хэшрейт 319 для строенного устройства и менее 2% HW. По показаниям пула хэшрейт ещё выше, видимо из-за учета Stale.
|
|
|
|
AtomicStrike
|
|
October 07, 2013, 04:51:26 AM |
|
alpet Подскажите, пожалуйста, как сделать, чтобы ваш bfgminer в статистике выводил еще и напряжение питания плат? У меня почему-то показывает все, кроме этого.
|
|
|
|
alpet (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 07, 2013, 04:56:15 AM Last edit: October 07, 2013, 09:04:28 AM by alpet |
|
alpet Подскажите, пожалуйста, как сделать, чтобы ваш bfgminer в статистике выводил еще и напряжение питания плат? У меня почему-то показывает все, кроме этого.
Надо раскоментировать в начале файла driver-bitfury.c строку: // #define BITFURY_MONITORING
Только проверьте хэшрейт с включенным и выключенным мониторингом, скорее всего он ухудшиться.
|
|
|
|
AtomicStrike
|
|
October 07, 2013, 09:36:31 AM |
|
Как ни странно, хешрейт с мониторингом особо не ухудшился, даже параметр u: подрос немного, с 204 до 208 Гх/с на двойном метафурике.
|
|
|
|
alpet (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 07, 2013, 11:05:18 AM |
|
Как ни странно, хешрейт с мониторингом особо не ухудшился, даже параметр u: подрос немного, с 204 до 208 Гх/с на двойном метафурике.
Возможно на 10 платах будет нормально. У меня на 15 вроде как снижается. В любом случае, это число стоит оценивать на периоде час-два, оно от удачи вроде как плавает.
|
|
|
|
core
|
|
October 07, 2013, 01:33:23 PM |
|
попробовал я ваш форк. В целом вроде немного быстрее чем форк от нидбмв. Но при этом есть небольшие непонятные глюки. В веб морде в разделе чип инфо почему-то сбрасываются счетчики ошибок на 0. Т.е. показатель errors почти всегда на 0%. Хотя сам майнер считает хардвары нормально.
Потом скорость у меня получилась 158-159 гх на 7 плат при 1,0В на чипах. Это нормально или мало?
|
|
|
|
alpet (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 07, 2013, 02:01:40 PM |
|
попробовал я ваш форк. В целом вроде немного быстрее чем форк от нидбмв. Но при этом есть небольшие непонятные глюки. В веб морде в разделе чип инфо почему-то сбрасываются счетчики ошибок на 0. Т.е. показатель errors почти всегда на 0%. Хотя сам майнер считает хардвары нормально.
Потом скорость у меня получилась 158-159 гх на 7 плат при 1,0В на чипах. Это нормально или мало?
1. У меня счетчик HW действительно обнулению подвергается. Чтобы выяснять частоту возникновения ошибок за период. Как-нибудь переделаю этот алгоритм. 2. Скорость надо смотреть среднюю за сутки на пуле. С таким вольтмодом 2.83 на чип вроде нормально, хотя нужно скорее смотреть прирост.
|
|
|
|
core
|
|
October 08, 2013, 07:26:36 AM |
|
2. Скорость надо смотреть среднюю за сутки на пуле. С таким вольтмодом 2.83 на чип вроде нормально, хотя нужно скорее смотреть прирост.
Скорость за сутки устаканилась в меньшую сторону Теперь 157-158 показывает. На пуле за пол дня 158 стабильно держится. До этого было 145-146, т.е. где-то 2,6 гх/чип. Я так понимаю до 3 гх с чипа конкретно этим платам не суждено дотянуть... Температуру нормально измерить не получается, но палец держать на чипе терпимо. Так что по ощущениям 60-70 градусов. Охлад я максимум как можно улучшил, разве только радиаторы на чипы не лепил. Думаю как все остальные замоддю, то на балкон их вытащу и попробую 1,05 выставить. Кстати как bits выставлять? Это где-то в сырцах править? У меня сейчас 54, а для 1.05 лучше 53?
|
|
|
|
alpet (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 08, 2013, 08:11:54 AM |
|
Скорость за сутки устаканилась в меньшую сторону Теперь 157-158 показывает. На пуле за пол дня 158 стабильно держится. До этого было 145-146, т.е. где-то 2,6 гх/чип. Я так понимаю до 3 гх с чипа конкретно этим платам не суждено дотянуть... Температуру нормально измерить не получается, но палец держать на чипе терпимо. Так что по ощущениям 60-70 градусов. Охлад я максимум как можно улучшил, разве только радиаторы на чипы не лепил. Думаю как все остальные замоддю, то на балкон их вытащу и попробую 1,05 выставить. Кстати как bits выставлять? Это где-то в сырцах править? У меня сейчас 54, а для 1.05 лучше 53? 1. Скорость усредняется медленно, плюс разные условия влияют (например холодный запуск). 2. Выставить можно через командную строку, т.к. я сливал свой код с форком от needbmw. Вроде как --biftury-clockbits="53," должно работать.
|
|
|
|
alpet (OP)
Legendary
Offline
Activity: 1912
Merit: 1020
|
|
October 08, 2013, 12:13:24 PM |
|
Сделал обновление с более-менее честным подсчетом аппаратного хэшрейта (скорости перебора нонсов) с вычетом плохих решений. Он более стабилен, чем расчет по шарам и акцептованным шарам, поскольку не зависит от удачи. Стало-быть можно тестировать будет скоро и автоподбор частоты осциллятора. Так-же теперь в короткой статистике честно указывается процент аппаратных ошибок, что позволяет улучшить вольтмод при тонкой подстройке.
|
|
|
|
|