Bitcoin Forum
June 30, 2025, 06:14:09 AM *
News: Pizza day contest voting
 
   Home   Help Search Login Register More  
Pages: « 1 ... 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 [402] 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 ... 586 »
  Print  
Author Topic: [40 TH/s] pool.itzod.ru - RSMPPS 0% fee/LongPoll/JSON API/Websockets/No Invalid  (Read 1293745 times)
qqqq
Legendary
*
Offline Offline

Activity: 1596
Merit: 1011


View Profile
May 28, 2013, 05:31:30 PM
 #8021

В чем причина ухода от прямого ответа на вопрос "вернется ли возможность снова выбирать сложность шар" ? Почему ее убрали ?
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1362



View Profile
May 28, 2013, 05:36:54 PM
Last edit: May 28, 2013, 05:47:39 PM by Balthazar
 #8022

Да куда уж прямее-то?
Quote
Но можно будет выбрать целевое количество шар в минуту.
Такое ощущение, как будто я на китайском или суахили пишу незаметно для самого себя. Ей-богу, это просто несерьезно. %)

Quote from: qqqq
Почему ее убрали ?
Потому что она неэффективна.
ZPK
Legendary
*
Offline Offline

Activity: 1302
Merit: 1021



View Profile
May 28, 2013, 05:38:29 PM
 #8023

Настройки сложности, как таковой, не будет.
А если человек на ОпСоСовском модеме сиди с мощной фермой?
Ну и все нормально будет)

Novacoin POS mining only now
Lexis77
Hero Member
*****
Offline Offline

Activity: 830
Merit: 1000



View Profile
May 28, 2013, 05:44:30 PM
 #8024

Настройки сложности, как таковой, не будет.
А если человек на ОпСоСовском модеме сиди с мощной фермой?
Ну и все нормально будет)
Тада ок.
Мне без разницы, я так, для общего развития.

   ▄ █     ▄
   ▀ █ ▄ ▀ █
 ▄ █ █ █ █ █ ▄
██ █ █ █▄█ █ ██
██▄███▄█ ██████
 ▀▀███▄█████▀▀
██▀▀███████▀▀██
 █▄  ▀███▀  ▄█
 ▀▀▀██▀ ▀██▀▀▀
   ███▀█▀███
   █ █▀█ █ █
     ▀ █ █
     ▀ █
   ▄ █     ▄
   ▀ █ ▄ ▀ █
 ▄ █ █ █ █ █ ▄
██ █ █ █▄█ █ ██
██▄███▄█ ██████
 ▀▀███▄█████▀▀
██▀▀███████▀▀██
 █▄  ▀███▀  ▄█
 ▀▀▀██▀ ▀██▀▀▀
   ███▀█▀███
   █ █▀█ █ █
     ▀ █ █
     ▀ █
   ▄ █     ▄
   ▀ █ ▄ ▀ █
 ▄ █ █ █ █ █ ▄
██ █ █ █▄█ █ ██
██▄███▄█ ██████
 ▀▀███▄█████▀▀
██▀▀███████▀▀██
 █▄  ▀███▀  ▄█
 ▀▀▀██▀ ▀██▀▀▀
   ███▀█▀███
   █ █▀█ █ █
     ▀ █ █
     ▀ █
.
●  Over 630 Cards
●  32 Heroes in 7 Classes
●  Innovative Dual System
.
●  Balanced & Varied
●  Great Community
●  FREE to play
[]   ▄ █     ▄
   ▀ █ ▄ ▀ █
 ▄ █ █ █ █ █ ▄
██ █ █ █▄█ █ ██
██▄███▄█ ██████
 ▀▀███▄█████▀▀
██▀▀███████▀▀██
 █▄  ▀███▀  ▄█
 ▀▀▀██▀ ▀██▀▀▀
   ███▀█▀███
   █ █▀█ █ █
     ▀ █ █
     ▀ █
invader
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
May 28, 2013, 05:47:21 PM
Last edit: May 28, 2013, 06:00:47 PM by invader
 #8025

Quote
Путаешь теплое с мягким. 32 шара дает в 32 раза больше "работы", чем 1. Но она все равно одна. Это одна шара, один хэш.

Промтой пример - два ведра яблок, в одном 1 килограмм, в другом 2. Если считать ведрами, то у нас будет 2 ведра, а не 3. Если считать в "условных ведрах по 1кг яблок", то будет три "условных ведра". Но физически-то их все равно будет 2.

Но это не совсем правильное сравнение, потоиу что яблоки можно разложить по ведрам, а из d32 шары нельзя сделать 32 d1 шары.

Отнюдь, просто пытаюсь указать на существующую проблему вычисления параметра "rej.%" при наличии периодически скачущей сложности шар, при любой фиксированной сложности проблема просто отсутствует как класс.

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

Как я уже писал выше, неплохо было бы видеть на worker'е как количество физически отвергнутых шар, так и количество отвергнутых "виртуальных" d1 шар. Сейчас есть информация только по принятым для разной сложности, для отвергнутых нет - оно все сваливаются в одну кучу.
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1362



View Profile
May 28, 2013, 05:52:13 PM
 #8026

Нет никакой проблемы считать реджекты, исходя из d1a (окромя того, что для отклоненных шар нельзя установить, какая у них была сложность). Но это просто неправильно будет. То, о чем идет речь - это совсем другой и сферический параметр, по сути. "Оценка потерь, выраженная как доля потерь в работе, приведенной к единичной сложности", но никак не реджекты. Его тогда уж в отдельную колонку добавлять.
qqqq
Legendary
*
Offline Offline

Activity: 1596
Merit: 1011


View Profile
May 28, 2013, 05:55:27 PM
 #8027

А что если пул будет временами переходить на повышенную сложность, которая и будет больше реджектится ? Обидно же...
needbmw
Legendary
*
Offline Offline

Activity: 1302
Merit: 1008



View Profile
May 28, 2013, 05:56:44 PM
 #8028

ведро там уронили, к примеру, или кто-то насрал в него
какая прелестная аналогия  Grin

ну так колхозу все равно, в ведро какой вместимости насрали, оно теперь все равно целиком непригодно к переработке  Cheesy
поэтому колхоз считает Rej = (насрали / всего ведер) * 100% и неиб... (beep)  Grin

NO PSAKING!
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1362



View Profile
May 28, 2013, 05:58:41 PM
 #8029

А что если пул будет временами переходить на повышенную сложность, которая и будет больше реджектится ? Обидно же...
С чего ей больше реджектиться? Реджектов и там и там одинаково будет, если канал достаточно широкий. Если нет, то на большей сложности будет меньше потерь. Roll Eyes
invader
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
May 28, 2013, 06:04:08 PM
 #8030

Quote
Нет никакой проблемы считать реджекты, исходя из d1a (окромя того, что для отклоненных шар нельзя установить, какая у них была сложность). Но это просто неправильно будет. То, о чем идет речь - это совсем другой и сферический параметр, по сути. "Оценка потерь, выраженная как доля потерь в работе, приведенной к единичной сложности", но никак не реджекты. Его тогда уж в отдельную колонку добавлять.

Именно об этом и речь, просто добавить еще один параметр - нормированные d1 режекты, ведь нормированные принятые считаются уже. Из них уже посчитать правильный нормированный % потерь (добавить его к существующему) как соотношение ( d1_rejected / d1_accepted ) * 100%. Можно обозвать его как-нибуть rejN.% ...
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1362



View Profile
May 28, 2013, 06:06:50 PM
 #8031

Нормированные принятые считаются, а отклоненные нет. Архитектурное ограничение не позволяет оперировать сложностями шар, которые были удалены из буфера. В основном, в этом проблема.
invader
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
May 28, 2013, 06:07:12 PM
 #8032

ведро там уронили, к примеру, или кто-то насрал в него
какая прелестная аналогия  Grin

ну так колхозу все равно, в ведро какой вместимости насрали, оно теперь все равно целиком непригодно к переработке  Cheesy
поэтому колхоз считает Rej = (насрали / всего ведер) * 100% и неиб... (beep)  Grin

Grin Но фермер то хочет узнать в ведро какой емкости чаще всего гадят....
PrimeMan
Newbie
*
Offline Offline

Activity: 40
Merit: 0


View Profile
May 28, 2013, 06:09:20 PM
 #8033

Потерянные вёдра характеризуют качество связи, а потерянные яблоки характеризуют качество дохода. По большому счёту, в пределе, эти параметры должны сходиться, так как вероятность потерять ведро не зависит от количества яблок в нём. Грубое, конечно, сравнение, не всё так просто. А если всё-таки зависит, значит с пулом что-то не так. (Грузчики п*т полные вёдра чаще, чем полупустые?)
Vicus
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
May 28, 2013, 06:10:35 PM
 #8034

Раз пошла такая пьянка то добавьте на главной в строке:
Раунд длится ... (процент намайненого в тек. раунде относительно блока в 25 монет)...
И вообще, может в таблице текущий раунд отображать со статусом что-то вроде "Вычисление"?
mine777
Member
**
Offline Offline

Activity: 210
Merit: 10



View Profile
May 28, 2013, 06:18:33 PM
 #8035

Раз пошла такая пьянка то добавьте на главной в строке:
Раунд длится ... (процент намайненого в тек. раунде относительно блока в 25 монет)...
это там итак давно есть

Вcего новых решений 85760 (D1A 333536).
Из них ваших 53 (D1A 106).
Награда в системе RSMPPS ~ 0.00021730 BTC.

Последний блок был найден 28.05.2013 22:07:45.
Раунд длится 11м 9с.
Vicus
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


View Profile
May 28, 2013, 06:21:43 PM
 #8036

Раз пошла такая пьянка то добавьте на главной в строке:
Раунд длится ... (процент намайненого в тек. раунде относительно блока в 25 монет)...
это там итак давно есть

Вcего новых решений 85760 (D1A 333536).
Из них ваших 53 (D1A 106).
Награда в системе RSMPPS ~ 0.00021730 BTC.

Последний блок был найден 28.05.2013 22:07:45.
Раунд длится 11м 9с.
Ключевое слово процент и, не мною намайненого, а всеми в этом раунде...
invader
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
May 28, 2013, 06:23:35 PM
 #8037

Потерянные вёдра характеризуют качество связи, а потерянные яблоки характеризуют качество дохода. По большому счёту, в пределе, эти параметры должны сходиться, так как вероятность потерять ведро не зависит от количества яблок в нём.

Да, именно так. При условии что сложность емкость ведра не будет меняться постоянно, а установится на определенном значении. Как уже упоминалось выше. Если емкость ведер увеличивается пропорционально количеству подаваемых яблок, то в моменты когда яблоки на некоторое время перестают подаваться счетчик емкости ведра сбрасывается до минимальных значений. Затем при возобновлении подачи яблок емкость ведер снова начинает меняться и получаются что параметры не будут сходится пока меняется емкость ведер.
PrimeMan
Newbie
*
Offline Offline

Activity: 40
Merit: 0


View Profile
May 28, 2013, 06:31:00 PM
Last edit: May 28, 2013, 06:46:22 PM by PrimeMan
 #8038

Потерянные вёдра характеризуют качество связи, а потерянные яблоки характеризуют качество дохода. По большому счёту, в пределе, эти параметры должны сходиться, так как вероятность потерять ведро не зависит от количества яблок в нём.

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

Допустим вероятность потерять шару равна 1%.
Вероятность потерять шару D2 равна 1%
Вероятность потерять шару D4 тоже 1%
На небольшом интервале времени в 200 шар (пусть по 100 каждого вида), мы можем потерять две шары D4 (2%), и ни одной D2 (0%), сколько бы раз они не переключались между собой за это время. Интернет соединению, частоте появления новых блоков, и погоде на марсе пофиг на сложность конкретной шары. Но когда шар десятки тысяч, то такого разброса быть не должно. И там, и там, будет примерно 1% +/- малое значение.
rPman
Legendary
*
Offline Offline

Activity: 1120
Merit: 1069


View Profile WWW
May 28, 2013, 06:53:46 PM
 #8039

Нет никакой проблемы считать реджекты, исходя из d1a (окромя того, что для отклоненных шар нельзя установить, какая у них была сложность). Но это просто неправильно будет. То, о чем идет речь - это совсем другой и сферический параметр, по сути. "Оценка потерь, выраженная как доля потерь в работе, приведенной к единичной сложности", но никак не реджекты. Его тогда уж в отдельную колонку добавлять.
Не согласен! Как раз с точки зрения недополученной прибыли, правильнее считать потери в виртуальных d1 шарах, важно ведь в конце концов не количество не дошедших шар, а упущенная мощность (не дошедшая до пула и соответственно им неучтенная). Если вам так удобнее, можете считать в реджекты в недополученных биткоинах, правда не с PPS пулами формула будет ой какая нетривиальная, но зато сразу понятная и удобная клиентам.

Считать 'потерянные яблоки в абстрактных ведрах не фиксированного размера' действительно бессмысленное дело, правильно считать в килограммах, или на худой конец в штуках (а точнее в оплачиваемых единицах).

Здесь не может находиться ваша реклама Smiley
Protect a future of bitcoin, use p2pool
Donation in BTC: 19fv5yYtfWZ9jQNjx2ncmu1TTrvg5CczZe
invader
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
May 28, 2013, 07:06:21 PM
Last edit: May 28, 2013, 07:28:51 PM by invader
 #8040

Quote
Допустим вероятность потерять шару равна 1%.
Вероятность потерять шару D2 равна 1%
Вероятность потерять шару D4 тоже 1%
На небольшом интервале времени в 200 шар (пусть по 100 каждого вида), мы можем потерять две шары D4 (2%), и ни одной D2 (0%), сколько бы раз они не переключались между собой за это время. Интернет соединению, частоте появления новых блоков, и погоде на марсе пофиг на сложность конкретной шары. Но когда шар десятки тысяч, то такого разброса быть не должно. И там, и там, будет примерно 1% +/- малое значение.

Также,как мы можем потерять две шары D2 и ни одной D4, и продолжая считать в итоге на D32 - получим довольно странный итоговый результат.
Вероятность потери шары задается суммой различных факторов, каналом передачи данных и т.п.,
также имеет смысл говорить о вероятности потерять шару в некую единицу времени и она в том числе зависит от количества шар в единицу времени - больше шар, больше вероятность потери каждой из них.
Этот параметр может плавать в некоторых пределах, но главная проблема именно в дополнительной переменной связанной с переходным процессом при изменении сложности.
Чем выше сложность, тем меньше поступает шар в единицу времени, тем больше влияние потерянных простых шар на суммарный результат в % соотношении, особенно когда сложность периодически перестраивается. Если процесс сброса сложности и сопутствующего ему накапливанию простых отвергнутых шар в общей сумме будет повторяться, то будем иметь постоянно завышенную оценку % потерь.
Для проверки достаточно сбросить статистику и понаблюдать за ней, периодически меняя долю хэшрейта воркера чтобы происходили переключения сложности.
Pages: « 1 ... 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 [402] 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 ... 586 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!