Comments 36
"… ну то есть примерно в 3 раза хуже, чем видеокарта, то я за два часа получу хотя бы один нонсе принятый пулом..."
вот за эти 2 часа условные 1060 уже его и посчитали и были приняты пулом, так что Ваш хэш уже никому не нужен
вот за эти 2 часа условные 1060 уже его и посчитали и были приняты пулом, так что Ваш хэш уже никому не нужен
Эм… Так человек пишет о том, что у него карта считает больше хешей в секунду, и награда должна начисляться в 3 раза реже. Что значит хеш никому не нужен? Во-первых, почему хеш, а не хеши, во вторых, всмысле не нужен. По протоколу человеку дается задача, считать хеши в диапазоне, в ответ воркер возвращает нашел или нет + данные для подтверждения, что он вобще считал. Поэтому, почему не работает — непонятно.
Я абсолютно уверен, что сама плата считает верно и процесс получения заданий и вычисление нонсе — все идет как положено.
Вот в чем я не уверен — у меня старая версия cgminer 3.1.1 (только для нее были патчи) — возможно в протоколе стратум были какие-то изменения в более поздних версиях. Возможно проблема при обмене сообщениями с пулом или еще что-то такое на более высоком уровне.
Как в этом разобраться? Я пока не знаю.
Вот в чем я не уверен — у меня старая версия cgminer 3.1.1 (только для нее были патчи) — возможно в протоколе стратум были какие-то изменения в более поздних версиях. Возможно проблема при обмене сообщениями с пулом или еще что-то такое на более высоком уровне.
Как в этом разобраться? Я пока не знаю.
наверно не понимаете принцип майнинга если не в пуле где паралельные вычисления то майнер может не успевать за остальной сетью если не достаточно везучий и можно годами майнить так ничего не намайнив, тут нет платы за количество посчитанных хешей(если не в пуле), плата только подходящий
Честно говоря мне не очень ясна логика работы пула. Не может же он всем одинаковые задания раздавать — это как мне кажется было бы странно. В таком случае выигрывал бы всегда один и тот же самый быстрый майнер — а ведь этого я думаю нет. Или я ошибаюсь?
Мало понять логику конкретного алгоритма хеширования, нужно еще понимать логику всей системы — вот этого понимания у меня пока нет.
Мало понять логику конкретного алгоритма хеширования, нужно еще понимать логику всей системы — вот этого понимания у меня пока нет.
расчет хэша распараллеливается на всех участников пула, полученная монета делится на всех пропорционально потраченной мощности
Вы меня извините, вот такие общеизвестные фразы — ну что об этом говорить. Это понятно. Дьявол кроется в деталях: особенности реализации протокола, последовательность команд, очередь заданий, правила поиска нонсе.
Вот такой пример. Я смотрю исходные тексты и вижу, что при нахождении первого удачного нонсе с 32-мя ведущими нулями некоторые майнеры возвращают этот нонсе и дальше не продолжают считать хотя полный диапазон всех возможных нонсе еще не пройден, но они запрашивают следующее задание. Это вообще правильно или нет?
По большому счету на одном блоке данных может быть несколько удачных нонсе с 32-мя или более ведущими нулями. Почему нужно или можно прекращать считать и брать следующее задание? Ответ на такой простой вопрос вы нигде ни в какой в документации не найдете.
Или еще замечательное. Все знают, что нужно рассчитывать хэш от некоторого блока данных, но никто не упоминает, что кое-где исходные данные проходят через процедуру be32() которая изменяет очередность байт данных big-endian… Пока это поймешь — с ума можно сойти.
Вот такой пример. Я смотрю исходные тексты и вижу, что при нахождении первого удачного нонсе с 32-мя ведущими нулями некоторые майнеры возвращают этот нонсе и дальше не продолжают считать хотя полный диапазон всех возможных нонсе еще не пройден, но они запрашивают следующее задание. Это вообще правильно или нет?
По большому счету на одном блоке данных может быть несколько удачных нонсе с 32-мя или более ведущими нулями. Почему нужно или можно прекращать считать и брать следующее задание? Ответ на такой простой вопрос вы нигде ни в какой в документации не найдете.
Или еще замечательное. Все знают, что нужно рассчитывать хэш от некоторого блока данных, но никто не упоминает, что кое-где исходные данные проходят через процедуру be32() которая изменяет очередность байт данных big-endian… Пока это поймешь — с ума можно сойти.
нонсе считается от 0 до бесконечности, это единственный параметр в блоке который можно менять, для того что бы получить заветный хэш с ведущими нулями, который должен быть меньше trarget…
Bitcoin in a nutshell — Mining раздел Proof-of-Work (PoW)
Bitcoin in a nutshell — Mining раздел Proof-of-Work (PoW)
Там же ищется хеш определенного вида, всем даются разные задачи, причем вы не знаете что именно считаете, и не можете получить всю премию. Единственно что можно сделать из плохого это умолчать о найденном подходящем хеше, я так понял, но это не дает выгоды никому. В зависимости от типа оплаты в пуле может быть по разному, но всегда по сути идет прапорционально мощности. А как вы говорите кто быстрее — это если майнить без пула, причем если вы не успеваете за блок, то начинать приходится заново и вероятность найти на хеш малыми мощностями крайне мал. Пулы нужны чтобы сократить дисперсию нахождения хеша, и распределение награды равномерно для всех участников. На длинном промежутке времени вам бы было все равно (если комиссий нет) использовать или нет пул.
P.S. Для eth есть интересный пул, для соломайнеров, желающих уменьшить дисперсию, но без распределения награды остальным. Там все майнят, и в соответствии с мощностями накапливаются "очки" и когда хеш находится — майнер с наибольшим числом очков получает всю награду за блок, а его очки сбрасываются до второго майнера в рейтинге. Так все получают в соответствии с мощностями награду, достаточно редко, но зато с малой дисперсией.
Вот, на мой взгляд, хороший цикл статей о биткоин
Bitcoin in a nutshell — Cryptography
Bitcoin in a nutshell — Cryptography
Интересно сколько на эту www.xilinx.com/products/boards-and-kits/ek-k7-kc705-g.html плату влезет модулей.
Можно только примерно предсказать. Если считать, что альтеровский ALM примерно эквивалентен Xilinx LogicCell (хотя это наверное не так), то считаем: в моем проекте 3 хэшера заняли 31 тысячу логических элементов. А тут в Kintex7 326 тысячи элементов. Получается в 10 раз больше. Ну будет наверное 30 хэшеров. Если у меня 360МХэш в секунду, то будет 3,6ГХэш в секунду.
Но тут еще один момент. PowerPlay говорит, что мой проект в CycloneV будет потреблять 3,5Ватта. То есть может оказаться на чипе Xilinx 35Ватт. Тут нужно будет очень хорошее охлаждение, иначе сгорит.
Но тут еще один момент. PowerPlay говорит, что мой проект в CycloneV будет потреблять 3,5Ватта. То есть может оказаться на чипе Xilinx 35Ватт. Тут нужно будет очень хорошее охлаждение, иначе сгорит.
decred.org — намного интересней проект который использует BLAKE256 как базовый хеш алгоритм. А вот они разработали силикон для blake obelisk.tech
Может это и интересный проект, но с FPGA туда войти довольно трудно — нет исходников на которые можно опереться или на которые они ссылаются.
Можно конечно брать исходники от kramble -те, что я использовал в этой работе для блейка, но нет никакой гарантии, что они окажутся как-то совместимыми. Ну а сопряжение хоть и возможно, но может оказаться довольно трудоемким.
Можно конечно брать исходники от kramble -те, что я использовал в этой работе для блейка, но нет никакой гарантии, что они окажутся как-то совместимыми. Ну а сопряжение хоть и возможно, но может оказаться довольно трудоемким.
Возможно, есть какие то проблемы с протоколом общения с пулом. Выберите из логов сообщения типа SEND/RECVD и посмотрите все ли с ними в порядке. Нет ли в них сообщений об ошибках и т.д.
Будет неправильно если Вы ориентируетесь на число нулей в hex, нужно сравнивать именно значения: пусть заданная сложность транслируется в число 0x0000ABCDEF… (target). Требуется найти nonce с хэшем ниже данного значения: 0x00009BCDEF — подойдёт, 0x0000BBCDEF — не подойдёт.
Может поэтому пул не начисляет шары/монеты? Нужно посмотреть статистику invalid shares, rejected shares.
Может поэтому пул не начисляет шары/монеты? Нужно посмотреть статистику invalid shares, rejected shares.
Да-да, я понимаю. Возможно в статье не удачная формулировка для простоты изложения. На самом деле я сам никаких решений не принимаю. Плата ВСЕГДА возвращает нонсе только если в хэше 32 бита нулей. Это довольно редкое событие. Потом этот нонсе проверяется в cgminer программными методами с помощью CPU. Тут дальше бывает два варианта. Иногда очень редко вероятно в следствии перегрева происходит аппаратная ошибка вычислений и нонсе оказывается не верным. Программа перепроверяя отфильтровывает такие случаи (они бывают раза 3-4 за сутки). Второй вариант событий — нонсе проверяется программой — достигается ли таргет, а именно весь хэш рассматривается как длинное двоичное число, которое сравнивается с длинным двоичным числом таргета. Меньше-равно или больше. cgminer принимает решение и высылает результат пулу или нет.
Погодите, если 3-4 раза за сутки бывают неправильные хеши, это какой процент? Правильно ли я понял, что это значит и другие хеши которые вы считаете могут быть неверными? Тоесть они могут подходить, а вы сочтете их неподходящими.
Да нет… это очень маленький процент…
Плата находит за сутки может 6-7 тысяч нонсе и из них только 3-4 не верные. Ерунда.
Плата проходит диапазон нонсе от нуля до FFFFFFFF примерно за 12 секунд.
Вот это сколько за сутки просчитает примерно 7 тысяч. Каждый найденный нонсе пересчитывается процессором, чтоб убедиться что он верный.
Плата находит за сутки может 6-7 тысяч нонсе и из них только 3-4 не верные. Ерунда.
Плата проходит диапазон нонсе от нуля до FFFFFFFF примерно за 12 секунд.
Вот это сколько за сутки просчитает примерно 7 тысяч. Каждый найденный нонсе пересчитывается процессором, чтоб убедиться что он верный.
Человек на картинке с поездом, удивительно похож на моего соседа с универской общаги )
Этот человек олицетворяет мое отчаяние, когда потратил кучу времени и сил на исследование, а оно не приносит результата… Увы на этот уходящий криптовалютный поезд уже не успеть…
Возможно еще есть варианты.
Разработали платку с FPGA для мелких монет.
Внутри STM32 и FPGA KINTEX-7. Есть живые образцы.
Есть прошивка под PASC, DCR, SIA. На этих монетах вполне зарабатывает на электричество и еще железо отбивает.
Есть желание поучаствовать в разработке?
Разработали платку с FPGA для мелких монет.
Внутри STM32 и FPGA KINTEX-7. Есть живые образцы.
Есть прошивка под PASC, DCR, SIA. На этих монетах вполне зарабатывает на электричество и еще железо отбивает.
Есть желание поучаствовать в разработке?
Ну не знаю… А что нужно делать? Тут же уже похоже все сделано…
Где про этот проект узнать больше?
А что Вас конкретно интересует? Я могу попробовать ответить…
Есть еще статья marsohod.org/projects/proekty-dlya-platy-marsokhod3/363-blake
Но она в принципе про то же самое.
Есть еще статья marsohod.org/projects/proekty-dlya-platy-marsokhod3/363-blake
Но она в принципе про то же самое.
И какое потребление (Ватт) получилось на 360 МХэшей/с?
Quartus 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;
+----------------------------------------+--------------------------------------------------+
+-------------------------------------------------------------------------------------------+
; 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;
+----------------------------------------+--------------------------------------------------+
Only those users with full accounts are able to leave comments. Log in, please.
Как я blakecoin майнер делал