Only
https://www.mining-dutch.nl/pools/vivo.php?page=login

Registration...

-a neoscrypt -o stratum+tcp://mining-dutch.nl:3610 -u <Your WorkerID> -p <Your Worker Password>

 INFO : [00:32:36] : MESSAGE FROM SERVER: welcome on ALTMINER.NET - happy mining!
 INFO : [00:32:37] : Share difficulty reset -- 256 (0.00391)
 INFO : [00:32:37] : New block #1189445 received, new difficulty is 12.610
 INFO : [00:32:38] : GPU #1: GeForce GTX 1060 6GB, flags: 0, 0, 1
 INFO : [00:32:38] : GPU #0: GeForce GTX 1060 6GB, flags: 0, 0, 1
 INFO : [00:32:39] : New block #86061 received, new difficulty is 111.493
INFO : [00:32:39] : Share Rejected, Invalid job id

Miner send to pool request on block 1189445?  

With 4233:
INFO : [00:30:59] : New block #6110 received, new difficulty is 423.982

 INFO : [00:31:25] : New block #1189444 received, new difficulty is 13.730

Not a VIVO

Can the hsrminer ignore blocks that go out of order? In theory, if the connection was not interrupted, then the blocks should follow strictly in order...

Now testing on port 4233 with "-p c=vivo,d=256"... Bug with dedicated port 10001

Log:
 INFO : [23:55:35] : Share Accepted
 INFO : [23:55:36] : New block #86041 received, new difficulty is 76.410 VIVO
 INFO : [23:55:40] : Share Accepted
 INFO : [23:56:02] : Share Accepted
 INFO : [23:56:06] : Share Accepted
 INFO : [23:56:21] : New block #86042 received, new difficulty is 76.913 VIVO
 INFO : [23:56:40] : Share Accepted, overall speed is 903.68kH/s, efficiency 98.38%
 INFO : [23:57:21] : Share difficulty reset -- 512 (0.00781)
 INFO : [23:57:21] : New block #23595 received, new difficulty is 682.049 GoByte
 INFO : [23:57:33] : Share Accepted
 INFO : [23:57:45] : New block #23596 received, new difficulty is 663.913 GoByte
 INFO : [23:58:25] : MESSAGE FROM SERVER: welcome on ALTMINER.NET - happy mining!
 INFO : [23:58:41] : Share difficulty reset -- 256 (0.00391)
 INFO : [23:58:41] : New block #86043 received, new difficulty is 90.925 VIVO
 INFO : [23:58:42] : New block #86044 received, new difficulty is 100.923 VIVO
 INFO : [23:58:48] : Share Accepted
 INFO : [23:58:51] : Share Accepted
 INFO : [23:58:52] : Share Accepted

DevFee on GoByte? It cause long reinit process... Fixed diff...

I've also noticed that https://www.altminer.net/ sometimes sends blocks from other coins. I am mine VIVO, there are blocks with a certain number. Then once the block comes from GoByte ... Some glitch of the pool.

Я пишу программное обеспечение в области нейронных сетей и обработки изображений Вот мой сайт https://sites.google.com/site/iamforintelligent/ Не думаю, что считывание одного числа из памяти GPU раз в 10 секунд, к примеру, как-то может повлиять на скорость...

Так-то с Новым годом Тема интересна, так как я вижу, что какие-то потоки делают чёрти что продолжительное время... Обидно за державу программу

Почему же нельзя. Есть некий процесс, при запуске он получает адрес в памяти GPU, именно адрес в памяти GPU (передаём этот адрес через параметр ядра), считывает по этому адресу значение, это номер блока.

Далее считаем мы 10 секунд, к примеру, заново считываем по этому адресу, получаем актуальный номер блока, если он отличается от того, что было при запуске, самозавершаем поток, простой return. При этом все потоки делают такие проверки синхронно (через N операций, тактов, именно синхронно, а не с использованием какой-то синхронизации программно вызываемой), то есть и завершат свою же работу также синхронно.

Я имею ввиду счет над конкретной шарой после 22:08:54. Он уже не актуален, можно было бы ресурсы отдать другим потокам. Вполне может быть, что они стояли в очереди и ничего не делали, пока ранее запущенный счет бесполезно сжигал ватты.

Все же хотел уточнить.
INFO : [22:04:59] : New block #85993 received, new difficulty is 126.086
...
 INFO : [22:08:54] : New block #85994 received, new difficulty is 118.543
...
 INFO : [22:14:01] : Share Rejected, Invalid job id
 INFO : [22:14:04] : Share Rejected, Invalid job id
 INFO : [22:14:05] : Share Rejected, Invalid job id
 INFO : [22:14:14] : Share Rejected, Invalid job id
 INFO : [22:14:15] : Share Rejected, Invalid job id

Какая-то из нитей (или ядер, не принципиально, пусть мы абстрагируемся), запущенная между 22:04:59 и 22:08:54 считала, считала и в 22:14:01 закончила счёт. То есть за зря как минимум 5 минут шёл счёт? Если это нить, запущенная ещё раньше блока 85993, то всё ещё хуже  

На двух картах 1080 Ti между 22:04:59 и 22:08:54 было успешно принято ровно 58 шар. Сложность фиксированная - 256. Получается округленно 60 шар за 4 минуты. 15 шар в минуту, 7.5 шар на карту в минуту. Что это тогда за шара, которая считалась 5 минут или более (начиная с момента до 22:08:54 и заканчивая 22:14:01)? Понятно, что итеративные процессы могут быть бесконечными, но тут надо его прерывать в какой-то момент, а именно - в 22:08:54

Я не вникал в алгоритм, но из такого разброса скорости можно предположить, что некий процесс считается дольше других. Если он оооочень затянулся (например, в N раз дольше, чем последние 100 успешно завершившихся), есть ли повод его прибить совсем, чтобы запустить другой процесс, который может быть был бы более успешным?

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

Не думаю, что много будет есть ресурсов CPU. По крайней мере можно было бы посмотреть, оценить это... Современные процессоры весьма шустрые.

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

Меня смущает, что эффективность эта меньше 98% Получается достаточно много таких вот случаев.

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

Откуда могут возникать ошибки типа "Share Rejected, Invalid job id"? Майнер о том, что новый блок появился не сообщал... Может быть, конечно, https://www.altminer.net косячит

Тут есть весьма явная зависимость от сложности на NeoScrypt. Если фиксировать, то скорость на разных настройках существенно отличается. Поэкспериментируйте. На риге с тремя 1070-ми и одной 1080Ti экспериментально подобрал оптимальное значение - 512. Вместо 5.2 MH/s выдаётся стабильно 5.4 MH/s. Почти 4% рост...

А вообще, на этом майнере пара моих 1060-ых выдаёт почти столько же, сколько и одна 1080Ti. Место оптимизации...

10 вентиляторов в системнике сделали его почти вертолётом, всего 16 штук, если считать те, что на видеокартах.