Topic: Nicehash miner legacy fork (форк программы NHML) - page 112. (Read 56325 times)
Хотелось бы обсудить следующую фичу, как перехват devfee майнеров и отправка шар найсу на кошелек пользователя. В соотношении 50% пользователю, 50% разработчику nhml fork fix. Devfee майнеров, которые используют ssl подключение к серверам перехватываться не будет. И не все алгоритмы могут быть перехвачены, на данный момент.
С увеличенной до 3-х секунд задержкой рестарта майнеров пока всё работает без приключений (вотчдоги ещё не отключал).
Была у меня такая проблема. Заключалось в том что у запущенного NHML Fix не было достаточно прав.
Решилось запуском от имени администратора
Все варианты найсхэша всегда запускал с админскими правами, так что тут что-то другое. Решилось запуском от имени администратора
Лучше найти причину зависания майнеров.
Фикус в том, что майнеры в этот момент технически не зависшие. Не знаю, с чего начинается цепочка событий, но при обнаружении данной ситуации оба майнера либо успешно работают, дерясь за ресурсы, либо один работает, а другой ругается, что ему не хватает видеопамяти (и его бесконечно перезапускает форкфикс). Оба также легко снимаются либо таскменеджером, либо убиванием процессов из командной строки. В системе ничего не портится, её рестарта для возобновления работы не требуется. Единственное, что при этом ведёт себя неадекватно – сам форкфикс, не закрывающийся по нажатию на крестик с последующим диалогом "программа не отвечает".
Была у меня такая проблема. Заключалось в том что у запущенного NHML Fix не было достаточно прав.
Решилось запуском от имени администратора
Чем не устраивает штатный виндовый планировщик задач?
как им останавливать майн? - убить саму оболочку мало - она же запускает сами майнеры. Или я что-то упустил и можно передавать команды старт-стоп?
taskkill /F /IM NiceHashMinerLegacy.exe /T
/T Завершение указанного процесса и всех его дочерних процессов.
/F Принудительное завершение процесса.
Чем не устраивает штатный виндовый планировщик задач?
как им останавливать майн? - убить саму оболочку мало - она же запускает сами майнеры. Или я что-то упустил и можно передавать команды старт-стоп?
Чем не устраивает штатный виндовый планировщик задач?
как им останавливать майн? - убить саму оболочку мало - она же запускает сами майнеры. Или я что-то упустил и можно передавать команды старт-стоп?
Во-первых, хочу выразить благодарность автору за программу - пользуюсь давно и успешно.
Во-вторых - в свете всем известных причин возникла необходимость переходить на "ночной" майн. Есть ли какой способ с минимумом костылей сделать "планировку задач" с запуском и остановкой в указанное время? - сходу такого не нашёл. В своё время был CGWatcher - там это было реализовано и было очень удобно. Если нету такой возможности никак - прошу считать это feature request-ом.
Чем не устраивает штатный виндовый планировщик задач? Во-вторых - в свете всем известных причин возникла необходимость переходить на "ночной" майн. Есть ли какой способ с минимумом костылей сделать "планировку задач" с запуском и остановкой в указанное время? - сходу такого не нашёл. В своё время был CGWatcher - там это было реализовано и было очень удобно. Если нету такой возможности никак - прошу считать это feature request-ом.
Во-первых, хочу выразить благодарность автору за программу - пользуюсь давно и успешно.
Во-вторых - в свете всем известных причин возникла необходимость переходить на "ночной" майн. Есть ли какой способ с минимумом костылей сделать "планировку задач" с запуском и остановкой в указанное время? - сходу такого не нашёл. В своё время был CGWatcher - там это было реализовано и было очень удобно. Если нету такой возможности никак - прошу считать это feature request-ом.
Во-вторых - в свете всем известных причин возникла необходимость переходить на "ночной" майн. Есть ли какой способ с минимумом костылей сделать "планировку задач" с запуском и остановкой в указанное время? - сходу такого не нашёл. В своё время был CGWatcher - там это было реализовано и было очень удобно. Если нету такой возможности никак - прошу считать это feature request-ом.
Как всегда, при возникновении любой проблемы нужны логи
Те, которые logs/log.txt и logs/log.1.txt или ещё какие-то? Копировать до принудительного закрытия форкфикса или после?Если принятых вчера мер окажется недостаточно и проблема продолжит проявляться, сохраню конечно.
Как всегда, при возникновении любой проблемы нужны логи
Те, которые logs/log.txt и logs/log.1.txt или ещё какие-то? Копировать до принудительного закрытия форкфикса или после?Если принятых вчера мер окажется недостаточно и проблема продолжит проявляться, сохраню конечно.
Кстати, сейчас заглянул на одной машине наугад в лог, а там при работе miniz пару раз в минуту пробегает один из вот таких казусов:
Code:
[2019-12-08 23:00:57] [INFO] [miniZ-MINER_ID(16)-DEVICE_IDs(0,1,2,3)] Unexpected end when deserializing array. Path 'result[0]', line 1, position 580.
...
[2019-12-08 23:00:47] [INFO] [miniZ-MINER_ID(16)-DEVICE_IDs(0,1,2,3)] Unexpected end when deserializing array. Path 'result[1]', line 1, position 886.
...
[2019-12-08 23:00:22] [INFO] [miniZ-MINER_ID(16)-DEVICE_IDs(0,1,2,3)] Unexpected end when deserializing array. Path 'result[2]', line 1, position 1192.
...
[2019-12-08 23:01:37] [INFO] [miniZ-MINER_ID(16)-DEVICE_IDs(0,1,2,3)] Unexpected end when deserializing array. Path 'result[3]', line 1, position 1498
...
[2019-12-08 23:00:47] [INFO] [miniZ-MINER_ID(16)-DEVICE_IDs(0,1,2,3)] Unexpected end when deserializing array. Path 'result[1]', line 1, position 886.
...
[2019-12-08 23:00:22] [INFO] [miniZ-MINER_ID(16)-DEVICE_IDs(0,1,2,3)] Unexpected end when deserializing array. Path 'result[2]', line 1, position 1192.
...
[2019-12-08 23:01:37] [INFO] [miniZ-MINER_ID(16)-DEVICE_IDs(0,1,2,3)] Unexpected end when deserializing array. Path 'result[3]', line 1, position 1498
Номер позиции для каждого из резалтов колеблется на несколько единиц относительно процитированного.
Работать оно вроде работает, но наверное так не должно быть.
Лучше найти причину зависания майнеров.
Фикус в том, что майнеры в этот момент технически не зависшие. Не знаю, с чего начинается цепочка событий, но при обнаружении данной ситуации оба майнера либо успешно работают, дерясь за ресурсы, либо один работает, а другой ругается, что ему не хватает видеопамяти (и его бесконечно перезапускает форкфикс). Оба также легко снимаются либо таскменеджером, либо убиванием процессов из командной строки. В системе ничего не портится, её рестарта для возобновления работы не требуется. Единственное, что при этом ведёт себя неадекватно – сам форкфикс, не закрывающийся по нажатию на крестик с последующим диалогом "программа не отвечает".
Лучше найти причину зависания майнеров.
Фикус в том, что майнеры в этот момент технически не зависшие. Не знаю, с чего начинается цепочка событий, но при обнаружении данной ситуации оба майнера либо успешно работают, дерясь за ресурсы, либо один работает, а другой ругается, что ему не хватает видеопамяти (и его бесконечно перезапускает форкфикс). Оба также легко снимаются либо таскменеджером, либо убиванием процессов из командной строки. В системе ничего не портится, её рестарта для возобновления работы не требуется. Единственное, что при этом ведёт себя неадекватно – сам форкфикс, не закрывающийся по нажатию на крестик с последующим диалогом "программа не отвечает".
Может, совпадение, но с 20-й версией вернулся уже месяца два как забытый баг с запуском двух майнеров одновременно, причём комбинации бывают разные (вчера, например, на одном риге случились gminer+gminer, а на другом claymore+miniz). Пока увеличил задержку перезапуска майнеров до 3-х секунд – не знаю, поможет ли, но параллельно возник вопрос:
Судя по двойным процессам в штатном режиме, встроенные в майнеры вотчдоги (где они есть) не отключены. Есть ли в этом какой-то особый смысл, ведь форкфикс сам берёт на себя функции вотчдога для запущенных майнеров, если я правильно понимаю? Не может ли двойной надзор быть причиной двойного [пере]запуска и появления неучтённого процесса?
Может. Если процесс майнера завис, то программа не может его прибить в 90% случаев. Попробуйте отключить вачдоги у майнеров в доп.параметрах, но лучше не станет. Лучше найти причину зависания майнеров. Судя по двойным процессам в штатном режиме, встроенные в майнеры вотчдоги (где они есть) не отключены. Есть ли в этом какой-то особый смысл, ведь форкфикс сам берёт на себя функции вотчдога для запущенных майнеров, если я правильно понимаю? Не может ли двойной надзор быть причиной двойного [пере]запуска и появления неучтённого процесса?
Может, совпадение, но с 20-й версией вернулся уже месяца два как забытый баг с запуском двух майнеров одновременно, причём комбинации бывают разные (вчера, например, на одном риге случились gminer+gminer, а на другом claymore+miniz). Пока увеличил задержку перезапуска майнеров до 3-х секунд – не знаю, поможет ли, но параллельно возник вопрос:
Судя по двойным процессам в штатном режиме, встроенные в майнеры вотчдоги (где они есть) не отключены. Есть ли в этом какой-то особый смысл, ведь форкфикс сам берёт на себя функции вотчдога для запущенных майнеров, если я правильно понимаю? Не может ли двойной надзор быть причиной двойного [пере]запуска и появления неучтённого процесса?
Судя по двойным процессам в штатном режиме, встроенные в майнеры вотчдоги (где они есть) не отключены. Есть ли в этом какой-то особый смысл, ведь форкфикс сам берёт на себя функции вотчдога для запущенных майнеров, если я правильно понимаю? Не может ли двойной надзор быть причиной двойного [пере]запуска и появления неучтённого процесса?
Вытащил одну, оставил 8 ГБ, стало - huge page 100% 1168/1168 +JIT
И хеш вырос на треть.
И хеш вырос на треть.
Правильное описание событий:
Quote
Перезагрузил систему, стало - huge page 100% 1168/1168 +JIT
И хеш вырос на треть.
И хеш вырос на треть.
Фрагментация памяти, и, как следствие, невозможность выделить большие непрерывные куски. Бороться разве что воздержанием от использования приложений, крошащих память, и наличием достаточного её запаса. Иногда помогает временное закрытие (на время запуска майнера) какого-нибудь жадного до памяти процесса, если нет – перезагрузка.
А планочку верните, без неё будет только хуже
Вытащил одну, оставил 8 ГБ, стало - huge page 100% 1168/1168 +JIT
И хеш вырос на треть.
И хеш вырос на треть.
Правильное описание событий:
Quote
Перезагрузил систему, стало - huge page 100% 1168/1168 +JIT
И хеш вырос на треть.
И хеш вырос на треть.
Фрагментация памяти, и, как следствие, невозможность выделить большие непрерывные куски. Бороться разве что воздержанием от использования приложений, крошащих память, и наличием достаточного её запаса. Иногда помогает временное закрытие (на время запуска майнера) какого-нибудь жадного до памяти процесса, если нет – перезагрузка.
А планочку верните, без неё будет только хуже
Здравствуйте!
Про xmrig версии 5.1.0. Всё замечательно, на AMD FX-8320E (8 ядер) хеш вырос с 1800 до 1950 h/s.
Вопрос про строку в начале запуска майнера:
rx alloceted 2336 MB (2080+256) huge page 0% 0/1168 +JIT
На других процессорах - huge page 100% 1168/1168 +JIT
И, соответственно, хешрейт больше на 1\3.
Блокировка страниц памяти включена ВЕЗДЕ.
Везде минус 1 ядро.
Как с этим бороться?
Что-то с памятью? Столкнулся: - стояло 2 одинаковых планки по 8 ГБ, всего 16,
было huge page 0% 0/1168 +JIT
Вытащил одну, оставил 8 ГБ, стало - huge page 100% 1168/1168 +JIT
И хеш вырос на треть.
С уважением.
Как бороться с этим - не знаю. Иногда помогает перезагрузка.Про xmrig версии 5.1.0. Всё замечательно, на AMD FX-8320E (8 ядер) хеш вырос с 1800 до 1950 h/s.
Вопрос про строку в начале запуска майнера:
rx alloceted 2336 MB (2080+256) huge page 0% 0/1168 +JIT
На других процессорах - huge page 100% 1168/1168 +JIT
И, соответственно, хешрейт больше на 1\3.
Блокировка страниц памяти включена ВЕЗДЕ.
Везде минус 1 ядро.
Как с этим бороться?
Что-то с памятью? Столкнулся: - стояло 2 одинаковых планки по 8 ГБ, всего 16,
было huge page 0% 0/1168 +JIT
Вытащил одну, оставил 8 ГБ, стало - huge page 100% 1168/1168 +JIT
И хеш вырос на треть.
С уважением.
upd. Попробуйте версию 5.1.1, вдруг поможет https://github.com/angelbbs/xmrig/releases
Обновил майнер xmrig до версии 5.1.0, который обещает улучшение производительности RandomX (до +6-7% на Intel CPUs, +2-3% на Ryzen CPUs).
В своей сборке улучшил совместимость с nicehash.
Уменьшил fee до 0.5%.
Чтобы скачать, удалите файл /bin/Fork_Fix_20.txt
После запуска программы, майнеры загрузятся автоматически.
В своей сборке улучшил совместимость с nicehash.
Уменьшил fee до 0.5%.
Чтобы скачать, удалите файл /bin/Fork_Fix_20.txt
После запуска программы, майнеры загрузятся автоматически.
Здравствуйте!
Про xmrig версии 5.1.0. Всё замечательно, на AMD FX-8320E (8 ядер) хеш вырос с 1800 до 1950 h/s.
Вопрос про строку в начале запуска майнера:
rx alloceted 2336 MB (2080+256) huge page 0% 0/1168 +JIT
На других процессорах - huge page 100% 1168/1168 +JIT
И, соответственно, хешрейт больше на 1\3.
Блокировка страниц памяти включена ВЕЗДЕ.
Везде минус 1 ядро.
Как с этим бороться?
Что-то с памятью? Столкнулся: - стояло 2 одинаковых планки по 8 ГБ, всего 16,
было huge page 0% 0/1168 +JIT
Вытащил одну, оставил 8 ГБ, стало - huge page 100% 1168/1168 +JIT
И хеш вырос на треть.
С уважением.
Обновил майнер xmrig до версии 5.1.0, который обещает улучшение производительности RandomX (до +6-7% на Intel CPUs, +2-3% на Ryzen CPUs).
В своей сборке улучшил совместимость с nicehash.
Уменьшил fee до 0.5%.
Чтобы скачать, удалите файл /bin/Fork_Fix_20.txt
После запуска программы, майнеры загрузятся автоматически.
В своей сборке улучшил совместимость с nicehash.
Уменьшил fee до 0.5%.
Чтобы скачать, удалите файл /bin/Fork_Fix_20.txt
После запуска программы, майнеры загрузятся автоматически.
Jump to: