Не знаю кому как, а меня прошедший 2017 год шокировал стремительным взлетом биткоина. Сейчас, конечно, ажиотаж уже ушел, а в 17-м году про криптовалюты говорили и писали все кому не лень.
Я видел, что люди пытаются зарабатывать на криптовалютах. Кто как умеет. Кто-то на все сбережения скупал видеокарты и начинал самостоятельно майнить в гараже. Кто-то вкладывался в облачный майнинг. Кто-то пытается организовать свой пул. Кто-то запустил в производство шоколадные биткоины, а кто-то выпускает минеральную воду:
Я тоже стал изучать, что же такое эти самые биткоины. Когда-то я даже начал свое собственное иследование алгоритма SHA256 и написал статью здесь на хабре "Можно ли вычислять биткоины быстрее, проще или легче?". Мои исследования алгоритмов хеширования до сих пор продолжаются и еще и близко не завершены… Может быть когда нибудь напишу про это отдельную статью. А сейчас пока вот это..
Я попробовал запустить bitcoin майнер в FPGA. Я понимал, что время уже ушло, но хотелось все же прикоснуться к технологии. Уже в конце прошлого года я вдруг почему-то вспомнил, что у меня совершенно без дела лежит плата Terasic DE10-Standard с ПЛИС Intel Cyclone V 5CSXFC6D6F31C6 — это тот чип, который со встроенным процессором ARM. Я подумал, что было бы интересно запустить какой нибудь альткоин майнер в этой плате. А что? Инвестировать в оборудование мне уже не надо, оно и так есть. Главное, чтобы плата зарабатывала больше, чем потребляет энергии.
Поиск подходящего альткоина был весьма прост. Я искал готовые проекты для FPGA, которые я смогу адаптировать под свою плату. Таковых оказалось не очень много. На самом деле как я понимаю во всем мире есть всего несколько человек, которые делали FPGA проекты и главное публиковали их в открытом доступе, например, на github.
Таким образом, я взял проект github.com/kramble/FPGA-Blakecoin-Miner и адаптировал его под имеющуюся у меня плату Марсоход3, а так же адаптировал этот проект для DE10-Standard.
Собственно о том, как я адаптировал проект для платы Марсоход3 написано здесь. Для Cyclone V в принципе все то же самое — только ревизия проекта квартуса blake_cv, мои исходники вот.
К моему сожалению в имеющийся у меня Cyclone V помещается только три хэш функции blake.
Чуть-чуть не хватает емкости ПЛИС до четырех хэшеров. Я запускаю проект на частоте 120МГц и за один такт рабочей частоты вычисляется один хэш blake. Значит производительность моего проекта 120*3=360MH/sec. Не очень много честно говоря, однако, как я уже сказал, плата у меня уже была, и возвращаеть ее стоимость мне не нужно… Тут еще Quartus говорит, что Fmax=150MHz. Можно попытаться поднять частоту, но боюсь придется ставить кулер, будет гудеть — ну не на столько мне нужны эти крипты, чтоб еще гул в комнате слушать.
Общая задумка проекта такая: плата имеет микросхему у которой есть и ПЛИС и Dual-ARM:
Когда плата стартует, то из U-BOOT первым делом загружается ПЛИС, затем стартует Linux и в нем программа майнинга cgminer. Я сперва думал, что я смогу устроить виртуальный канал связи между ARM и FPGA, и это на самом деле возможно, но так не получилось. Дело в том, что программа майнера cgminer работает с аппаратными майнерами через USB и использует библиотеку libusb. То есть мне проще подключить ПЛИС к Linux системе через преобразователь USB-COM на FTDI, чем городить городушку соединяя ПЛИС на шину ARMа. Я таким уже как-то занимался и это было не очень просто.
Сейчас мой «майнер» выглядит вот так (на Cyclone V поставил радиатор на термопасте, а то сильно греется):
Сказать по правде основные проблемы у меня как раз возникли не с FPGA проектом, а с cgminer.
Проблемы следующие:
1) Какой cgminer брать за основу своей разработки? И связанный с этим вопрос «Куда подключаться, чтобы начать майнить?». А какая связь между этими вопросами? Казалось бы, где тут проблема — бери самый свежий cgminer, какой найдешь. Но позвольте: на github есть 98 форков программы cgminer. Все они чем-то отличаются, какой есть хороший, а какой плохой, какой есть вообще хотя бы рабочий? Вот вам и опенсоурс. Каждый автор чего-то там себе добавлял и исправлял, или ломал… или делал свою монету. Разобраться не просто. Нашел для себя сайт, где на одной странице есть ссылка и на github проект и на github проект для FPGA. То есть эти два проекта видимо как-то могут и должны пересекаться.
2) Поскольку я взял за основу FPGA проект от автора kramble, то на самом деле, конечно, логично было бы взять его патчи, которые он приложил к своему проекту. Но и тут не без проблем. У него есть патчи к программе cgminer-3.1.1 и cgminer-3.4.3. Я решил, что лучше брать ту, что новее 3.4.3, но только потерял с ней время. Похоже автор начал адаптировать для этой версии, но что-то там не довел до конца и эта версия совсем сырая. Пришлось брать 3.1.1 а это кажется вообще старючая версия.
3) Авторы изменяющие программу cgminer в своих форках для своих альткоинов не следят за правильностью комментариев и именованием функций в коде. Зачастую в коде тут и там встречается слово bitcoin, а сам этот форк cgminer-а уже кажется не может считать для биткоина, а может только в альткоин.
4) Тесты. ГДЕ ТЕСТЫ? Я чего-то не понимаю, как можно делать сложный продукт без тестов? Я их не нашел.
Сказать по правде даже начинать что-то делать было не просто. Представьте себе, что нужно запустить некоторый проект в FPGA, но не очень понятно, что он должен делать, как получать данные, какие данные и в каком виде нужно выдавать результат. К этому FPGA проекту должна прилагаться некоторая программа, которую не известно точно где взять, но она должна обнаружить плату майнера, что-то туда посылать (неизвестно что) и что-то из нее получать. В каком формате, какими блоками, как часто — ничего не известно.
На самом деле, изучая патчи cgminer от kramble я примерно представляю себе как оно должно работать.
В файле usbutils.c прописаны устройства, которые могут рассматриваться как аппаратные внешние майнеры на шине USB:
static struct usb_find_devices find_dev[] = {
#ifdef USE_BFLSC
{
.drv = DRV_BFLSC,
.name = "BAS",
.ident = IDENT_BAS,
.idVendor = IDVENDOR_FTDI,
.idProduct = 0x6014,
//.iManufacturer = "Butterfly Labs",
.iProduct = "BitFORCE SHA256 SC",
.kernel = 0,
.config = 1,
.interface = 0,
.timeout = BFLSC_TIMEOUT_MS,
.latency = LATENCY_STD,
.epcount = ARRAY_SIZE(bas_eps),
.eps = bas_eps },
#endif
...
{
.drv = DRV_ICARUS,
.name = "BLT",
.ident = IDENT_BLT,
.idVendor = IDVENDOR_FTDI,
.idProduct = 0x6010,
//.iProduct = "Dual RS232-HS",
.iProduct = "USB <-> Serial Cable",
.kernel = 0,
.config = 1,
.interface = 1,
.timeout = ICARUS_TIMEOUT_MS,
.latency = LATENCY_STD,
.epcount = ARRAY_SIZE(ftdi2232h_eps),
.eps = ftdi2232h_eps },
Я в эту структуру добавил описатель своего USB-to-COM преобразователя FTDI-2232H. Теперь, если cgminer обнаружит устройство с VendorId/DeviceId = 0x0403:0x6010, то он попробует работать с этим устройством, как с платой Icarus, хоть она таковой и не является.
Дальше смотрим файл driver-icarus.c и тут есть функция icarus_detect_one:
static bool icarus_detect_one(struct libusb_device *dev, struct usb_find_devices *found)
{
int this_option_offset = ++option_offset;
struct ICARUS_INFO *info;
struct timeval tv_start, tv_finish;
/* Blakecoin detection hash
N.B. golden_ob MUST take less time to calculate than the timeout set in icarus_open()
0000007002685447273026edebf62cf5e17454f35cc7b1f2da57caeb008cf4fb00000000dad683f2975c7e00a8088275099c69a3c589916aaa9c7c2501d136c1bf78422d5256fbaa1c01d9d1b48b4600000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
{ midstate, data } = { 256'h553bf521cf6f816d21b2e3c660f29469f8b6ae935291176ef5dda6fe442ca6e4, 96'hd1d9011caafb56522d4278bf };
*/
const char golden_ob[] =
// "553bf521cf6f816d21b2e3c660f29469"
// "f8b6ae935291176ef5dda6fe442ca6e4"
// "00000000000000000000000000000000"
// "00000000d1d9011caafb56522d4278bf";
//-----------
"a8c369073d7dc0a63168f5fcf0246e4f"
"eb916bda12787ad1607d2303186ed8f1"
"00000000000000000000000000000000"
"0142b9a0e7b4001cf8b35852a3accab0";
const char golden_nonce[] = "0142b9b1"; //"000187a2";
const uint32_t golden_nonce_val = 0x0142b9b1; //0x000187a2;
unsigned char ob_bin[64];
unsigned char nonce_bin[ICARUS_READ_SIZE];
char *nonce_hex;
int baud, uninitialised_var(work_division), uninitialised_var(fpga_count);
struct cgpu_info *icarus;
int ret, err, amount, tries;
bool ok;
char tmpbuf[256]; //lancelot52
unsigned char* wr_buf = ob_bin;
int bufLen = sizeof(ob_bin);
icarus = usb_alloc_cgpu(&icarus_drv, 1);
if (!usb_init(icarus, dev, found))
goto shin;
usb_buffer_enable(icarus);
get_options(this_option_offset, icarus, &baud, &work_division, &fpga_count);
hex2bin(ob_bin, golden_ob, sizeof(ob_bin));
tries = 2;
ok = false;
while (!ok && tries-- > 0) {
icarus_initialise(icarus, baud);
err = usb_write_ica(icarus, (char *)wr_buf, bufLen, &amount, C_SENDTESTWORK);
if (err != LIBUSB_SUCCESS || amount != bufLen)
continue;
memset(nonce_bin, 0, sizeof(nonce_bin));
ret = icarus_get_nonce(icarus, nonce_bin, &tv_start, &tv_finish, NULL, 500);Смысл такой. Программа передает плате заведомо известное задание на поиск хэша, причем в задании сказано с какого нонсе начинать вычисление и это нонсе немного меньше настоящего GOLDEN nonce. Таким образом, плата начнет считать с указанного места и буквально сразу в считанные доли секунды наткнется на GOLDEN nonce и вернет его. Программа тут же получит этот результат, сравнит его с правильным ответом и сразу становится понятно — это действительно тот HW майнер с которым можно работать или нет.
И вот тут была ужасная проблема — в проекте есть патчи на языке C, есть тестовая программа на питоне и тестбенч для FPGA.
В патчах на C тестовые данные выглядят вот так:
1) патч для cgminer-3.1.1
const char golden_ob[] =
"553bf521cf6f816d21b2e3c660f29469"
"f8b6ae935291176ef5dda6fe442ca6e4"
"00000000000000000000000000000000"
"00000000d1d9011caafb56522d4278bf";
const char golden_nonce[] = "00468bb4";
const uint32_t golden_nonce_val = 0x00468bb4;1) патч для cgminer-3.4.3
const char golden_ob[] =
"553bf521cf6f816d21b2e3c660f29469"
"f8b6ae935291176ef5dda6fe442ca6e4"
"00000000000000000000000000000000"
"00000000d1d9011caafb56522d4278bf";
const char golden_nonce[] = "000187a2";
const uint32_t golden_nonce_val = 0x000187a2;И что тут правильно, а что нет? Исходные данные одинаковые, а golden nonce объявлен разным!!! Парадокс… (заранее скажу, что в патче для cgminer-3.4.3 ошибка — нонсе 0x000187a2 не верный, а сколько времени я на это потратил..)
В проекте есть тестовая программа на питоне, которая читает текстовый файл, извлекает из него данные и передает в плату через последовательный порт… Там тестовые данные вот такие:
0000007057711b0d70d8682bd9eace78d4d1b42f82da7d934fac0db4001124d600000000cfb48fb35e8c6798b32e0f08f1dc3b6819faf768e1b23cc4226b944113334cc45255cc1f1c085340967d6c0e000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
0000007057711b0d70d8682bd9eace78d4d1b42f82da7d934fac0db4001124d6000000008fa40da64f312f0fa4ad43e2075558faf4e6d910020709bb1f79d0fe94e0416f5255cc521c085340df6b6e01000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
0000007095696e4529ae6568e4b2a0057a18e82ccf8d370bf87e358900f8ab5000000000253c6078c7245036a36c8e25fb2c1f99c938aeb8fac0be157c3b2fe34da2fa0952587a471c00fa391d2e5b02000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
000000704445e0446fcf2a84c47ce7305722c76507ba74796eaf39fe0007d44d00000000cac961f63513134a82713b172f45c9b5e5eea25d63e27851fac443081f453de1525886fe1c01741184a5c70e000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
00000070a3ac7627ca52f2b9d9a5607ac8212674e50eb8c6fb1219c80061ccd500000000ed5222b4f77e0d1b434e1e1c70608bc5d8cd9d363a59cbeb890f6cd433a6bd8d5258a0141c00b4e770777200000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
000000706c90b789e84044d5be8b2fac01fafe3933ca3735269671e90043f8d900000000d74578c643ab8e267ab58bf117d61bb71a04960a10af9a649c0060cdb0caaca35258b3f81c00b4e7b1b94201000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
00000070171d2644781cccf873ce3b6e54967afda244c47fc963bb240141b4ad00000000d56c4fbdc326e8f672834c8dbca53a087147fe0996d0c3a908a860e3db0589665258da3d1c016a2a14603a0a000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
00000070d03c78cb0bb0b41a5a2c6ce75402e5be8a705a823928a5640011110400000000028fb80785a6310685f66a4e81e8f38800ea389df7f16cf2ffad16bb98e0c4855258dda01c016a2ae026d404000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
0000007091a7eef446c4cb686aff8908ab5539d03a9ab2e975b9fe5700ed4ca9000000000f83bb385440decc66c10c0657fcd05f94c0bc844ebc744bba25b5bc2a7a557b5258e27c1c016a2a6ce1900a000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
00000070856bd0a3fda5dac9ede45137e0c5648d82e64fbe72477f5300e96aec0000000026ca273dbbd919bdd13ba1fcac2106e1f63b70f1f5f5f068dd1da94491ed0aa45258e51b1c017a7644697709000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000Ну то есть совершенно другие! Потом я уже понял, что это не те даннае, что посылаются в плату, из этих только извлекаются данные, специальным образом конвертируются в задание и отсылаются в плату.
Но все равно, среди этих тестовых данных для программы на питоне НЕТ задания похожего на то, которое описано в программе на C!!!
Ну хорошо, тогда смотрю тестовую программу-тестбенч на verilog:
blakeminer #(.comm_clk_frequency(comm_clk_frequency)) uut
(clk, RxD, TxD, led, extminer_rxd, extminer_txd, dip, TMP_SCL, TMP_SDA, TMP_ALERT);
// TEST DATA (diff=1) NB target, nonce, data, midstate (shifted from the msb/left end) - GENESIS BLOCK
reg [415:0] data = 416'h000007ffffbd9207ffff001e11f35052d554469e3171e6831d493f45254964259bc31bade1b5bb1ae3c327bc54073d19f0ea633b;
// ALSO test starting at -1 and -2 nonce to check for timing issues
// reg [415:0] data = 416'h000007ffffbd9206ffff001e11f35052d554469e3171e6831d493f45254964259bc31bade1b5bb1ae3c327bc54073d19f0ea633b;
// reg [415:0] data = 416'h000007ffffbd9205ffff001e11f35052d554469e3171e6831d493f45254964259bc31bade1b5bb1ae3c327bc54073d19f0ea633b;
reg serial_send = 0;
wire serial_busy;
reg [31:0] data_32 = 0;
reg [31:0] start_cycle = 0;
serial_transmit #(.comm_clk_frequency(comm_clk_frequency), .baud_rate(baud_rate)) sertx (.clk(clk), .TxD(RxD), .send(serial_send), .busy(serial_busy), .word(data_32));Здесь есть предполагаемый пакет данных, который плата должна принять. Но опять этот предполагаемый пакет данных никак не похож на пакет данных в программе на C или на данные для тестовой программы на питоне.
Вот это отсутствие общих тестовых данных для программы на питоне, C и Verilog очень сильно портит картину. Получается, что между компонентами как бы нет общих точек соприкосновения, общих тестов и это печально.
Вообще, в верилог проекте blakecoin майнера было скрыто еще одно форменное издевательство над моим организмом.
Если проводить симуляцию проекта с verilog тестбенчем, то в симуляторе с вот этими тестовыми данными 416'h000007ffffbd9207ffff001e11f35052d5544… замечательно находится и возвращается результат GOLDEN nonce.
Потом проект компилирую для реальной FPGA платы, эти же самые данные подаю из программы на питоне и… плата не находит GOLDEN nonce…
Оказывается, что тестовые данные в verilog тестбенче «немного плохие». Они для низкой сложности, когда в результирующем хэше всего 24 ведущих нуля, а не 32, как требуется.
В файле experimental/LX150-FourPiped/BLAKE_CORE_FOURPIPED.v есть вот такой код
reg gn_match_d = 1'b0;
always @(posedge clk)
`ifndef SIM
gn_match_d <= (IV7 ^ b76 ^ d74) == 0;
`else
gn_match_d <= (IV7[23:0] ^ b76[23:0] ^ d74[23:0]) == 0;
`endif
В Verilog симуляторе проверяется не так, как будет будет работать в железе! То есть для реальной FPGA платы будем проверять на 32 бита ведущих нулей, а в симуляции будем проверять только 24 бита. Это просто прелестно. Хочется побить автора.
Я конечно, все это победил. По крайней мере, тестовая программа на питоне выдает бодрые сообщения:
Ладно, что в результате? Сколько намайнил? К сожалению нисколько.
Как только я был уже готов начать майнить, буквально в конце января сложность блейка сильно возросла:
Теперь я мог оставить на сутки плату и она хоть и находила решения, но их не принимал пул — все еще мало ведущих нулей.
Я пробовал переключиться на другую валюту — VCASH. С этой валютой пул хотя бы иногда выдавал мне бодрящие сообщения вроде вот этого:
Но все равно и VCASH пул ничего не начисляет. Печаль-беда.
Пользуясь случаем хотел бы спросить у знающих людей. Вот у меня есть видеокарта Nvidia 1060. Она выдает 1,25GHash/sec на блейкоине и за час два-три раза выдает nonce, который принимает пул (и начисляет копеечку). Я думал, что если моя FPGA плата считает 360MHash/sec, ну то есть примерно в 3 раза хуже, чем видеокарта, то я за два часа получу хотя бы один нонсе принятый пулом. Однако, этого не происходит. Даже за сутки нет ни одной копеечки… Где тут подвох для меня так и осталось загадка…
Сейчас я на досуге пытаюсь понять можно ли как-то оптимизировать имеющийся FPGA проект, скажем задействовать встроенную память или еще что-то. Может быть, если повезет, что-то и придумаю.
Комментарии (33)
nckma Автор
13.03.2018 22:21Честно говоря мне не очень ясна логика работы пула. Не может же он всем одинаковые задания раздавать — это как мне кажется было бы странно. В таком случае выигрывал бы всегда один и тот же самый быстрый майнер — а ведь этого я думаю нет. Или я ошибаюсь?
Мало понять логику конкретного алгоритма хеширования, нужно еще понимать логику всей системы — вот этого понимания у меня пока нет.mkuzminov
13.03.2018 22:36расчет хэша распараллеливается на всех участников пула, полученная монета делится на всех пропорционально потраченной мощности
nckma Автор
14.03.2018 08:48Вы меня извините, вот такие общеизвестные фразы — ну что об этом говорить. Это понятно. Дьявол кроется в деталях: особенности реализации протокола, последовательность команд, очередь заданий, правила поиска нонсе.
Вот такой пример. Я смотрю исходные тексты и вижу, что при нахождении первого удачного нонсе с 32-мя ведущими нулями некоторые майнеры возвращают этот нонсе и дальше не продолжают считать хотя полный диапазон всех возможных нонсе еще не пройден, но они запрашивают следующее задание. Это вообще правильно или нет?
По большому счету на одном блоке данных может быть несколько удачных нонсе с 32-мя или более ведущими нулями. Почему нужно или можно прекращать считать и брать следующее задание? Ответ на такой простой вопрос вы нигде ни в какой в документации не найдете.
Или еще замечательное. Все знают, что нужно рассчитывать хэш от некоторого блока данных, но никто не упоминает, что кое-где исходные данные проходят через процедуру be32() которая изменяет очередность байт данных big-endian… Пока это поймешь — с ума можно сойти.mkuzminov
14.03.2018 09:43нонсе считается от 0 до бесконечности, это единственный параметр в блоке который можно менять, для того что бы получить заветный хэш с ведущими нулями, который должен быть меньше trarget…
Bitcoin in a nutshell — Mining раздел Proof-of-Work (PoW)nckma Автор
14.03.2018 09:55Теоретически да, так должно быть. А вот в исходниках я этого не увидел. И глазами смотрел и с GDB проходил — по крайней мере в драйвере для платы icarus — кажется нет там такого. Ищется только первый нодходящий нонсе и все.
Почему так — я не знаю. Может это баг, а может фича. Как узнать?jahr
14.03.2018 10:32С однй стороны, нужно спрашивать новые задания как можно чаще, потому что если пул начал считать новый блок, а вы продолжаете считать задание для старого, то даже если вы что-то там найдете — вам это не засчитают. С другой стороны, спрашивать слишком часто нельзя — будете не успевать что-то находить и не получите никакой награды. Поэтому майнер как только что-то нашел спрашивает новое задание.
charypopper
14.03.2018 00:15Там же ищется хеш определенного вида, всем даются разные задачи, причем вы не знаете что именно считаете, и не можете получить всю премию. Единственно что можно сделать из плохого это умолчать о найденном подходящем хеше, я так понял, но это не дает выгоды никому. В зависимости от типа оплаты в пуле может быть по разному, но всегда по сути идет прапорционально мощности. А как вы говорите кто быстрее — это если майнить без пула, причем если вы не успеваете за блок, то начинать приходится заново и вероятность найти на хеш малыми мощностями крайне мал. Пулы нужны чтобы сократить дисперсию нахождения хеша, и распределение награды равномерно для всех участников. На длинном промежутке времени вам бы было все равно (если комиссий нет) использовать или нет пул.
P.S. Для eth есть интересный пул, для соломайнеров, желающих уменьшить дисперсию, но без распределения награды остальным. Там все майнят, и в соответствии с мощностями накапливаются "очки" и когда хеш находится — майнер с наибольшим числом очков получает всю награду за блок, а его очки сбрасываются до второго майнера в рейтинге. Так все получают в соответствии с мощностями награду, достаточно редко, но зато с малой дисперсией.
mkuzminov
13.03.2018 22:55Вот, на мой взгляд, хороший цикл статей о биткоин
Bitcoin in a nutshell — Cryptography
VBKesha
13.03.2018 23:10Интересно сколько на эту www.xilinx.com/products/boards-and-kits/ek-k7-kc705-g.html плату влезет модулей.
nckma Автор
14.03.2018 08:29+1Можно только примерно предсказать. Если считать, что альтеровский ALM примерно эквивалентен Xilinx LogicCell (хотя это наверное не так), то считаем: в моем проекте 3 хэшера заняли 31 тысячу логических элементов. А тут в Kintex7 326 тысячи элементов. Получается в 10 раз больше. Ну будет наверное 30 хэшеров. Если у меня 360МХэш в секунду, то будет 3,6ГХэш в секунду.
Но тут еще один момент. PowerPlay говорит, что мой проект в CycloneV будет потреблять 3,5Ватта. То есть может оказаться на чипе Xilinx 35Ватт. Тут нужно будет очень хорошее охлаждение, иначе сгорит.old_bear
14.03.2018 23:59иначе сгорит
Вероятнее всего не сгорит, а аварийно сбросит прошивку по перегреву или по превышению порога потребления.
R3VoLuT1OneR
14.03.2018 08:11decred.org — намного интересней проект который использует BLAKE256 как базовый хеш алгоритм. А вот они разработали силикон для blake obelisk.tech
nckma Автор
14.03.2018 08:23Может это и интересный проект, но с FPGA туда войти довольно трудно — нет исходников на которые можно опереться или на которые они ссылаются.
Можно конечно брать исходники от kramble -те, что я использовал в этой работе для блейка, но нет никакой гарантии, что они окажутся как-то совместимыми. Ну а сопряжение хоть и возможно, но может оказаться довольно трудоемким.
ktod
14.03.2018 09:19+1Возможно, есть какие то проблемы с протоколом общения с пулом. Выберите из логов сообщения типа SEND/RECVD и посмотрите все ли с ними в порядке. Нет ли в них сообщений об ошибках и т.д.
Afterk
14.03.2018 09:19+1Будет неправильно если Вы ориентируетесь на число нулей в hex, нужно сравнивать именно значения: пусть заданная сложность транслируется в число 0x0000ABCDEF… (target). Требуется найти nonce с хэшем ниже данного значения: 0x00009BCDEF — подойдёт, 0x0000BBCDEF — не подойдёт.
Может поэтому пул не начисляет шары/монеты? Нужно посмотреть статистику invalid shares, rejected shares.nckma Автор
14.03.2018 09:26Да-да, я понимаю. Возможно в статье не удачная формулировка для простоты изложения. На самом деле я сам никаких решений не принимаю. Плата ВСЕГДА возвращает нонсе только если в хэше 32 бита нулей. Это довольно редкое событие. Потом этот нонсе проверяется в cgminer программными методами с помощью CPU. Тут дальше бывает два варианта. Иногда очень редко вероятно в следствии перегрева происходит аппаратная ошибка вычислений и нонсе оказывается не верным. Программа перепроверяя отфильтровывает такие случаи (они бывают раза 3-4 за сутки). Второй вариант событий — нонсе проверяется программой — достигается ли таргет, а именно весь хэш рассматривается как длинное двоичное число, которое сравнивается с длинным двоичным числом таргета. Меньше-равно или больше. cgminer принимает решение и высылает результат пулу или нет.
charypopper
14.03.2018 17:55Погодите, если 3-4 раза за сутки бывают неправильные хеши, это какой процент? Правильно ли я понял, что это значит и другие хеши которые вы считаете могут быть неверными? Тоесть они могут подходить, а вы сочтете их неподходящими.
nckma Автор
14.03.2018 17:58Да нет… это очень маленький процент…
Плата находит за сутки может 6-7 тысяч нонсе и из них только 3-4 не верные. Ерунда.
Плата проходит диапазон нонсе от нуля до FFFFFFFF примерно за 12 секунд.
Вот это сколько за сутки просчитает примерно 7 тысяч. Каждый найденный нонсе пересчитывается процессором, чтоб убедиться что он верный.
PqDn
14.03.2018 14:50Человек на картинке с поездом, удивительно похож на моего соседа с универской общаги )
nckma Автор
14.03.2018 14:58Этот человек олицетворяет мое отчаяние, когда потратил кучу времени и сил на исследование, а оно не приносит результата… Увы на этот уходящий криптовалютный поезд уже не успеть…
1kvi1
14.03.2018 15:27Возможно еще есть варианты.
Разработали платку с FPGA для мелких монет.
Внутри STM32 и FPGA KINTEX-7. Есть живые образцы.
Есть прошивка под PASC, DCR, SIA. На этих монетах вполне зарабатывает на электричество и еще железо отбивает.
Есть желание поучаствовать в разработке?
sergeypid
14.03.2018 15:20И какое потребление (Ватт) получилось на 360 МХэшей/с?
nckma Автор
14.03.2018 15:26Quartus PowerPlay говорит, что:
+-------------------------------------------------------------------------------------------+
; PowerPlay Power Analyzer Summary;
+----------------------------------------+--------------------------------------------------+
; PowerPlay Power Analyzer Status; Successful — Sat Jan 27 16:52:36 2018;
; Quartus Prime Version; 17.0.0 Build 595 04/25/2017 SJ Lite Edition;
; Revision Name; blakeminer;
; Top-level Entity Name; blakeminer;
; Family; Cyclone V;
; Device; 5CSXFC6D6F31C6;
; Power Models; Final;
; Total Thermal Power Dissipation; 3592.59 mW;
; Core Dynamic Thermal Power Dissipation; 2828.63 mW;
; Core Static Thermal Power Dissipation; 471.21 mW;
; I/O Thermal Power Dissipation; 292.75 mW;
; Power Estimation Confidence; Low: user provided insufficient toggle rate data;
+----------------------------------------+--------------------------------------------------+
mkuzminov
"… ну то есть примерно в 3 раза хуже, чем видеокарта, то я за два часа получу хотя бы один нонсе принятый пулом..."
вот за эти 2 часа условные 1060 уже его и посчитали и были приняты пулом, так что Ваш хэш уже никому не нужен
charypopper
Эм… Так человек пишет о том, что у него карта считает больше хешей в секунду, и награда должна начисляться в 3 раза реже. Что значит хеш никому не нужен? Во-первых, почему хеш, а не хеши, во вторых, всмысле не нужен. По протоколу человеку дается задача, считать хеши в диапазоне, в ответ воркер возвращает нашел или нет + данные для подтверждения, что он вобще считал. Поэтому, почему не работает — непонятно.
nckma Автор
Я абсолютно уверен, что сама плата считает верно и процесс получения заданий и вычисление нонсе — все идет как положено.
Вот в чем я не уверен — у меня старая версия cgminer 3.1.1 (только для нее были патчи) — возможно в протоколе стратум были какие-то изменения в более поздних версиях. Возможно проблема при обмене сообщениями с пулом или еще что-то такое на более высоком уровне.
Как в этом разобраться? Я пока не знаю.
jetcar
наверно не понимаете принцип майнинга если не в пуле где паралельные вычисления то майнер может не успевать за остальной сетью если не достаточно везучий и можно годами майнить так ничего не намайнив, тут нет платы за количество посчитанных хешей(если не в пуле), плата только подходящий
nckma Автор
А я в пуле.
jetcar
хм, тогда может пул маловат и -2/3 мощности ощутимо повлияли на общую производительность и теперь все койны забирает другой более мощный пул