Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
August 08, 2011, 02:44:01 PM Last edit: August 31, 2012, 04:06:35 PM by Balthazar |
|
Думаю, защиту от хопперов можно было сделать гораздо проще. Из награды каждого раунда (50 коинов) 75% распределять между всеми (37.5), и 25% (12.5) распределять между приславшими последние N шар. Причем N должно быть не очень большим (раз в 5 меньше сложности). Можно еще небольшой бонус (2-3%) нашедшему блок сделать.
Дело в том, что шары не сохраняются в БД (путь с сохранением шар в БД мы уже проходили, возвращаться к нему не стоит, вариант с индивидуальными счетчиками гораздо эффективнее и позволяет обновлять большую часть информации на лету), а определить продолжительность раунда заранее невозможно, только пост-фактум. Да и не будет такая система достаточно эффективна и справедлива, хопперы могут прыгать и под конец блока без проблем, и практикуют такое. А в данной системе не имеет значения, в начало или в конец блока был совершен прыжок. Награда дается комплексно, и за объем работы и за время. Прямо как в реальной работе в крупной организации.
|
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
Alex AXe
Legendary
Offline
Activity: 1218
Merit: 1019
|
|
August 08, 2011, 02:52:43 PM |
|
Понятно, раз шары не хранятся, то такое не пойдет. Жаль. Дело в том, что рейтинговая система наказывает как хопперов, так и тех, кто просто нерегулярно майнит по той или иной причине. А прыжки в конец раунда, ИМХО, абсурд, так угадать этот конец невозможно.
Подумал - а почему бы не хранить, допустим последнюю 1000 шар, циклически ее обновляя? И платить приславшим их бонусы?
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
August 08, 2011, 02:56:44 PM |
|
Понятно, раз шары не хранятся, то такое не пойдет. Жаль. Дело в том, что рейтинговая система наказывает как хопперов, так и тех, кто просто нерегулярно майнит по той или иной причине. А прыганье в конец раунда, ИМХО, абсурд, так угадать этот конец невозможно.
Как показал вчерашний подсчет (xlsx-файл я выкладывал ранее в этом топике), суммы "наказаний" для отпадающих юзеров сильно приувеличены, разница в +/- была в районе +0.01 у майнеров с высоким рейтингом и -0.002 BTC у майнеров с низким рейтингом в сравнении с обычным пропоршеналом. Возможно абсурд, но кто их поймет... Сама идея снабжения себя и окружающих геморроем ради ничтожных копеек-чем не абсурд? Вот CCCP тут писал, что такое практикуется... Так что кто их поймет. Хранятся текстовые логи шар, на случай если придется искать ошибку или еще что. В базе шары не хранятся, только счетчики ассептед/тотал для каждого юзера, обнуляемые в конце раунда. Насчет хранения последних 1000 шар (а точнее, их временных меток) была такая мысль, но по другой причине-для уточнения подсчета скорости. Думаю, и это будет. В общем, я предлагаю дождаться конца раунда, а потом уже делать выводы о нужности или ненужности изменений. Незачем чинить пока еще толком неиспользованную вещь.
|
|
|
|
Alex AXe
Legendary
Offline
Activity: 1218
Merit: 1019
|
|
August 08, 2011, 03:04:52 PM |
|
Да там и не нужно хранить сами шары, а только информацию о том, кто их прислал. Причем этих записей должно быть немного (1000 к примеру). Берем номер текущей полученной шары, получаем остаток от его деления на 1000, и записываем имя приславшего эту шару в соответствующее поле. Например Balthazar прислал 126871-ю шару, его имя пишется как приславшего 871-ю. Когда кто-то пришлет 127871-ю, он перезапишет эту запись. Итого будем иметь всегда запись приславших 1000 последних шар. Так можно сделать, или это сложно?
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
August 08, 2011, 03:11:55 PM |
|
Да там и не нужно хранить сами шары, а только информацию о том, кто их прислал. Причем этих записей должно быть немного (1000 к примеру). Берем номер текущей полученной шары, получаем остаток от его деления на 1000, и записываем имя приславшего эту шару в соответствующее поле. Например Balthazar прислал 126871-ю шару, его имя пишется как приславшего 871-ю. Когда кто-то пришлет 127871-ю, он перезапишет эту запись. Итого будем иметь всегда запись приславших 1000 последних шар. Так можно сделать, или это сложно? Дело в том, что обработка новых шар осуществляется хранимой процедурой на pl/pgsql. И для того, чтобы изменить значение какой-либо записи, требуется лок этой записи на время обновления. А так как при большой скорости шары присылаются часто, блокировка-разблокировка записей будет происходить с каждой присланной шарой тоже часто. Возможны даже ситуации, когда посланные в разное время шары из-за задержек сети придут одновременно с двух серверов (допустим lp1 и lp2) и произойдет взаимная блокировка одной и той же записи (допустим, 871-й) двумя процессами. И каждый из них будет ждать, пока сосед снимет блокировку, ничего не делая. Такая ситуация называется deadlock и даже хуже с точки зрения применимости, чем хранение всех шар сразу, т.к. PostgreSQL разрешает ситуацию с взаимными блокировками очень просто-принудительным завершением обоих процессов, что приводит к тому что ни одно из этих двух новых значений не будет сохранено. В многопользовательских системах под многопоточной нагрузкой порой возникает много странных эффектов, которые новичку в этом деле трудно понять.
|
|
|
|
Alex AXe
Legendary
Offline
Activity: 1218
Merit: 1019
|
|
August 08, 2011, 03:20:11 PM |
|
Ну, если можно хранить временные метки 1000 шар, то можно хранить и ид приславших их.
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
August 08, 2011, 03:43:02 PM Last edit: August 31, 2012, 04:04:05 PM by Balthazar |
|
Ну, если можно хранить временные метки 1000 шар, то можно хранить и ид приславших их.
Без риска взаимных блокировок мы можем изменять только записи, которые имеют непосредственное отношение к юзеру, шара которого обрабатывается. Обновлять остальные записи мы можем только в случае редкого события, например конца раунда. В конце раунда мы можем с чистой совестью залочить всю таблицу и проапдейтить в один присест. В других же случаях, ситуация иная. К примеру, мы можем изменять значение поля-счетчика в записи, соответствующей его учетке, как нам вздумается с каждой шарой. Допустим, есть у нас такой код: 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К примеру, вот этими записями: Flintenfu 2241 19 0,0496088 USSR 2182 2 0,04326501
Имхо, но система вполне демократично относится к юзерам. Разница в рейтинге почти в 10 раз, но награда отличается далеко не так сильно. Или вот, тоже хороший пример: kaufmann 11328 69 0,32768917 overDen 11324 69 0,32757346 gaer 13093 31 0,31117626
Сравни разницу в рейтингах и разницу в наградах. Не так уж и страшно все, разве нет?
|
|
|
|
starik69
Legendary
Offline
Activity: 1367
Merit: 1000
|
|
August 09, 2011, 06:20:24 PM |
|
Для меня эти рейтинги как-то неправильно работают. Похоже из-за неточности определения скорости. Мне пишет "Ваша базовая скорость для расчета рейтинга составляет 42 MH/s" когда реально у меня скорость вдвое меньше. и в результате получается, что 40% теперь всегда мне отсекает увеличение рейтинга
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
August 09, 2011, 07:11:24 PM Last edit: August 09, 2011, 07:29:53 PM by Balthazar |
|
Для меня эти рейтинги как-то неправильно работают. Похоже из-за неточности определения скорости. Мне пишет "Ваша базовая скорость для расчета рейтинга составляет 42 MH/s" когда реально у меня скорость вдвое меньше. и в результате получается, что 40% теперь всегда мне отсекает увеличение рейтинга С уточнением определения скорости работаю в настоящее время. А пока добавлено исключение для пользователей со скоростями < 100 MH/s, для них порог отклонения теперь составляет 60%. P.S. А как вообще майнить на такой скорости с такой сложностью
|
|
|
|
Yazik
Member
Offline
Activity: 98
Merit: 100
|
|
August 09, 2011, 08:19:54 PM |
|
Для меня эти рейтинги как-то неправильно работают. Похоже из-за неточности определения скорости. Мне пишет "Ваша базовая скорость для расчета рейтинга составляет 42 MH/s" когда реально у меня скорость вдвое меньше. и в результате получается, что 40% теперь всегда мне отсекает увеличение рейтинга С уточнением определения скорости работаю в настоящее время. А пока добавлено исключение для пользователей со скоростями < 100 MH/s, для них порог отклонения теперь составляет 60%. P.S. А как вообще майнить на такой скорости с такой сложностью Что вы какие злые, нравится ему))
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
August 09, 2011, 08:26:11 PM Last edit: August 09, 2011, 11:02:35 PM by Balthazar |
|
Метод подсчета скорости изменен, + скорости на главной теперь обновляются в реальном времени. К сожалению, некоторое количество воркеров могло отвалиться, судя по тому как после апдейта базы у меня выскочила пачка сообщений "miner is idle" и скорость пула просела с 60+ gh/s до 48. Извиняюсь. P.S. Еще из изменений - скорости больше не будут сбрасываться в нули с началом нового раунда. Сбрасываться будет только статистика по шарам, рейтинг и базовая скорость. Также уменьшен до 5 минут интервал обновления скоростей воркеров в списке воркеров.
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
August 09, 2011, 11:41:02 PM Last edit: August 10, 2011, 01:37:18 AM by Balthazar |
|
Оценка награды на главной теперь отображается с учетом рейтингов, ее значение обновляется раз в 10 минут. http://img812.imageshack.us/img812/8775/rewarde.pngP.S. интервал для обновления рейтинга увеличен до 30 минут против прежних 20, по причине ввода нового механизма подсчета скорости, для предотвращения возможных ошибок.
|
|
|
|
manrus
Legendary
Offline
Activity: 1334
Merit: 1004
TTM
|
|
August 10, 2011, 07:53:44 AM |
|
Блок
|
|
|
|
Ocakypa
|
|
August 10, 2011, 08:01:00 AM |
|
не только я с утра его заметил, - проснулся и сразу блок))
|
|
|
|
overDen
Newbie
Offline
Activity: 43
Merit: 0
|
|
August 10, 2011, 08:17:34 AM |
|
Неужели блок Кстати, на лп3 кол-во rej.-тов стало гораздо меньше, что очень радует
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
August 10, 2011, 08:23:34 AM |
|
Итак, мои поздравления всем нам, с первым блоком, найденным при рейтинговой системе. Правда, я вижу проблему с обновлением статистики, гляну в чем дело.
|
|
|
|
Yazik
Member
Offline
Activity: 98
Merit: 100
|
|
August 10, 2011, 08:48:25 AM |
|
В статистике его не видать что-то.
|
|
|
|
Alex AXe
Legendary
Offline
Activity: 1218
Merit: 1019
|
|
August 10, 2011, 08:54:39 AM |
|
А где награда?
|
|
|
|
Alex AXe
Legendary
Offline
Activity: 1218
Merit: 1019
|
|
August 10, 2011, 09:01:21 AM |
|
А где награда? Уже появилась.
|
|
|
|
Balthazar
Legendary
Offline
Activity: 3108
Merit: 1358
|
|
August 10, 2011, 09:03:52 AM |
|
Проблема была в том, что время сервера отстало на 20 секунд и скрипт не смог установить соответствие между записью в базе и транзакцией нового блока в списке. Синхронизировал время и все норм пошло.
|
|
|
|
|