Вот со статистикой, код driver-bitfury.c сейчас, явно содержит ошибку и конечно выдает ахинею
это исправлю, я ни LONG STAT ни SHORT STAT не использую (вообще убрал из компиляции), смотрю статистику только через API, поэтому эта часть не тестированная получилась 
Topic: мои форки cgminer и bfgminer для bitfury ASIC - page 29. (Read 53319 times)
alpet, какие результаты дала твоя автоподстройка? есть прирост по сравнению со статикой?
Я ещё разбираюсь, но пока рано оценивать. Сама автоподстройка рубит хэшрейт жестоко, поэтому надо её сделать завершаемой после скажем 30 минут работы. Вот со статистикой, код driver-bitfury.c сейчас, явно содержит ошибку и конечно выдает ахинею:
Code:
222: for(k = 0; k < BITFURY_BANKCHIPS; k++) {
Code:
222: for(k = 0; k < BITFURY_BANKCHIPS/2; k++) {
Может прогнать клоки по всем чипам (например от 51 до 55), по 10 минут это около часа, залогировать полезные значения (Хэши-HW) для каждого клока,каждого чипа. Всё взвесить (определить наилучший клок для чипа), сбросить в файлик с настройками и выставлять соответствующий клок на соответствующем чипе.
у них питание групповое, когда подойдешь к пределу DC/DC (а разгон это всегда работа питалова на пределе) ничего не понятно будет.. один чип начнет чуть больше жрать и у всех остальных в группе хешрейт тут же провалится.alpet, какие результаты дала твоя автоподстройка? есть прирост по сравнению со статикой?
- увеличил размер буфера в api.c, при 100 чипах в цепочке теперь не вылетает при запросе статистики (длиннее цепочки нет, проверьте на более длинных)
на 120 штук теперь нормально работает.
я смотрю с усреднением 10 минут.
про 20-50% никто и не говорит, а вот 10% - легко.
и попадаются экземпляры, которые дают 2,5Гх при 3% hw, и заветные 3Гх при 10%, и будет неправильно не использовать их потенциал.
Золотые слова, 10% прироста лучше чем его нет.про 20-50% никто и не говорит, а вот 10% - легко.
и попадаются экземпляры, которые дают 2,5Гх при 3% hw, и заветные 3Гх при 10%, и будет неправильно не использовать их потенциал.
Может прогнать клоки по всем чипам (например от 51 до 55), по 10 минут это около часа, залогировать полезные значения (Хэши-HW) для каждого клока,каждого чипа. Всё взвесить (определить наилучший клок для чипа), сбросить в файлик с настройками и выставлять соответствующий клок на соответствующем чипе.
needbmw
На каком периоде ты оцениваешь изменение хэш-рейта? Мне вот представляется, что 20-50% HW по отношению к Accepted это не есть хорошо. К тому-же при массовом разгоне, некоторые чипы порой просто вырубаются - по ним 0Гх в SHORT stat, и количество ошибок быстро растет.
Кстати выложил свою модификацию driver-bitfury.c с автоподбором, может какие-то кусочки используешь ).
я смотрю с усреднением 10 минут.На каком периоде ты оцениваешь изменение хэш-рейта? Мне вот представляется, что 20-50% HW по отношению к Accepted это не есть хорошо. К тому-же при массовом разгоне, некоторые чипы порой просто вырубаются - по ним 0Гх в SHORT stat, и количество ошибок быстро растет.
Кстати выложил свою модификацию driver-bitfury.c с автоподбором, может какие-то кусочки используешь ).
про 20-50% никто и не говорит, а вот 10% - легко.
и попадаются экземпляры, которые дают 2,5Гх при 3% hw, и заветные 3Гх при 10%, и будет неправильно не использовать их потенциал.
Changelog на сегодня:
- реализована опция командной строки --bitfury-clockbits для настройки фиксированных индивидуальных клок-битов без перекомпиляции.
формат:
--bitfury-clockbits={global},{slot1}:{chip1}:{bits1},{slot2}:{chip2}:{bits2},...
примеры:
--bitfury-clockbits=54 - всем чипам установить 54 бита
--bitfury-clockbits=54,0:4:53,1:2:52 - всем чипам 54, кроме слот 0 чип 4 53 бита, и слот 1 чип 2 52 бита
и т.д., если опущен первый глобальный параметр он принимает значение 54 по умолчанию.
- при запуске майнера автоматически подгружаются необходимые SPI и I2C модули
- увеличил размер буфера в api.c, при 100 чипах в цепочке теперь не вылетает при запросе статистики (длиннее цепочки нет, проверьте на более длинных)
needbmw
На каком периоде ты оцениваешь изменение хэш-рейта? Мне вот представляется, что 20-50% HW по отношению к Accepted это не есть хорошо. К тому-же при массовом разгоне, некоторые чипы порой просто вырубаются - по ним 0Гх в SHORT stat, и количество ошибок быстро растет.
Кстати выложил свою модификацию driver-bitfury.c с автоподбором, может какие-то кусочки используешь ).
На каком периоде ты оцениваешь изменение хэш-рейта? Мне вот представляется, что 20-50% HW по отношению к Accepted это не есть хорошо. К тому-же при массовом разгоне, некоторые чипы порой просто вырубаются - по ним 0Гх в SHORT stat, и количество ошибок быстро растет.
Кстати выложил свою модификацию driver-bitfury.c с автоподбором, может какие-то кусочки используешь ).
alpet, я пока подбираю вручную и вот что получается.
есть чипы, которые недодают хэшрейт, при снижении клока до 52-53 бит хэшрейт повышается, hw снижаются (все логично).
но встречаются и другие чипы, у которых при повышении клока повышаются hw, но при этом и хэшрейт у них растет прилично! (я наблюдал у отдельных экземпляров даже 3.2 на последней сборке, в ней надеюсь не попугаи а гигахэши все же).
получается, если будем нормировать hw - задушим и стахановцев...
есть чипы, которые недодают хэшрейт, при снижении клока до 52-53 бит хэшрейт повышается, hw снижаются (все логично).
но встречаются и другие чипы, у которых при повышении клока повышаются hw, но при этом и хэшрейт у них растет прилично! (я наблюдал у отдельных экземпляров даже 3.2 на последней сборке, в ней надеюсь не попугаи а гигахэши все же).
получается, если будем нормировать hw - задушим и стахановцев...
Добавил ещё аппаратные датчики:
Рекомендуют не запускать часто i2c вызовы, но для оверклокинга без этого сложно.
Рекомендуют не запускать часто i2c вызовы, но для оверклокинга без этого сложно.
Balthazar
Так хэш-рейт заметно не изменяется, при модификации osc6_bits. Что-же тогда ещё оптимизировать?
Так хэш-рейт заметно не изменяется, при модификации osc6_bits. Что-же тогда ещё оптимизировать?
Самое забавное тут в том, что далеко не факт что конфигурация с меньшим % HW окажется лучше в деле.
Пытаюсь сделать автоподборщик, на базе последних файлов:
Основная цель, чтобы hw_errors в среднем были не более 2% от суммы hw_errors и shares_found. Обновление частот производится каждый 16-ый цикл.
Для лучшей стабильности результатов, назначаю процессу cgminer приоритет -19.
Основная цель, чтобы hw_errors в среднем были не более 2% от суммы hw_errors и shares_found. Обновление частот производится каждый 16-ый цикл.
Для лучшей стабильности результатов, назначаю процессу cgminer приоритет -19.
Поэтому я и сказал, 'не рубите сплеча', пусть пользователь сам контролирует, отсылать ли майнеру опоздавшие шары на пул или нет.
А про это речи и не было. Как раз я и написал что есть и другие пулы, которые примут такие шары.
Поэтому я и сказал, 'не рубите сплеча', пусть пользователь сам контролирует, отсылать ли майнеру опоздавшие шары на пул или нет.
Как правило таких нод очень небольшое количество, если специально не собирать самые тормозные (а этого точно не стоит делать).
Когда вы уже приняли блок, это означает что кто-то из ваших соседей уже получил этот новый блок.
Маэестро, вы не забыли тему беседы? Речь шла про то, стоит ли опоздавшее решение из буфера чипа извлекать и возвращать пулу или нет. Тут счет идет на миллисекунды, на грани пингов и помех в связи между нодами bitcoin.Когда вы уже приняли блок, это означает что кто-то из ваших соседей уже получил этот новый блок.
Дальнейшее увеличение времени опоздания будет влиять только на вероятность того, что этот опоздавший блок кто то поймает первым и найдет свой блок, прописав в его предки этот опоздавший.
Ограничил stats, чтобы только по первым 90 чипам инфу давал - все нормально. Больше - fail. Где-то размера буфера не хватает. Может, ограничить длину строк (типа не "match_work_count", а ""m_wrk_cnt")? не в этом дело.
попробуй эти параметры увеличитьapi.c
Code:
// Big enough for largest API request
// though a PC with 100s of PGAs may exceed the size ...
// data is truncated at the end of the last record that fits
// but still closed correctly for JSON
// Current code assumes it can socket send this size + JSON_CLOSE + JSON_END
#define SOCKBUFSIZ 65432
// BUFSIZ varies on Windows and Linux
#define TMPBUFSIZ 8192
Ограничил stats, чтобы только по первым 90 чипам инфу давал - все нормально. Больше - fail. Где-то размера буфера не хватает. Может, ограничить длину строк (типа не "match_work_count", а ""m_wrk_cnt")? не в этом дело.
Необходимость высылать даже опоздавший с точки зрения пула блок - есть, она, как и другие методы, должна способствовать уменьшению орфанов.
Вы ответьте лучше на один вопрос. Откуда на вашей ноде появился новый блок?
Орфан - это когда вы отправляете созданный блок своим соседям, часть из которых еще не успела получить информацию (как и вы) о новом блоке.
Как правило таких нод очень небольшое количество, если специально не собирать самые тормозные (а этого точно не стоит делать).
Когда вы уже приняли блок, это означает что кто-то из ваших соседей уже получил этот новый блок.
На все предлагаемые манипуляции у вас несколько секунд. Чтобы гарантировано поддержать свою цепочку вам нужно 51% мощностей.
В теории это возможно, на практике маловероятно, затратно (как минимум bitcoind нужно свой пилить) и не гарантированно.
needbmw че-то ты перемудрил с редактирорванием апи, при запросе stats майнер вываливается segmentation fault (остальные запросы - норм). Сейчас посмотрю код, может найдется ошибка.
ed.
Блин, ниче не понимаю, ты же просто название переменных сменил и содержимое строк. Должно все также работать.
Может из-за того что теперь запускаю на МБ-устр-ве в 120чипов (против 72 ранее).
ed.
Блин, ниче не понимаю, ты же просто название переменных сменил и содержимое строк. Должно все также работать.
Может из-за того что теперь запускаю на МБ-устр-ве в 120чипов (против 72 ранее). Jump to: