мои форки cgminer и bfgminer для bitfury ASIC

[alexxy]

Первым делом перенести бы все эти изменения на BFGMiner... А то cgminer как-то кривоват сам по себе, например соединения закрывать "забывает".

Часть изменений уже там в бранче littlefury

[1714770979]

1714770979

[1714770979]

1714770979

[1714770979]

1714770979

[1714770979]

1714770979

[1714770979]

1714770979

[needbmw]

мои измерения скорости через API (к сожалению не помню где какой вольтаж, но примерно все платы у меня работают в диапазоне 0.88-0.92В):

четырехслойная плата, одна цепочка в 20 чипов:            
[ghash_total] => 50.424687
[ghash_avg] => 2.521234

двухслойная плата, одна цепочка 100 чипов:
[ghash_total] => 225.175370
[ghash_avg] => 2.251754

двухслойная плата, одна цепочка 40 чипов:
[ghash_total] => 89.369402
[ghash_avg] => 2.234235

питание везде не менее 3А на чип, на более слабом питании показатели еще хуже.
итзод в принципе показывает примерно эти скорости воркеров, но из-за задранной сложности показания на нем скачут.
сейчас попробую контрольную плату перекинуть на элигиус, посмотрим что он насчитает

http://eligius.st/~wizkid057/newstats/userstats.php/18R28t8nUCK5iwV4YBoHH5WaNZUoVvJRyg
понаблюдаем...

[alpet]

Сделал небольшие модификации исходников для своего устройства на 15 плат. Пока это пробная программная подгонка, исходя из небольшого по длительности теста.
Пока вместо файла с настройками, получается тупая копипаста для отличившихся чипов:

Code:

        libbitfury_setChipClk(devices, chip_n, 5, 0, 53);
        libbitfury_setChipClk(devices, chip_n, 5, 1, 53);
        libbitfury_setChipClk(devices, chip_n, 5, 5, 53);

Подбирал по счетчику strange_counter, там где малые значения накапливаются для чипа - ставил 53, где большие соответственно 55.
Вот мне кстати говорили в другой ветке, что радиаторы на чипах не нужны. А тут совпадение или нет, а 8 плата с радиаторами просто самая лучшая по показателям (5 чипов хороших).

[needbmw]

legkodymov, подскажи откуда эти константы взялись? как вычислял их?

Code:

double shares_to_ghashes(int shares, int seconds) {
	return (double)shares / (double)seconds * 4.84387;  //orig: 4.77628
}

[needbmw]

Подбирал по счетчику strange_counter, там где малые значения накапливаются для чипа - ставил 53, где большие соответственно 55.

а почему именно так? я бы наоборот поступил - если чип генерирует много ошибок, снижал бы частоту, если мало - повышал бы её

[ProtonEvil]

выложи программку, красиво получилось 

положил здесь: https://bitcointalk.org/index.php?topic=287147.msg3115503#msg3115503

над регулировкой клока через апи надо подумать, хорошая идея кстати.

Тоже думаю в том направлении, уже начал код апи ковырять, может прикручу подстройку частот чипов и spi.
needbmw, понимаю, у тебя время мало, так что заканчивай быстрее со своими авалоноклонами, давно пора в будущее смотреть, мутить с битфури-чипами.

[needbmw]

Тоже думаю в том направлении, уже начал код апи ковырять, может прикручу подстройку частот чипов и spi.

может лучше все это через параметры командной строки передавать? допустим все чипы имеют клок по умолчанию 54 (стандарт де-факто), а через параметр задавать индивидуальные настройки, например

--bitfury-clockbits="4:53,7:55,12:53"

и самое главное - нам нужно определить стратегию автоподстройки частоты.
реализовать саму автоподстройку - не проблема, это за вечер сделать можно. а вот разобраться, кого и куда нужно подстраивать, непросто.

needbmw, понимаю, у тебя время мало, так что заканчивай быстрее со своими авалоноклонами, давно пора в будущее смотреть, мутить с битфури-чипами.

с авалоновскими чипами процесс разработки давно завершен, а тестовый битфури-блейд молотит сейчас на элигиусе, ссылка парой сообщений выше

[dbitcoin]

legkodymov, подскажи откуда эти константы взялись? как вычислял их?

Code:

double shares_to_ghashes(int shares, int seconds) {
	return (double)shares / (double)seconds * 4.84387;  //orig: 4.77628
}

Оригинальная формула выглядит примерно так (дает скорость в MHash/s):
speed = (shares * 4294967296) / (time_sec * 1000000)

Где первая константа это 2^32  -  nonce range
Т.к. нахождение шары процесс случайный, скорость все время плавает.
Чем меньше промежуток расчета, тем выше погрешность.  Для 5 минут до 20%.
Если "оптимизировать" вычисления и брать небольшой промежуток, то точность падает, что "компенсируют" задиранием величины константы.

[ProtonEvil]

реализовать саму автоподстройку - не проблема, это за вечер сделать можно. а вот разобраться, кого и куда нужно подстраивать, непросто.

Вот! Золотые слова Понятно, что вручную много не настроишь (мягко говоря), я хочу вручную потыкать, понять поведение, а уже исходя из этого составить алгоритм АПЧ.
Через строку (кстати, не знал, что так можно) - не вариант - задолбаешься перезапускать.

с авалоновскими чипами процесс разработки давно завершен, а тестовый битфури-блейд молотит сейчас на элигиусе, ссылка парой сообщений выше

Ага, увидел. Короче, нам с метобанковскими двуслойками взрыв хешрейта не светит
Но, все равно, мне кажется четырехслойки не стоили твоих мытарств с китайцами.
Вот, cscape, какую-то ересь четырехслойную замутил за 15 минут. Эту ересь быстро собрали и запустили. Тут главное скорость, а не качество, ИМХО.

[needbmw]

Оригинальная формула выглядит примерно так (дает скорость в MHash/s):
speed = (shares * 4294967296) / (time_sec * 1000000)

Где первая константа это 2^32  -  nonce range
Т.к. нахождение шары процесс случайный, скорость все время плавает.
Чем меньше промежуток расчета, тем выше погрешность.  Для 5 минут до 20%.
Если "оптимизировать" вычисления и брать небольшой промежуток, то точность падает, что "компенсируют" задиранием величины константы.

ну, с оригинальной формулой я хорошо знаком, и если бы увидел 4.294967 в коде, совсем не удивился бы.
а вот остальное объяснение просто в голове не укладывается, релятивистские сдвиги какие-то, однако 
хотелось бы услышать комментарий Легкодымова

[needbmw]

Через строку (кстати, не знал, что так можно) - не вариант - задолбаешься перезапускать.

пока так нельзя, но можно и нужно реализовать (и будет куда проще, чем через АПИ).
насчет перезапускать, а я вот совсем не уверен что можно вот так просто на ходу клок-биты менять и все будет пучком.
для чистоты эксперимента перезапускать всяко придется...

[alpet]

а почему именно так? я бы наоборот поступил - если чип генерирует много ошибок, снижал бы частоту, если мало - повышал бы её

Все перепутал потому что...
У меня кстати эта сборка недолго работает, через некоторое время хэшрейт по всем чипам в ноль сбрасывается.

[rPman]

Во время перезапуска чипам посылается последовательность реиннициализации. Логично вместо перезапуска всего майнера дождаться нового задания и перед ним послать конкретному чипу команду реиннициализации с новыми параметрами.

[ProtonEvil]

насчет перезапускать, а я вот совсем не уверен что можно вот так просто на ходу клок-биты менять и все будет пучком.

Стоп, если нельзя на ходу, как тогда АПЧ мутить? Составлять карту клоков во время работы, а потом загружать при старте?
alpet уже начал регулировать на ходу - может остановить его, пока не поздно. 

[ProtonEvil]

Логично вместо перезапуска всего майнера дождаться нового задания и перед ним послать конкретному чипу команду реиннициализации с новыми параметрами.

Все становится сложнее...

[needbmw]

Стоп, если нельзя на ходу, как тогда АПЧ мутить?

я имел ввиду для чистоты эксперимента по изучению влияния клок-битов на суммарный хэшрейт перезапустить майнер после изменения не помешает.
принципиально клок на ходу менять можно (chainminer же меняет).

[alexxy]

legkodymov, подскажи откуда эти константы взялись? как вычислял их?

Code:

double shares_to_ghashes(int shares, int seconds) {
	return (double)shares / (double)seconds * 4.84387;  //orig: 4.77628
}

Это битфури где то писал (в ветке про предзаказ от метабанка), что одна шара это 4.84387Gh/s по этому чип на 3Gh/s должен давать примерно 0.619 шары в секунду

[needbmw]

Это битфури где то писал (в ветке про предзаказ от метабанка), что одна шара это 4.84387Gh/s по этому чип на 3Gh/s должен давать примерно 0.619 шары в секунду

вот мне интересно откуда эти цифры?

итого сейчас имеем на контрольной плате три разных хэшрейта:

54.45Гх/c среднее(avg) в шапке cgminer
52.73Гх/c трехчасовое среднее на элигиусе
~50.5Гх/c среднее по API (оно вообще говоря не чисто среднее за все время, а за последние 10 минут, но болтается в диапазоне 49-51)

что-то здесь не так... 

[alexxy]

вот мне интересно откуда эти цифры?

итого сейчас имеем на контрольной плате три разных хэшрейта:

54.45Гх/c среднее(avg) в шапке cgminer
52.73Гх/c трехчасовое среднее на элигиусе
~50.5Гх/c среднее по API (оно вообще говоря не чисто среднее за все время, а за последние 10 минут, но болтается в диапазоне 49-51)

что-то здесь не так... 

Кстати по поводу форка, вроде как у luke-jr в littlefury бранче реализован контроль ошибок в bfgminer для чипов, может вам стоит скооперироваться?

[needbmw]

Более-менее разобрался со статистикой.
_{а константу-то похоже подгоняли под хэшрейт, отображаемый на пуле, другого объяснения я не нахожу}  

Changelog:

- абсолютно честная константа 4.294967296 при пересчете шары->Гх/c
- гигахэши в шапке cgminer-a теперь неплохо совпадают с гигахэшами по API (хотя считаются внутри по-разному) и совпадают со средним на элигиусе
- полностью избавился от duplicate-шар, стало в разы меньше реджектов
- вернул на место счетчик HW ошибок (хотя меня все еще терзают сомнения а ошибки ли это)
- изменились некоторые имена параметров в API на более вменяемые (ProtonEvil, придется это учесть в твоей проге).