задержка задержки в сети O(n^2) нод (частично фиксится, частично акселится), задержки в самой ноде (фиксится/акселерируется), в генерации getblocktemplate (между пулом и нодой, есть версия вместо json/bin формат), задержки в самом пуле фисксяться (акселерируются), стек пула tcp/udp + протокол - (оптимизация/аксел) разница между тем же stratum v1/stratumv2 примерно раз в 30ать траф/cpu/mem, поскольку нету оверхедов, заголовка http с баластом, все влезает в один пакет tcp без дисордеринга меньше окна tcp, меньше памяти, меньше трафика, нету задержек на парсинге json, проще конечный клиент, нету потерь jobid при обрыве сессий tcp, нету потерь jobid всего ДЦ при работе прокси и смене ISP1/isp2-backup.
Ура!
А в процентах (потерянных терахешах/сек на петахеш/сек) примерно сколько?
Ну, и, готов поспорить, что, объявив переключение на границе блока / не чаще чем раз в N минут и только при условии M% профитности можно найти такую долю «скачущих» майнеров (чтобы обойти парадокс ожидания/проч нюансы), при которой интегральный профит будет выше, чем если направить те же силы на устранение задержек распространения задач.
NB: я ни в коем случае не предлагаю бросить одно и начать заниматься другим, просто это ещё одно направление оптимизации.
Кстати, при даунвольтинге отношение th/w не константа, и при уменьшении какое-то время растёт - юные умельцы успешно колхозят двойных свиней из пережаренных s9, запуская на одном бп 20th вместо 14 - это тоже направление оптимизации, при котором также продлевается среднее время службы оборудования.
Темой пока не владею, тестовые только приехали - а у меня менты с обысками - поэтому точной статистики нет, но должно быть интересно.
