Смысл пользователям из Украины предлагать сервисы Яндекса? Оно там почти всё заблокировано.

GoDaddy падал, можно, конечно, рандомно подбирать разные DNS сервера в надежде найти закэшировавший нужные адреса (у меня, например, пока и провайдерский держит). Можно в hosts прописать пока адреса вручную, например эти с Reddit'а:


UPD: если что, я проверил – 8.8.8.8 (Google DNS) в данный момент возращает правильные адреса (те, что указаны выше).

По поводу отлёта воркеров с тирексом – в списке изменений версии 0.18.7 (4 дня назад) есть следующее:

---

Её там каждый день под разными акками постят, но надо же какой-то инстинкт самосохранения иметь.

Да я просто --mt 1 убрал. И вообще, у меня с тирексом что-то много получается шар забракованных, оставил феникс.

Процесс монитором посмотрел фактическую командную строку – не объединяется. Но действительно, галочка стоит:

Кстати, а что она делает? Без неё, помнится, тоже что-то не работало.

В новом форкфиксе для trex/daggerhashimoto для всех карт по умолчанию прописан дополнительный параметр --mt 1. Во-первых, t-rex при этом не стартует, ругаясь красным на синтаксис командной строки (скорее всего из-за того что одинаковые параметры из настроек разных карт по-прежнему не объединяются, а повторяются, т.е. получается "--mt 1 --mt 1 --mt 1..."). А во-вторых, нельзя такие параметры по умолчанию ставить – теоретически так можно завесить удалённый риг с последующей необходимостью ехать к нему и поднимать обратно.

There is a better parameter, --help; in most situations it significantly reduces the time for getting answers.
In this particular case it immediately suggests that there are at least two related parameters, --intensity and --dual_intensity.

У 31+ версий не получается переключиться с феникса на kawpow-trex – феникс продолжает вхолостую работать, а форкфикс снова и снова убивает тирекса (которому, вероятно, не хватает памяти из-за работающего феникса и он не может нормально стартовать), в результате риг просто простаивает без выхлопа, пока не захочет вернуться обратно на даггерхашимото. Случилось уже несколько раз. С предыдущими версиями ничего такого не происходило.

К сожалению, не удалось пока застать лог с началом проблемы, но есть лог с самым разгаром и концом: http://www.mediafire.com/file/0yrggrkehz9ii4q/Phoenix-trex_transition_problem.zip/file

UPD: залипший феникс оказался отдельной проблемой, не связанной напрямую с тирексом. Оказалось, что оно просто не может запустить тирекс сам по себе, даже после свежего старта всего клиента ("GetSummary exception: No connection could be made because the target machine actively refused it 127.0.0.1:4002").

UPD2: немедленное обрубание тирекса происходит не на всех машинах, на некоторых всё работает. В чём разница – пока не понял. Там, где его рубит – рубит ещё до того, как он успевает что-то написать в консоль.

UPD3: вроде нашёл в чём дело. В архиве с майнерами лежит тирекс для CUDA 11, соответственно работает это только с весьма свежими драйверами.

Это с фениксом? У меня настройки не слетают, но в системный лог при обрубании процесса форкфиксом сыплются ошибки драйвера. На всех ригах, где используется форкфикс и феникс. При закрытии майнера крестиком ошибок нет. Со старыми драйверами бывало и винду ребутило, сейчас вроде перестало.

The same story as with Cuckatoo32. Actual poolside hashrate for BeamV3 is significantly (7-10% for 1070) lower than hashrate shown in the console. While another miner displays slightly lower numbers, its effective hashrate is actually higher.

A couple of months ago I thought that it's a bug in the C32 implementation, but now all this looks more like desperate attempts to win the hashrate race.

Не думаю, что стану вас учить профессиональной этике. Делайте как умеете.

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

Да хоть бы и штатным, но это происходило без анонса и какого-либо уведомления о произведенных действиях. Просто в очередной версии появилась установленная по умолчанию опция в конфиге, пользователь о сбросе протоколов не знал, а если бы и знал – воспрепятствовать никак не мог. В кругах, к которым я близок, так делать не принято.

Пожеланий выше крыши, но уже не сегодня. Спасибо за оперативные изменения.

ResetProtocols не меняла настройки?

Два неприятных бага в последних версиях:

1) При автоперезапуске форкфикса он зачем-то убивает все процессы майнеров, которые находит в системе, в том числе и те, которые запускал не он. Ему не для того админские права дадены, чтобы он делал что хочет; кстати, надеюсь, практика тихого изменения настроек системы уже в прошлом? Я хотел бы явного подтверждения.

2) Я о том, что так скорее всего будет, уже писал, вы тогда реплику проигнорировали: независимо от включенности галочки "использовать OpenHardwareMonitor" оно грузит драйвер WinRing0 и некорректно выгружает его при выходе, разрушая цепочку пользователей драйвера, если форкфикс оказался в её начале или особенно в середине. Простое упражнение: а) запускаем OpenHardwareMonitor или LibreHardwareMonitor, б) запускаем форкфикс, в) запускаем xmrig; г) перезапускаем форкфикс и затем д) пытаемся перезапустить xmrig – тот уже не может ничего сделать с драйвером и, как следствие, не может установить/снять флаги управления кэшированием. Теперь, чтобы xmrig вновь заработал полноценно, нужно закрыть одновременно все процессы, использующие драйвер WinRing0.

BeamV3 suddenly stopped working on Nicehash with --pers=auto (all shares are rejected); when --pers=Beam-PoW or is not specified at all miniZ still works fine.

Уже нормально платит.

Отклоняет только от miniZ, запущенного из-под форкфикса, потому что там прописано "pers=auto". Причём кастомные параметры, указанные в настройках, зачем-то лепятся в начало командной строки, а не в конец, и оверрайдить захардкоденные в форке нет возможности. Приходится пока запускать майнер без форкфикса, батничком, и посматривать на пейрейты.

UPD: обнаружил, что --pers указан первым среди вшитых параметров, и, казалось бы, его можно было бы подавить ключом -p, сделав вид, что это пароль, но вот именно его автор почему-то прописал не через "=", как всё остальное, а через пробел, и "auto" в зону действия -p уже не попадает и майнер в итоге не стартует из-за некорректной командной строки, как удачно-то, а.

Now the difference between the C32 hashrate shown by gminer and that one reported by the pool became even bigger; with 1070s it's about 25% (at least on Nicehash servers). Basically, since you started declaring improved C32 hashrate back in April the actual hashrate stays more or less the same, only numbers reported by the miner "improve".

Tried C32, got device out of memory error on Win 10 with 8GB 1070s, while gminer works fine there. Not sure what you meant by "cuckatoo32 for Grin32 on Nvidia 8G above GPUs" in the release notes. Is that "8GB or above" or "above 8GB"?

Минизи тоже есть уже.

Прямо сейчас не проверял, но с месяцок назад тоже исследовал, там ситуация интереснее – принятый хэшрейт kawpow вроде как заметно ниже отображаемого майнером, но реальный пейрейт настолько же выше декларируемого, и в итоге получается как раз то что ожидалось. С кукату32 всё не так, пейрейт там ничего не компенсирует, и ему действительно нужно искуственно снижать ожидаемый хэшрейт.

С kawpow хотя бы есть возможность попробовать разные майнеры и убедиться, что проблема одинакова для всех и корень её где-то в найсхэше, а тут майнер один, и непонятно, к кому бежать жаловаться – к гмайнеру или к найсхэшу. Или к обоим. Или забить

Это ещё как посмотреть. У меня gminer показывает хэшрейт для cuckatoo32 на 15-20% больше, чем найсхэш, при том что битых шар ничтожно мало или совсем нет. Пробовал даже на сутки жёстко включать и сравнивать усреднённое – всё то же самое, кто-то из них врёт.