xpmclient 10.5-beta3 is available:
Windows: http://coinsforall.io/distr/xpmclient-opencl-10.5-beta3-win64.zip
Linux: http://coinsforall.io/distr/xpmclient-opencl-10.5-beta3-linux.tar.gz

Radeon RX 6900XT results:

coinsforall.io was down about 6 hours (since 9 May midnight), all miners received XPM for this period.

Since 21 March noon pool works more stable, some issues fixed. xpmforall.org also returns.

minerja
Try this:

Yes, another hosting needed, current cannot. be used for mining pool

Ok, DTC pull will be recovered little bit later.

coinsforall.io was in destroyed SBG2 (with backups), now reopened.

Asm mode for Hawaii is possible, but need some additional work and testing, Tahiti and older GPUs have not gcn 1.1 instructions, can't create asm kernel.

https://twitter.com/olesovhcom
Both pools and backups use OVH.

Update for NVidia version (with RTX 3xxx support), 460.xx or later driver recommended
Windows: http://coinsforall.io/distr/xpmclient-cuda-10.5-beta2-win64.zip
Linux: http://coinsforall.io/distr/xpmclient-cuda-10.5-beta2-linux.tar.gz

Да, я просто частный случай упомянул, и то не совсем корректно, увеличение тактовой частоты (т.е. обычный разгон) ведь тоже увеличение мощности железа

Какой смысл обсуждать масштабирование с ростом частоты, понятно, что тут почти все масштабируется Да только уже давно частоты CPU уже давно не растут...
Предлагаю вернуться к ядрам CPU, тут сортировка пузырьком никак не масштабируется, но есть работающие алгоритмы параллельной сортировки, в редких случаях бывают полезны.

Это зависит от конкретной ОС, в винде это принципиально разные объекты, потоки одного процесса имеют только свой собственный контекст исполнения (регистры, стек, TLS и все что туда входит), все потоки одного процесса имеют общее адресное пространство, файловые дескрипторы, и.т.д.
В линуксе нет такой четкой границы между потоком и процессом, например 2 таких объекта могут иметь разные идентификаторы (тогда падение одного из них не затронет остальные), но работать в одном адресном пространстве, а может быть наоборот (см. параметры системного вызова clone).
Рабочие процессы в nginx в линуксе имеют отдельные идентификаторы, но предполагаю, что они имеют общее пространство файловых дескрипторов (иначе не очень понимаю, как реализивать опцию reuseport). Теперь по сути, вы называете nginx однопоточным и асинхронным, а апач синхронным многопоточным, реально же их рабочие процессы по сути одни и теже сущности в ОС (пусть будут процессы), только один рабочий процесс nginx обслуживает множество подключений одновременно, а в апаче только одно, и если nginx будет использовать классические потоки (то же самое что threads в винде), с точки зрения производительности не изменится абсолютно ничего, стабильность только пострадает.

Это уже совсем другая настройка, так включается пул потоков для запуска синхронных (блокирющих) операций без блокировки цикла сообщений. В зависимости от типа нагрузки опция может поднять производительность на тысячи процентов, а может и ничего не дать.

Если говорить про сеть, то раньше он висел на приеме входящих соединений, с появлением опции reuseport это тоже переехало в worker-ы, так что теперь мастер просто читает конфиг и управляет worker-ами.

Это с каких пор epoll колом встает из-за его вызова из нескольких потоков? Может тесты какие подтверждающие есть? Это у kqueue такие проблемы есть и там рекомендуют использовать несколько независимых экземпляров для цикла сообщений, а у epoll и виндового iocp всегда все ок с этим было.

А чего обсуждать криворуких программистов, да многопоточность это сложно и требования к квалификации разработчиков намного выше.

---

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

Это вообще как  
Сам термин масштабирование означает увеличение производительности при увеличении мощности железа

nginx запускает один мастер процесс и N рабочих процессов (параметр worker_processes в конфиге), каждый из которых мониторит события на своем наборе сокетов, подключения между рабочими процессами распределяются равномерно. Да, можно сделать 1 рабочий процесс и задействовать одно ядро, а можно выставить их по количеству ядер и задействовать CPU полностью, получив при этом почти линейное масштабирование по количеству ядер, что тут может быть не понятного?
А еще можно использовать один файловый дескриптор epoll для всех подключений и опрашивать его из нескольких потоков, так получим более равномерное распределение нагрузки по потокам.

Я же написал про винду и iocp, разве нет?
Poll есть на винде по немного другим названием WSAPoll https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsapoll (начиная с висты)
libevent использует select, в винде  потому что использовать iocp не выйдет, другая архитектура https://en.wikipedia.org/wiki/Proactor_pattern, тут, думаю, тоже должно быть понятно.
boost asio может задействовать iocp, но он сам по себе тяжеловесный и для high load не очень рекомендуется.

Хотелось бы увидеть на примере, как lock-free контейнеры приводят к однопоточному приложению, если они предназначены для доступа на чтение/запись из нескольких потоков

Не совсем так, внутри libevent использует epoll на Linux и kqueue на MacOS X/FreeBSD, отличия от select есть, и довольно заметные.
При использовании select или poll на вход этой функции передается список файловых дескрипторов, после того, как функция возвращает управление, вызывающий обязан в цикле перебрать все эти дескрипторы и проверить их состояние. Т.е. если к серверу подключены 10000 клиентов, то в ответ на приходящие данные хотя бы от одного из 10000 клиентов сервер будет проверять состояние всех 10000 подключений, алгоритмическая сложность O(n). epoll и kqueue возвращают список именно тех файловых дескрипторов, состояние которых изменилось, получаем алг.сложность O(1).
Кроме того, между select и poll есть различия, select использует номер файлового дескриптора как индекс в массиве, и если у тебя открыто более 1024 файлов (даже не сокетов, просто обычных файлов достаточно), то приложение, использующее select просто упадет.
Также надо упомянуть и винду, ее API ввода/вывода использует "порты завершения" (IOCP и чуть более оптимизированную реализация с названием RIO начиная с 8.1), поэтому libevent вынужден использовать select под виндой и не может эффективно работать.. nginx это тоже касается

Ну вот опять

Апач создает новый поток на каждое подключение и захлебывается, когда количество подключений приближается к 1000 или еще раньше. Nginx использует фиксированное количество потоков (но никак не один, если это специально не указать в конфиге), которые работают в цикле сообщений, используя наиболее эффективный механизм для ОС (см. про epoll и kqueue выше).

Если блокироваться на мьютексе по приходу данных, как делает Bitcoin Core (да и наверное все остальные клиенты ) и отпускать блокировку по окончания обработки этих данных, то, безусловно, да А если делать по уму, и синхронизировать только передачу данных между потоками, то приложение будет масштабироваться. Если есть высокие требования к производительности, то можно внедрить lock-free контейнеры... только убедиться, что в данном конкретном случае они дают выигрыш производительности

Код для работы с сетью в bitcoin core вполне себе асинхронный и всегда им был (раньше использовал системный вызов select, сейчас вроде как libevent, хотя на 100% не уверен), но оптимизированным его назвать сложно, т.к. он при обработке сообщения захватывает мьютекс cs_main, т.е. фактически однопоточный.
Дублирование event loop на всех ядрах не всегда хорошо, особенно если ядер много (16 и больше), а если их, к примеру, 4, то вполне нормально запустить 4 потока с циклом сообщений, и в них же выполнять обработку этих сообщений.

Mining was not affected, website did not show pool and workers statistics, now working.

Что, прямо так мало задач распараллеливается?
Если посмотреть тест многоядерных процессоров (например 32-ядерного AMD) https://www.anandtech.com/show/15044/the-amd-ryzen-threadripper-3960x-and-3970x-review-24-and-32-cores-on-7nm то видно, что не так и мало бенчмарков, где он обгоняет обычные 6-8 ядерники с большим отрывом.
Серверы распарралеливаются почти все (не только веб), что мешает одновременно обрабатывать запросы от нескольких клиентов?
И причем тут вообще асинхронность? Та же упомянутая библиотека boost.asio позволяет запускать цикл обработки сообщений о завершенных операциях отправки/приема данных, ничто не мешает запустить таких потоков по количеству ядер, и обрабатывать эти сообщения одновременно.

Это смотря какой язык используется, если Python то из-за его особенностей это все правда, но в контексте C++ написанное выглядит полным бредом Вот как можно противопоставлять многопоточность и асинхронность? Возьмем nginx, он асинхронный и многопоточный, в его конфиге указывается число рабочих потоков, и во многих случаях производительность линейно масштабируется в зависимости от кол-ва потоков.

Nano and Fury(X) also can get +20% performance, good...
For RX480 - not need any changes in config.txt except kernelType="asm", but possible need install more new drivers and remove all *.bin files after. Asm kernel don't like too old (2016 year) Crimson and amdgpu-pro drivers.

asm kernel can work on R9 290/390, may be next version will support it.
Can you post results of Fury and RX4xx with old miner version and 10.5 with asm kernel for compare ?
It seems, normal CPD for stock RX470 is 0.4-0.41CPD, for RX580 - 0.5 CPD now.
Will be in 10.5 beta2.

New beta version of xpmclient for AMD cards available:
http://coinsforall.io/distr/xpmclient-opencl-10.5-beta1-win64.zip
http://coinsforall.io/distr/xpmclient-opencl-10.5-beta1-linux.tar.gz

Main feature of this version - new experimental kernel partially writed using GCN assembly language (https://github.com/CLRX/CLRX-mirror). For enable this, change parameter in config.txt:

"asm" kernel is in not final release, it can works and show big performance advantage (such as 10-12% for Vega and up to 30% for Radeon 4xx/5xx GPUs on Linux.. so big speed up is possible because Linux amdgpu-pro drivers not so good for XPM mining), or fails to launch.
Also, interesting to see result of different GPUs in benchmark mode (xpmclient -b) with generic and asm kernels.

It looks like memory overclocked too much.

Not possible without rebuild, I'll add config parameter for logging in next version.
Now have a problem with high orphan rate, calculator assume that pool not have orphans at all.

Known problem, some drivers create non-optimal kernels.. for example, kernel compiled for R9 29x on old drivers works better on Polaris GPUs. Need fix it in next miner version 10.4.

Need use English here.
Miner users reported error "64 bit kernels not supported on 32 bit executable" in some cases, x86_64 version not have this issue.
I can add x86 build support to deploy system (https://github.com/eXtremal-ik7/xpmclient/tree/version/zcash/contrib), after this you can build x86 version by yourself.

I need use new newbie account, forum have not technical support, administrators not answer.

For solo mining need pool build with dropped accounting, web and other unnecessary parts. Also, pool required patched primecoind client and linux only. Need rewrite some code of pool, I working on it.
Why you not want use madmax's client for solo mining?
https://github.com/madMAx43v3r/xpmserver

xpmclient alltimes open source
https://github.com/eXtremal-ik7/xpmclient/tree/version/zcash

I have checked R9 390, but used little bit different config:
And got same results as 10.2.2 miner.