Topic: [40 TH/s] pool.itzod.ru - RSMPPS 0% fee/LongPoll/JSON API/Websockets/No Invalid - page 463. (Read 1293685 times)

В статистике его не видать что-то.

Итак, мои поздравления всем нам, с первым блоком, найденным при рейтинговой системе.

Правда, я вижу проблему с обновлением статистики, гляну в чем дело.

Неужели блок Кстати, на лп3 кол-во rej.-тов стало гораздо меньше, что очень радует

не только я с утра его заметил, - проснулся и сразу блок))

Блок 

Оценка награды на главной теперь отображается с учетом рейтингов, ее значение обновляется раз в 10 минут.

http://img812.imageshack.us/img812/8775/rewarde.png

P.S. интервал для обновления рейтинга увеличен до 30 минут против прежних 20, по причине ввода нового механизма подсчета скорости, для предотвращения возможных ошибок.

Метод подсчета скорости изменен, + скорости на главной теперь обновляются в реальном времени. К сожалению, некоторое количество воркеров могло отвалиться, судя по тому как после апдейта базы у меня выскочила пачка сообщений "miner is idle" и скорость пула просела с 60+ gh/s до 48. Извиняюсь.

P.S. Еще из изменений - скорости больше не будут сбрасываться в нули с началом нового раунда. Сбрасываться будет только статистика по шарам, рейтинг и базовая скорость. Также уменьшен до 5 минут интервал обновления скоростей воркеров в списке воркеров.

Что вы какие злые, нравится ему))

С уточнением определения скорости работаю в настоящее время. А пока добавлено исключение для пользователей со скоростями < 100 MH/s, для них порог отклонения теперь составляет 60%.

P.S. А как вообще майнить на такой скорости с такой сложностью  

Для меня эти рейтинги как-то неправильно работают. Похоже из-за неточности определения скорости. Мне пишет "Ваша базовая скорость для расчета рейтинга составляет 42 MH/s" когда реально у меня скорость вдвое меньше. и в результате получается, что 40% теперь всегда мне отсекает увеличение рейтинга

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

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

update users set shares_total = shares_total + 1 where user_id = $1;

При запуске оператора update блокируются записи, попадающие под условие where, то есть только запись о пользователе с id, хранящемся в переменной $1. Таким образом, блокировки не оказывают существенного влияния на работу системы в целом и на процессы обновления счетчиков других пользователей, так как у них свои записи и свои блокировки. Но это так только если условие приводит к тому, что нет пересекающихся между юзерами записей. Т.е. не должно быть такого, чтобы два разных запроса пытались обновить одну и ту же запись одновременно, иначе сильно падает производительность. К примеру, если мы создадим табличку типа:

create table stats(
   total_shares integer not null
);

и создадим в ней строку для хранения общего количества шар на пуле. Будем обновлять статистику по шарам внутри хранимой процедуры вот так:

update stats set total_shares = total_shares + 1;

то при 100-150 гигахэшах, размазанных по четырем серверам, результатом будут страшные тормоза сайта и множественные сообщения miner is idle от феникса, хотя, казалось бы, тормозить тут ну совершенно нечему. Именно потому что каждый новый процесс будет пытаться повесить блокировку одну и ту же единственную строку таблицы stats, будет становиться в очередь и выполнение функции будет приостанавливаться до снятия блокировки, либо принудительного убийства блокирующего процесса системой. Такого не произойдет, если pushpoold один, но если их 4 штуки, как у нас, и все используют одну БД-то произойдет обязательно.

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

Вообще, крайне рекомендую ознакомиться вот с этой табличкой:

http://zalil.ru/31522584

К примеру, вот этими записями:


Имхо, но система вполне демократично относится к юзерам. Разница в рейтинге почти в 10 раз, но награда отличается далеко не так сильно. Или вот, тоже хороший пример:


Сравни разницу в рейтингах и разницу в наградах. Не так уж и страшно все, разве нет?  

Ну, если можно хранить временные метки 1000 шар, то можно хранить и ид приславших их.

Да там и не нужно хранить сами шары, а только информацию о том, кто их прислал. Причем этих записей должно быть немного (1000 к примеру).
Берем номер текущей полученной шары, получаем остаток от его деления на 1000, и записываем имя приславшего эту шару в соответствующее поле.
Например Balthazar  прислал 126871-ю шару, его имя пишется как приславшего 871-ю. Когда кто-то пришлет 127871-ю, он перезапишет эту запись. Итого будем иметь всегда запись приславших 1000 последних шар.
Так можно сделать, или это сложно?

Как показал вчерашний подсчет (xlsx-файл я выкладывал ранее в этом топике), суммы "наказаний" для отпадающих юзеров сильно приувеличены, разница в +/- была в районе +0.01 у майнеров с высоким рейтингом и -0.002 BTC у майнеров с низким рейтингом в сравнении с обычным пропоршеналом.

Возможно абсурд, но кто их поймет... Сама идея снабжения себя и окружающих геморроем ради ничтожных копеек-чем не абсурд? Вот CCCP тут писал, что такое практикуется... Так что кто их поймет.

Хранятся текстовые логи шар, на случай если придется искать ошибку или еще что. В базе шары не хранятся, только счетчики ассептед/тотал для каждого юзера, обнуляемые в конце раунда. Насчет хранения последних 1000 шар (а точнее, их временных меток) была такая мысль, но по другой причине-для уточнения подсчета скорости. Думаю, и это будет.

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

Понятно, раз шары не хранятся, то такое не пойдет. Жаль.
Дело в том, что рейтинговая система наказывает как хопперов, так и тех, кто просто нерегулярно майнит по той или иной причине. А прыжки в конец раунда, ИМХО, абсурд, так угадать этот конец невозможно.

Подумал - а почему бы не хранить, допустим последнюю 1000 шар, циклически ее обновляя? И платить приславшим их бонусы?

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

Думаю, защиту от хопперов можно было сделать гораздо проще.
Из награды каждого раунда (50 коинов) 75% распределять между всеми (37.5), и 25% (12.5) распределять между приславшими последние N шар. Причем N должно быть не очень большим (раз в 5 меньше сложности). Можно еще небольшой бонус (2-3%) нашедшему блок сделать.

Немного переработан забор статистики в формате JSON. Для сохранения совместимости старый скрипт не менялся, а был сделан новый. Он будет дополняться. Примеры:

https://pool.itzod.ru/apiex.php?act=getpoolstats
https://pool.itzod.ru/apiex.php?act=getactivetop100
https://pool.itzod.ru/apiex.php?act=getuserstats&username=balthazar
https://pool.itzod.ru/apiex.php?act=getworkerstats&username=balthazar

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

30% потерь при минимальном рейтинге, но ведь минимального же не будет у периодически отключющегося юзера, а значит и ущерба не будет. В общем, посмотрим по итогам текущего раунда. Не стоит так бояться рейтинга.