в целом ситуация такая. оригинальный икарус работал на 0.38 Гх/c, выдавал чуть более 5 шар
в минуту и протокол обмена с майнером под это дело был выбран соответствующий - дали задание, послушали нонсы, дали следующее задание, и т.д. (и, заметьте, никакой буферизации заданий!).
протокол икаруса отличный, простой и понятный, но он не очень хорошо подходит для мощных устройств.
по моим расчетам и наблюдениям потолок для него 10Гх/c (кстати, когда китайцы делали авалон им пришлось поменять протокол именно из-за непригодности икарусовского протокола для 60+ гигахэшных устройств).
у меня была разработана версия битстрима и с реализацией протокола авалона, и она даже работала. но после обкатки выяснилось, что авалоновский протокол сильно избыточен для такой маленькой платы, у него есть проблемы с синхронизацией, и разные мелкие недостатки которые не были исправлены даже в самом авалоне, а заткнуты костылями в майнере. поэтому в серию пошел стабильный битстрим с протоколом икарус.
на наши 5.5-6Гх протокол икаруса работает вполне себе неплохо
если он нормально реализован в майнере.
к сожалению, последние версии как cgminer, так и (особенно) bfgminer имеют целые гроздья непонятных коммитов в драйвер икаруса, связанных с переходом на WinUSB и поддержку других устройств, работающих по этому или подобному протоколу, в результате эти последние версии стали работать с моей платой плохо. сам я тестирую платы на морально устаревшем cgminer 3.1.0 и на MPBM (у этого вообще отличная и очень старая реализация протокола именно для икаруса, не перегруженная всякой ерундой).
теперь как это все связано с числом HW ошибок.
дело в том, что HW ошибки засекаемые майнером делятся на два типа. первый тип - ошибки возникающие непосредственно в чипах (причины я думаю все знают - перегрев, плохое питание, слишком высокая частота, чип не совсем здоровый и т.д.). нормой для авалоновских чипов считается HW порядка 2% (я считаю, что при комнатной температуре и 3% тоже норма).
второй тип ошибок - ошибки, возникающие в процессе обмена с майнером. тут на пальцах объяснить трудно, но попробую - чип находит нонсе, отправляет его в майнер. нонсе не сразу попадает в майнер, а висит некоторое время в разных буферах, например в буфере UART, потом в буфере FTDI, потом в буфере драйвера USB, потом в буфере ОС, и только потом попадает в майнер. за это время майнер мог отправить новое задание, старое при этом аннулируется, и нонсе не проходит проверку и засчитывается как HW (если посмотрите код cgminer - он не может различить причину ошибки, не подошел нонсе - ошибка и точка).
к чему такая длинная простыня.
для очистки совести нужно провести некоторую работу - взять плату, выдающую 4-5% HW в cgminer >3.4.0 и погонять ее и с bfgminer, и c cgminer <= 3.1.0, и желательно с MPBM, причем не по 10 минут, а хотя бы сутки.
еще желательно погонять ее же при разных температурах (например комнатная, лоджия-балкон и т.д.)
тогда можно будет оценить показания разных майнеров и сделать выводы ошибки каких типов мы наблюдаем, и сколько дают чипы, а сколько возникает за счет протокола.
я это делал на прототипной плате, но она другая, сильно отличается от серийной, и результаты тоже разные будут (на прототипной тот же bfgminer дает больше 5% HW ошибок, а MPBМ стабильно 2.6% в тех же условиях).
а с серийными мне к сожалению в связи с кризисом производства подобными изысканиями сейчас заниматься просто некогда.
извиняюсь за битфури-стайл изложения, вопрос вообще сложный с этими HW ошибками...
Может winusb (с помощью zadig) как-то не так установил? Пора дополнить инструкцию в первом посте
если майнер увидел икарус и майнит - дрова встали как надо.
