Я тут померил даже ради любопытства. Среднее время 1го скана 40 чипов вместе с отправкой nonce 13 милисекунд. 120 чипов было бы 36 милисекунд. а я скан запускаю раз в 250 милисекунд.
Эдит: пробовал и на частоте spi 4000000 и на 400000 - результат не меняется, я б даже сказал, вопреки ожиданиям на 400000 скан занимает 10мс
Вот это очень любопытный результат, покажите код? У меня четкая реакция на увеличение частоты SPI - среднее время 10 опросов снижается. Использую для замера cgtime, можете посмотреть как вычисляется median_load здесь в строках 1177-1181. |
|
|
|
|
Вопросик остался незамеченным: если флаг job_switched выставился, то чип не пишет в текущий буфер результатов, от того которое начало выполняться? В том смысле, не возможно затирание результатов, если долго не опрашивали чип?
Или же буфер результатов начинает изменяться лишь после загрузки нового задания?
|
|
|
|
Есть ли смысл ее поднимать? Я сейчас опрос произвожу раз в 250 милисекунд: производительность хешрейт тот же, что и если непрерывно опрашивать.
Раз в 250 миллисекунд, опрашиваете 120 чипов? Что-то не вериться, что такое возможно... у меня такой опрос занимает от 360 мс (3 мс, на чип). В моем форке цикл лимитирован по времени, т.е. перед выходом из функции scanHash опрашивается произвольное число чипов (сколько успеет за 500 мс), и размер цикла можно регулировать... В целом хорошо, если чип опрашивается 2-3 раза в секунду, но я заметил основное отличие bfgminer от cgminer - максимально частый опрос, и это заметно влияет на хэшрейт (что удивительно, ведь есть буферизация заданий). |
|
|
|
ок, только вот теперь не понимаю причем тут переменнная dups если вы её после даже не используете?)))
551 строка насколько я понял
ктонибудь объяснит зачем объясляем переменную dups?
Да это из моего форка, счетчик дубликатов. Он уже не нужен стал, поскольку дубликатов не стало вообще ) Кстати, правка позволяет безболезненно поднимать частоту SPI. Сейчас я тестирую на 2МГц, показатели HW не изменились, а вот время опроса чипа сократилось с 3 до 2.5 мс. Соответственно можно ещё сильнее разгрузить CPU, или увеличить частоту опроса чипов (ротацию очереди в моем форке). |
|
|
|
нет. мы ему всё время отправляем новое задание. как только мы получаем job_switched - оно начало выполнятся. в этот момент мы запрашиваем следующее задание и начинаем долбить чип им.
Если флаг этот стоит, то чип не пишет в текущий буфер результатов, от того которое начало выполняться? В том смысле, не возможно затирание результатов, если долго не опрашивали чип? в каком файле это проправить? хочу проверить что будет без вольтмода
libbitfury.c libbitfury_sendHashData если в оригинальных форках. По идее на хэшрейт особо не должно повлиять, если нет явной голодовки чипов. |
|
|
|
Ээхм, не многовато ли 24Гх для 4 чипов?  Опечатка, 8 чипов  |
|
|
|
кстати, сколько жрет твой модуль на 1.05В?
Пока что это проблемно измерить. Устройство на 120 чипов с вольтмодом перегружает UPS 1000VA, а устройство на 96 чипов, не перегружает ) Замерял когда-то ток на 12В шине, для одной платки (видимо без вольтмода): osc6_bits = 53, 2.3А
osc6_bits = 54, 2.4А (12В)
osc6_bits = 55, 2.6А
osc6_bits = 56, 2.78А, хэшрейт минимальный
Кстати, на устройстве с 96 чипами, все-же и с последней правкой HW держится около 23%. Думаю это связано с голодом чипов, но точно не уверен. Правильно я понимаю, что при установленном флаге job_switched чип отдает решения по старому заданию, а работает уже по новому? Т.е. мы отправляем ему старое задание при обмене, уже зря (таков протокол). |
|
|
|
майнер люка дал небольшую прибавку
итого
стоковый сгминер - 104.2гх
сгминер нидбмв - честные 104гх
бфгминер нидбмв - 105.5гх ~4% хардваров(на самом деле меньше ,если не учитывать ошибки при старте).Единственный майнер ,который перезапускает отвалившиеся чипы
бфгминер люка - 106.1гх ,скорость перестала плавать ,0.8% хардваров
У меня bfgminer тоже чипы реанимирует ) А вот скорости сравнивать самому некогда... |
|
|
|
Продолжаю тут эксперименты с оценкой результатов, и подсчетом HW/strange results. Одна лишь простейшая правка, в области оценки решений от чипа: int dups = 0;
if (op && o2p && d->job_switched)
for (i = 0; i < 16; i++) {
if (oldbuf[i] != newbuf[i] ) {
Дала интересный результат: 1. Хэшрейт моментально стал жестким на всю плату, 24.5 +- 0.2Гх. До этого все плавало, то к 22Гх, то к 26Гх. 2. Количество HW с десятков процентов (от 40%) свалилось к 0.5% и продолжает убывать... Проверка проводится на единичной плате Метабанка ( 8 чипов), с вольтмодом около 1.057В. Насколько мне понятен исходный код, получается очень часто одна и та-же HW ошибка, считается много раз. Ведь до переключения заданий, все значения в буфере результатов учитываются как новые... |
|
|
|
клок 53 и 55 для слабых чипов (=< 2Гх) особого эффекта не дало, 55 оказалось даже предпочтительнее.
Но, конечно, править каждый раз конфиг и рестартить это не вариант.
Нужна возможность менять клок "на лету".
Когда-то я тоже так думал, что возможности для оперативного вмешательства нужны. Сделал автоподбор брутфорсом даже. Но сейчас, все идет к тому, что каждый чип надо на другой частоте гонять часами, и собирать статистику производительности. Только тогда переключение может оказаться оправданным... |
|
|
|
|
На ходу вроде через API можно менять.
|
|
|
|
|
Что касается навеса конденсаторов и изменения хэшрейта. Мне кажется есть корреляция между хэшрейтом и верхней границей пульсаций напряжения. Фактически, если убрать все конденсаторы, мы получаем высокочастотный вольтмод (на платах Метабанка и более 1.12В бывает) под 150 тысяч раз в секунду, при этом сравнительно экономичный по потреблению энергии. Тем не менее, вроде как наилучшие результаты по хэшрейту были достигнуты с ФЭ, а это почти линейное напряжение. Соответственно, кто гонится за энергоэффективностью, может экспериментировать в направлении "без сглаживания пульсаций", а кто за максимумом Гх на чип... соответственно вынужден исследовать вольтмод с желательным избеганием пульсаций выше 1.1В.
|
|
|
|
|
needbmw
Правильно я понял, что нужно инкрементировать счетчик ошибок, если found < 3 в конце проверки?
Похоже на 15 платах стабилизировался хэш-рейт, без вольтмода плавает 315-318Гх... надо ещё поколдовать задержки.
|
|
|
|
Это с 3-го батча?
Именно, с самого кошмарного... хотя есть "счастливчики" и от первого батча получили NULL. |
|
|
|
а вот хобот её знает.
я переделал подсчет HW ошибок (теперь считает всё), и их реально очень много, почти 80%.
вопрос почему.
Обновишь на github? У меня пока подозрение падает, что число таких решений зависит от частоты опроса чипов. Если она слишком чрезмерная, то счет или сбивается, или ещё что-то происходит. Например, в своем форке я добавил между опросом каждого чипа паузу в 500 мкс, и HW упало с 50% к 34% примерно. Сейчас порядка 5Гх выигрываю на устройстве с вольтмодом, только из-за более частого внеочередного опроса "хороших" чипов. Думаю из-за HW просто не получается все опросы за 480 мс своевременно провести, поэтому готовых чипов (у которых job_switched != 0) к моменту опроса довольно большое количество. А с таким флагом надо думать, если чип ждет ещё сколько-то мс, он может и второе задание решить - запросто опять переключит буфера. Так что гипотеза сейчас такая, свести время опроса каждого чипа к оптимуму, чтобы успевать и не торопить одновременно ) |
|
|
|
закомментировал и открыл строку с // #define BITFURY_NEEDBMW_NOMUX 1
запустил билд.сш, запустил сгмайнер, идет очень долгий очень долгий поиск чипа и на 9 слоте он его находит.
Пока что ошибок очень много и скорость всего 400 мхешей
Если честно, у меня нет возможности тестировать альтернативные устройства, кроме как от Метабанка. Наверное этот форк только с ними и будет работать... invaderСамая большая проблема этого подбора на сейчас, не сложность алгоритма отбора. Слишком маленькие периоды для тестов, при том что в них включается период "холодного хэширования". Что-же до логики, попытаюсь описать насколько помню. 1. В массиве rbc_stat собираются четыре значения хэшрейта, за четыре раунда брутфорса. У каждого раунда выбирается соответственно своя частота осциллятора, в этом суть брутфорса. 2. Что касается csum, если было три соревнования, то наверняка определится две наилучших частоты, между которыми потом будет сравнение происходить. Для двух вариантов вроде как нет смысла делать четыре раунда. [edited] Сейчас несколько другая идея по оптимизации. Программа научилась собирать статистику по чипам в гистограммы, и записывать в отдельные файлы. Так что вольтмодим, гоняем день на 54, день на 53 (сохраняем файлы отдельно). Потом из таблицы в консоли выбираем те чипы, у которых прям замечательные результаты на 54 и сверяем для них файлы. Несколько больше ручной работы, но надежность наверняка выше будет. Чтобы файлы начали дампиться в /var/log/bitfury необходимо раскомментировать #define BITFURY_CHIP_STAT. Кстати стоит сделать скрипт их архивации/бэкапа, поскольку в полночь они превращаются в тыквы затираются. |
|
|
|
|
Сейчас исследую проблему голодания чипов в bfgminer, чего на самом деле благодаря буферизации быть не должно (во всяком случае часто). Некоторые ухищрения позволили на устройстве с вольтмодом, выжать дополнительные Гх (тестирую где оптимум пока).
Кто может прояснить суть strange решений или HW ошибок, более-менее развернуто? Мне интересно, как в целом эта ситуация алгоритмически обрабатывается: чипу дается второй шанс на выполнение задания, или задание вообще вылетает?
|
|
|
|
Так а сколько окупить успел?
Да я даже не считал, чтобы сильнее не расстраиваться. Порядка 20 августа включил его, может быть сутки простоя были всего-лишь. |
|
|
|
|
В личке сообщения по порядку от Santus, RenFarm, OZR. Отписал пока первому.
P.S.: Вообразите, сколько у меня ненависти к BitSyncom, учитывая что заплатил 78 монет за этот набор убогих чипов )
|
|
|
|
так,это понял, а дефайны можно самому исправить, если да то где ?
nano bitfury-config.h |
|
|
|
|
Show Posts
