Может прогнать клоки по всем чипам (например от 51 до 55), по 10 минут это около часа, залогировать полезные значения (Хэши-HW) для каждого клока,каждого чипа. Всё взвесить (определить наилучший клок для чипа), сбросить в файлик с настройками и выставлять соответствующий клок на соответствующем чипе.
у них питание групповое, когда подойдешь к пределу DC/DC (а разгон это всегда работа питалова на пределе) ничего не понятно будет.. один чип начнет чуть больше жрать и у всех остальных в группе хешрейт тут же провалится. alpet, какие результаты дала твоя автоподстройка? есть прирост по сравнению со статикой? |
|
|
|
needbmwНа каком периоде ты оцениваешь изменение хэш-рейта? Мне вот представляется, что 20-50% HW по отношению к Accepted это не есть хорошо. К тому-же при массовом разгоне, некоторые чипы порой просто вырубаются - по ним 0Гх в SHORT stat, и количество ошибок быстро растет. Кстати выложил свою модификацию driver-bitfury.c с автоподбором, может какие-то кусочки используешь ). я смотрю с усреднением 10 минут. про 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 чипах в цепочке теперь не вылетает при запросе статистики (длиннее цепочки нет, проверьте на более длинных) |
|
|
|
|
alpet, я пока подбираю вручную и вот что получается.
есть чипы, которые недодают хэшрейт, при снижении клока до 52-53 бит хэшрейт повышается, hw снижаются (все логично).
но встречаются и другие чипы, у которых при повышении клока повышаются hw, но при этом и хэшрейт у них растет прилично! (я наблюдал у отдельных экземпляров даже 3.2 на последней сборке, в ней надеюсь не попугаи а гигахэши все же).
получается, если будем нормировать hw - задушим и стахановцев...
|
|
|
|
Остается один филосовский вопрос - откуда берутся эти искажения на осцилограме.
нет, философский вопрос это накой тебе сдался этот Atheros, когда в природе (а в Москве в наличии в розницу) есть распи и на ней все работает  а если серьезно, по опыту скажу что выправление endianess это будет знатный геморрой в данном случае |
|
|
|
Очень надеюсь что накосячил  Потому как код проще править. Дайте уже лог от spi_test - как раз это и хочу проверить. вот так вышло: Sent 317 bytes:
0060e104 ffffffff 00f0ffff 00e070e0 e0000000 00000071 71e00000 00000020 4071e000 00000000 006071e0 e0000000 5683c070 70e0c79a 9a568380 2070e0c7 00000000 004070e0 e0000000 00006070 01e30000 20020200 20686010 027cbca0 402000f0 0010efc0 00000000 00000000 00000000 ffffffff 01000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00004001 000014e7 00000000 00000000 ff000000 00ffffff 00010000 00000000 00000000 e7000000 00000019 00000100 00000000 00000000 00000000 00000000 00000000 80000000 30f20000 e7b47100 a31d460d e72365b8 0a8faf97 58d67e0c c3211751 83c33f7e 8b1a8542 58d67e71 12124e51 0fddd9f6 93fee0f2 e7b47148 9b9e3d0d 024c69aa 0f79219c d0eded02 f50cf251 943058cc 0
Got:
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 fc6b0ce0 09f6166a 00000000
wait for job switching...
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 f2eb0ee0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 fa791ae0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 f68834e0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 7e7506e0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 714c0ee0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 b9351fe0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 b56420e0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 3dad33e0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 33221ce0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 db8334e0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 d79c15e0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 5f4d10e0 09f6166a 00000000
Sent 80 bytes:
0030f204 0de7b471 b8a31d46 97e72365 0c0a8faf 5158d67e 7ec32117 4283c33f 718b1a85 5158d67e f612124e f20fddd9 4893fee0 0de7b471 aa9b9e3d 9c024c69 020f7921 51d0eded ccf50cf2 d0943058
Got:
fd80f865 c819f1f1 fd80f865 c819f1f1 fd80f865 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 c819f1f1 500230e0 09f6166a ffffffff
JOB 1 MS0 b0e72d8e NONCE f0c4e61f RESULTS
oldbuf[]=00000000 newbuf[]=fd80f865
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=fd80f865
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=fd80f865
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=c819f1f1
oldbuf[]=00000000 newbuf[]=500230e0
oldbuf[]=00000000 newbuf[]=09f6166a
|
|
|
|
портировал cgminer на Atheros стоящий в роутере TP-Link, выведя из него SPI
Atheros это MIPS, он вроде бы big endian, распи это little endian ARM. Точно нигде с endianess не накосячил? |
|
|
|
Ограничил stats, чтобы только по первым 90 чипам инфу давал - все нормально. Больше - fail. Где-то размера буфера не хватает. Может, ограничить длину строк (типа не "match_work_count", а ""m_wrk_cnt")? не в этом дело.
попробуй эти параметры увеличить api.c // 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 |
|
|
|
|
про p2pool я как-то не подумал (сам не пользуюсь), тогда пока вопрос с реджектами оставим.
их кстати можно сам cgminer попросить не отправлять, а не душить в драйвере насильно...
|
|
|
|
Ну эти только распределением заданий и низкими задержками в сети лечить, один фиг 0 не будет До 10Gh вполне реально получить 0.05%, на больших скоростях уже ближе к 0.5% Будущие монстры видимо должны будут поддерживать несколько соединений, чтобы раздавать задания раздельно по платам, либо забить на высокий процент stale. не-не, все не так просто. у чипа два буфера (job0,1), один считается, из другого параллельно предыдущий результат читается. так вот когда новый блок найден сетью, текущий считаемый буфер сразу становится недействительным, но прочитан он будет только на следующей итерации, и потом отправлен пулу как ни в чем не бывало, и вот они стейлы. нужно просто заблокировать эту отправку, станет чуть меньше нагрузка на майнер, на сеть и на пул, и счетчик реджектов не будет таким раздражающим глаз. вечером посмотрю что с этим можно сделать. |
|
|
|
А под линукс её можно собрать?  Винда не везде есть и не у всех лучше бы вообще на php переписать и в распи залить |
|
|
|
А какой процент? И причина режекта?
от 0,8 до 3% в зависимости от сложности шар (самый высокий процент на итзоде), стейлы причина в принципе понятна, они выползают из предыдущего буфера чипа на границе блоков |
|
|
|
- вернул на место счетчик HW ошибок (хотя меня все еще терзают сомнения а ошибки ли это)
Насколько я помню, когда Битфури и ко только-только тестили чипы, они собирали и анализировали raw вывод чипа, потом из него выцепили что-то осмысленное. Это меня удивило, разве вывод не должен быть предсказуемым? Короче бредовая идея, но может быть эти strange данные можно трансмутировать во что-то полезное? (и получить 5гх strange (а по сути HW error) это когда nonce проверку не пошел, при нормальном питании их менее 5% (на моих платах), так что удвоить за их счет скорость по-любому не получится а вот то, что может проверяем мы их не совсем правильно, вот откуда сомнения.. ProtonEvil, да там изменения косметические, названия чуть поменялись, насчет смержить смотри ЛС. обязательно сделай проверку чтобы вводимые клоки были в безопасном диапазоне (типа 48-56), а то можно и чипы спалить случайно! iliyoleg, на понижение не пойду  посмотрел контрольные платы, отработaвшие ночь. несмотря на отсутствие duplicate-шар, реджектов сильно меньше не стало, это я погорячился. виноваты все же видимо буферы чипа, надо подумать как снизить реджекты, а то "неаккуратненько" получается (анекдот есть такой ) |
|
|
|
Более-менее разобрался со статистикой. а константу-то похоже подгоняли под хэшрейт, отображаемый на пуле, другого объяснения я не нахожу  Changelog:- абсолютно честная константа 4.294967296 при пересчете шары->Гх/c - гигахэши в шапке cgminer-a теперь неплохо совпадают с гигахэшами по API (хотя считаются внутри по-разному) и совпадают со средним на элигиусе - полностью избавился от duplicate-шар, стало в разы меньше реджектов- вернул на место счетчик HW ошибок (хотя меня все еще терзают сомнения а ошибки ли это) - изменились некоторые имена параметров в API на более вменяемые ( ProtonEvil, придется это учесть в твоей проге). |
|
|
|
Это битфури где то писал (в ветке про предзаказ от метабанка), что одна шара это 4.84387Gh/s по этому чип на 3Gh/s должен давать примерно 0.619 шары в секунду
вот мне интересно откуда эти цифры? итого сейчас имеем на контрольной плате три разных хэшрейта: 54.45Гх/c среднее(avg) в шапке cgminer 52.73Гх/c трехчасовое среднее на элигиусе ~50.5Гх/c среднее по API (оно вообще говоря не чисто среднее за все время, а за последние 10 минут, но болтается в диапазоне 49-51) что-то здесь не так...  |
|
|
|
Стоп, если нельзя на ходу, как тогда АПЧ мутить?
я имел ввиду для чистоты эксперимента по изучению влияния клок-битов на суммарный хэшрейт перезапустить майнер после изменения не помешает. принципиально клок на ходу менять можно (chainminer же меняет). |
|
|
|
два блока подряд, в "раундах" нету их мой сложностью 180М UPD появились... фух ледокол молодец |
|
|
|
Через строку (кстати, не знал, что так можно) - не вариант - задолбаешься перезапускать.
пока так нельзя, но можно и нужно реализовать (и будет куда проще, чем через АПИ). насчет перезапускать, а я вот совсем не уверен что можно вот так просто на ходу клок-биты менять и все будет пучком. для чистоты эксперимента перезапускать всяко придется... |
|
|
|
Оригинальная формула выглядит примерно так (дает скорость в MHash/s):
speed = (shares * 4294967296) / (time_sec * 1000000)
Где первая константа это 2^32 - nonce range
Т.к. нахождение шары процесс случайный, скорость все время плавает.
Чем меньше промежуток расчета, тем выше погрешность. Для 5 минут до 20%.
Если "оптимизировать" вычисления и брать небольшой промежуток, то точность падает, что "компенсируют" задиранием величины константы.
ну, с оригинальной формулой я хорошо знаком, и если бы увидел 4.294967 в коде, совсем не удивился бы. а вот остальное объяснение просто в голове не укладывается, релятивистские сдвиги какие-то, однако хотелось бы услышать комментарий Легкодымова |
|
|
|
Тоже думаю в том направлении, уже начал код апи ковырять, может прикручу подстройку частот чипов и spi.
может лучше все это через параметры командной строки передавать? допустим все чипы имеют клок по умолчанию 54 (стандарт де-факто), а через параметр задавать индивидуальные настройки, например --bitfury-clockbits="4:53,7:55,12:53" и самое главное - нам нужно определить стратегию автоподстройки частоты. реализовать саму автоподстройку - не проблема, это за вечер сделать можно. а вот разобраться, кого и куда нужно подстраивать, непросто. needbmw, понимаю, у тебя время мало, так что заканчивай быстрее со своими авалоноклонами, давно пора в будущее смотреть, мутить с битфури-чипами.
с авалоновскими чипами процесс разработки давно завершен, а тестовый битфури-блейд молотит сейчас на элигиусе, ссылка парой сообщений выше |
|
|
|
Нормально ли то, что файл кронтаба сохраняется по такому пути (во временной папке)? Или его нужно перенести куда-нибудь (например в var/spool/cron/crontabs)? Правильно ли я всё сделал?
файл кладешь в /etc/crontab потом service cron reload |
|
|
|
|
Show Posts
