В принципе, та же идея была в форке у Легкодымова сделана - если разница между соседними вычитываниями больше 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%, но на сопоставимый хэшрейт выходит медленно (возможно мешает обильный вывод статистики). |
|
|
|
Вот кстати дамп результатов, что сейчас выводится для чипов с слишком низким хэшрейтом. Подчеркнута строка где от чипа вернулась грязь вместо nonce, я подозреваю туда один лишний бит затесался (сдвинулись все двойные слова соответственно), либо наоборот выпал из-за помех на шине SPI. Теоретически можно сделать сдвиговый механизм восстановления нужных значений, но стоит-ли овчинка выделки (вероятность выпадения решения все равно мала)? Так вот, заметно что подобных убитых строк многовато для чипов, которые дают маленький хэшрейт. Вполне вероятно что повреждаются и задания при отправке чипам. Нужно как-то отладить передачу данных, при подключенной второй плате: изменить номинал резисторов, убрать земляную петлю... нужны идеи ) Кстати у меня сейчас по наблюдением все ещё нет чипов, чей хэшрейт безнадежно до нуля угасает и их приходится передергивать. Впрочем, некоторые ещё в процессе падения форк умудряется перехватить. |
|
|
|
Да смысла нет пропускать. Ну накручивает оно HW и что? Тем более, что это именно HW. Если на следующем вычитывании оно всё доберет - и славно!
Может и есть. Уже битый час пытаюсь дождаться когда чипы в забастовку пойдут, но все неожиданно стабильно. Похоже на шине SPI иногда случается "выброс" аномальной энергии и его нужно переждать )) |
|
|
|
Если данные портятся на пересылке оттуда - это не беда. следующее вычитывание должно (может) принести ранее испорченные данные правильными, а ранее правильные может испорченными. По сути это негативно влияет только на HW, так как в результате вычитав данные 3-4 раза за задание мы теоретически должны "поймать" правильно все нонсе (исходя из предположения, что внутри чипа всё что лежит в буфере - действительно не испорченные нонсе).
По сути я так и делаю. Если данные текущего буфера кардинально отличаются от предыдущего, просто пропускаю цикл (он сейчас менее 100мс), а в следующий раз они как правило приходят в норме. |
|
|
|
Я думаю, что в случае когда приходит подряд много неправильных ответов одной серией, это означает, что порча случилась на передаче "туда", т.е. посчитал чип вовсе не то, что мы хотели. Но я у себя таких серий не вижу.
Кстати, я тут обновил свой форк еще раз. Попробуй его, если не сложно.
Ситуация даже страннее, данные как правило портятся на пересылке "оттуда", и в основном однократно при опросе. Чтобы докопаться до сути, пришлось по совету Bitfury тупо дампить все решения, и смотреть на аномалии. Сделал фикс на это дело тяжелый, и теперь HW считаются совсем по другому (18% сейчас на стоковом). Хотя их преобладание на первых 8 платах очевидно, пока нельзя сделать вывод что они влияют на хэшрейт (если задания чипу не повреждаются). Предварительно думается у меня сейчас новый рекорд по производительности, но нужно проверить поведение забастовщиков. Твой форк несколько позже смогу проверить. |
|
|
|
Странно. У меня правда только три платы в вольтмоде, и всего их 5. Отвал чипов конечно случается, но не часто. Не чаше чем раньше.
А сколько у тебя сейчас HW % ? |
|
|
|
Я тут еще чуток почистил/пооптимизировал.
Снизил в 4 раза время опроса: на 4MHz 40 чипов опрашиваются 25ms вместо 100
свой форк обновил
У меня без дополнительных задержек теперь тоже быстрый опрос, т.к. сделал переключение мультиплексора "по необходимости", но отваливание чипов чаще случается. Поэтому задержки оставил, и как видишь 208 мс на 120 чипов... |
|
|
|
попробуй дважды вызывать set_oe, вдруг это поможет.
Не помогает, как и задержки оказалось через более долгий тест. Зато выяснилось, что set_oe выполняется чертовски долго - несколько миллисекунд. Так что для отдельных плат возможно стоит единожды вызывать эту функцию... [edited] Ещё один ньюанс с засилием HW. Оказывается чаще всего ими оказывается заполнен весь буфер (ну или 13-14 из 16), что подразумевает затирание решений и вообще отбраковку задания. Тут есть вопрос, а не пропустит-ли таким образом устройство искомый nonce с блоком? Как видно на картинке, страдают от ошибок более всего первые 8 плат к контроллеру (они у меня физически так-же установлены по индексам):  |
|
|
|
Проблема скорее всего в плохом согласовании линии и отражении сигнала. Почитал немного, есть как минимум два способа терминирования SPI линии, причем резисторы в конце - самый плохой. Советуют ставить в начале. Достаточно развернутое описание по этой теме. Нужно попробовать переделать согласование линии и посмотреть к чему это приведет. Тут ещё и земляная петля в наличии, при том что земля на основной плате ещё и под мощным перегрузом (греется при вольтмоде). Занимаюсь ещё одним явлением, более неприятным чем обилие HW: отваливание чипов. На одной платке стабильно отваливался один чип, и кажется удалось с этим справиться, вставив паузы 85 микросекунд, до и после вызова tm_i2c_set_oe(slot). Делаю промежуточный вывод, что микросхемы мультиплексоров на некоторых платах тормознутые, вот только как-бы задержку теперь подобрать поменьше. |
|
|
|
Есть мнение, что автоподбор неэффективен по причине накопления лишних hw_errors в слотах 0..7. Причина их возникновения кроется, вероятно, в реализации шины SPI - отключение второй платы помогает ( https://bitcointalk.org/index.php?topic=287147.msg3267249#msg3267249 ). Нужно научиться их как-то фильтровать чтобы собирать реальные значения. Там не вторая плата виновата, а скорее всего резисторы терминаторы на ней. Они либо подобраны неправильно по номиналу (волновому сопротивлению линии не соответствуют), либо с ними ещё какая-то проблема. У меня сегодня была ситуация, когда кулером слегка их погнул, даже не допуская замыкания: так перестали чипы определяться сходу некоторые. Пока не догадался выпрямить, ничто другое не помогало (жаль не впаяли изначально SMD). Думаю надо будет проверить что с фронтами сигналов, особенно на конце линии. Отключать вторую плату на устройствах с 15-платами, это мягко говоря "не вариант" ) |
|
|
|
|
На устройствах с вольтмодом у меня все красные горят. А без вольтмода иногда мигают, т.к. пульсации напряжения бывают за 1В выходят.
|
|
|
|
|
Продано. Надеюсь оно принесет прибыль новому владельцу, т.к. мне сильно не повезло...
|
|
|
|
это не винты, это саморезы от подвесных потолков. к сожалению, саморезы нельзя как обычные винты закручивать динамометрической отверткой, они часто закусывают на полпути и плата остается не прижатой.
А у меня именно винты, М3 кажется... такими ещё крепят DVD-RW/BD-RW в компах. |
|
|
|
|
Сегодня было обновление bfgminer до версии что дает у меня наиболее высокую производительность: 315-320Гх для строенного устройства. Можно экспериментировать теперь с разными параметрами )
|
|
|
|
подскажите а в какихнить форках можно мониторить температуру чипов, или это впринципе невозможно?
Чипов температуру программно мониторить нельзя, можно мониторить температуру платы в сантиметре от самых первых чипов, что дает огромную погрешность. У меня в форке это было включено до последнего времени, сейчас отключил (сгодиться на случай аварийного перегрева только). |
|
|
|
2, 4, 10 слоты - 82Ом 1,05В. Первые и последние чипы, видимо ближайшие к врм, дико греются судя по hw.
Ещё-бы! Чтобы на крайних от DC-DC чипах было 1.05В, нужно чтобы на ближних получилось 1.07В. Все-же очень большие токи для такого тонкого слоя фольги... |
|
|
|
|
Expected over 10Ph in feb 2014, if other manufacturers success sold all chips/devices...
You still do not understand? BFL is scammers company, so for their customers have only two choices: lost money or get refund (if not to late now).
|
|
|
|
Да, образ тот, с которым устройство получил. Не самый последний, но и конфиг он при ребуте не "накрывал". (видимо 12-ый) Вот: https://github.com/bee7/bfgminerEdit: поправил одну ошибочку (раскомментировал код перед предидущим коммитом и не проверил) Сначала я подумал, что clock_gettime выдает более точное время, сделал у себя с этой функцией замер... блин 2.5 мс на чип (при 2Мгц SPI). Потом внимательно ваш код изучил, нашел ошибочку: сальдируете наносекундные дельты (в каждой мс, миллион нс!) для 256 измерений. У вас запросто переполняется 32-битное беззнаковое... P.S.: для 8 чипов сборка успешно считает с 250 мс задержкой. |
|
|
|
|
У меня на чипах 60С, на плате 45С, программный мониторинг выдает 36С (feel difference!). Собирал сам, пасты не жалел и вымазывал отдельно как плату, так и радиатор )
|
|
|
|
|
bee7
Инструкцию отправил. Вот ещё хочется уточнить, у вас образ RasPi от Метабанка и драйверы соответственно родные?
|
|
|
|
|
Show Posts
