Копане на BURST - под лупа

[Mateev]

Този проблем с малкото Peers го имаше при мене по всичките ми Wallet-и. Конектваха се само към 4-5 Peer-а, при това тези Peer-ове обикновено бяха със стари версии на софтуера. Причината за този проблем се състои в това, че при инсталацията на Wallet-а той е зареден с НЕАКТУАЛЕН СПИСЪК от Well Known Peers. Дори и да приемем, че от този списък са валидни повечето IP адреси, самото му полуляризиране в толкова много инсталации води до това, че голяма част от тези Peers отказват връзка с вашия Wallet, защото вече са си достигнали до максимума от 20 Peers. Тези, които се съгласяват да се свържат, обикновено са най-скапаните, с най-стари версии и с най-бавните интернет връзки. Само те са останали свободни, защото всеки друг избягва да се свързва с тях.

Крайният резултат се състои в това, че Walett-а ви не е в състояние да се свърже с поне 10 Peer-а от този стар и неактуален списък, което пък му забранява да провери в публичните сървъри за други актурални Peers. Това може би е някаква недомислица в логиката за подбор на Peers, и ние страдаме от нея. Нашите Walett-и циклят до безкрай из този неактуален списък и никога не достигат до следващия етап, който да им разреши да проверят в интернет и за други, по-актуални списъци.

Има 2 начина за разрешаването на този проблем:
1. В конфигурацията на Wallet-а да се намали бройката на Well Known Peers, с които е задължен да се свърже портфейла, преди да получи правото да търси и други Peers.
2. В конфигурацията на Wallet-а да се добави нов актуален списък с Well Known Peers

Аз избрах втория вариант, и добавих всички Well Known Peers от този линк: http://burstcoin.cc/node
Процедира се по следния начин:
1. Отваря се директорията на QBundle и след това се отваря нейната поддиректория conf
2. Старите и неактурални Peers се намират във файл nxt-default.properties, но разработчиците забраняват да се правят корекции в този файл
3. Разрешено е да се правят корекции само във файла nxt.properties, като ако има разминавания между двата файла, с приоритет се вземат настройките от nxt.properties
4. Отваря се линка http://burstcoin.cc/node
5. Най-отдолу на страницата в зелено има актуален списък на всички активни към момента Peers от мрежата на BURST, които са с отворени входове по порт 8123.
6. Копира се САМО БЛОКА от IP адреси, започвайки от реда с начало nxt.wellKnownPeers=........
7. Този блок се изсипва най-отзад на файла nxt.properties, без да се променят настройките в по-горните редове.
8. Рестартира се сервиса Burst Service
9. След около 10-15 секунди трябва във Wallet-a да се появят първите няколко Peers, а до 10-15 минути бройката им трябва да стане 20.
10. Масово тези Peers трябва да са с най-последната версия NRS 1.3.6cg
11. Допустими са 2-3 Peers с по-стара версия, но болшинството трябва да са последната версия.

Този процес с добавянето на нов актуален списък с Well Known Peers се прави само веднъж и никога повече. Това е така защото Wallet-а един път достигнал бройката от 10 конекции вече има правото да започне сам да си строи собствена база данни, и постепенно тя ще се напълни със стотици Peers, за които Wallet-а вече сам ще си поддържа тяхната актуалност и мрежови качества.

[Mateev]

Mateev как решаваш да пишеш за TargetDeadline 2592000 (30 дни) при соло копане, или това е закономерност. Също така например в http://burst.btfg.space/ трябва сам да си изчисляваш с вграденият им калкулатор какво ще пишеш за TargetDeadline на база броя на терабайтите с които копаеш, но там има смисъл защото пула е 0-100 и чакаш само от Historical Share.

Нарочно съм го оставил такова, защото по този начин във файловете stat.csv на компютрите ми се натрупва вярна информация за всяко едно Deadline, открито от всеки един компютър. Пределно ми е ясно, че няма шанс да спечеля блок с Deadline, по голямо от 1 час, но ако я направя тази настройка, моментално ще загубя статистиките по файловете stat.csv (ще са пълни предимно с нули).

Така че съжалявам, че натоварвам мрежата с някой друг излишен байт трафик, но тези статистики са ми необходими, и не искам да ги губя.

Освен това мрежата не се натоварва с кой-знае колко, защото още първия Peer, на който му кажа моята голяма DL веднага ще ми върне най-малката мрежова DL, и от този момент нататък моята копачка ще праща нещо към мрежата само ако намери някакъв още по-малък DL. Така че съжалявам - но забележката ти беше ненужна, още повече че е написана със заядлив тон, а не с въпросителен.

[Mateev]

Още малко информация за разликата между копането в пул и соло копане:

Когато се копае соло, намерените от DL-и се изпращат на мрежата, което всъщност означава, че се изпращат на 20 други компютъра. Всеки един от тях е свързан с още 20, които от своя страна са свързани с още 20. Ако се замислим, веднага ще се досетим, че информацията от един компютър най-много след 3-4 стъпки се научава от всички други компютри по света. Тоест процеса отнема максимум от половин до една секунда. Следователно публикуванеето в мрежата на каквато и да било DL след не повече от 1 секунда се научава от всички останали компютри по света, и всичките те без изключение започват да се съобразяват с нея. Тоест започват да отхвърлят по-големите DL, и да ретранслират в мрежата по-малките DL.

При това положение DL-ите, които прелитат през мрежата, още на първите 2-3 цикъла падат до ниво под 1 час, и най-вероятно прелитат още 5-6 цикъла докато се открие най-добрата DL в света. Дори и да пуснете в мрежата DL с период 1 милион години, то това ще е само 1 цикъл, и то само до първите 20 компютъра. Така че въобще не е прегрешение, ако силно увеличите настройката си за стойноста на минималната DL, която да се изпраща към мрежата. Мрежата въобще няма да се натовари допълнително, защото всеки един компютър по света е свързан с 20 други, и по тези връзки така или иначе си тече някакъв постоянен трафик. Няма да се натовари и нито един отделен конкретен компютър пак заради факта, че е ограничен до 20 конекции. Просто един цикъл в повече от всичките 7-8 цикъла на прелитане на DL-и, но той така или иначе си го има с нас или без нас.

По друг начин стоят нещата с пуловете. Те са ЗАДЪЛЖЕНИ да приемат и по-големи DL-и от най-ниския в момента, защото по тях те водят статистиката на отделните свои потребители. Следователно един пул получава не 7-8, а няколко хиляди DL-а при всеки един нов блок. И сървърите на пула наистина могат да се претоварят от многото конекции. Затова пуловете (а не BURST мрежата) са въвели изисквания за лимитиране на максималния DL, който може да им се изпраща. Това е с цел да реализират икономия от трафик и от процесорни ресурси, но тези икономии бъркат в джоба на потребителите, защото се губи справедливоста при разпределението на спечелените пари.

[Stoyan]

задрвейте за пробата вчера пуснах 300гб хард да копае но ми изписва error ReadFile. code=23 Unexpected and of file и ми изписва HDD,WAKE UP! вапроса ми е копае ли нещо или нищо не прави

[Mateev]

HDD WAKE UP е нормално съобщение. На всеки 3 минути копачката събужда диска, ако случайно е заспал при голямо време между 2 блока. Другото съобщение обаче казва, че с файла ти нещо не е наред. Вероятно не е плотнат до края или в него има повредени сектори. Аз ти предлагам да го изтриеш и да го плотнеш отново, като по време на плотването не трябва да спираш компютъра. Ако тока мигне и компютъра спре аварийно, започваш пак отначало - триене и плотване отново.

[Stoyan]

благодаря сега ще пробвам

[Joro_]

Интересна логика. Малко хора се замислят върху последното написано от Mateev

[Mateev]

На практика един готов плотнат файл се състои от 4096 участъка с Nonce-та, като по време на копането за всеки блок се чете само един от тези участъци. Самата копачка по време на тръгването си няма как да провери, дали всичките 4096 участъка са коректно записани. Затова тя прави някакви минимални бързи проверки, като например дали дължината на файла отговаря на декларираната такава в неговото име. Всякакви други грешки ще бъдат открити чак когато му дойде времето да се чете даден участък, но това може да се случи след дни или дори месеци.

Аз имам подобни проблеми - от време на време Proxy копачката ми казва, че е открита някаква странна DL, която или е много къса или е плод на повредени сектори от някой файл. За съжаление диагностиката ми е почти невъзможна - имам над 1000 плотнати файла, разпилени по над 40 компютъра. И това се случва въпреки че много внимавах при плотването да не допусна такова нещо, но явно съм го допуснал.

За който не му се чете отново цялата тема, пак ще повторя накратко:
Ако по време на плотването процеса се прекъсне коректно посредством коректно затваряне на плотера, то тогава при следващото му пускане той продължава от там, докъдето е стигнал предишния път. Ако обаче компютъра спре аварийно при мигване на тока, след рестарта плотера пак продължава от там, докъдето е стигнал, но във файла остават повредени участъци. Това е така защото се е загубила информацията от кеша на Windows-а, който не е успял да се запише на диска при мигването на тока.

После при копането файла привидно изглежда изряден и с него се копае нормално, но от време на време когато копачката поиска четене на повредените участъци, появява се грешка за некоректен DL.

[-X5]

За проверка на плотнатите файлове може да се използува това:https://github.com/Blagodarenko/PlotsChecker/releases
Проверката отнема секунди.

[Mateev]

Благодаря за линка и за програмата.
Не знаех за нея .....

Само да спомена, че програмата трябва да се пуска с BAT файл, в който са оказани всички пътища, в които има BURST файлове. Също така трябва да се пуска с опцията Run As Administrator, за да може ако намери повреден файл, да му смени името.

Ето какъв BAT файл си сглобих набързо, за да мога без да го променям да го пускам по всички компютри. При мене на различните компютри плотнати файлове има по различни дискове, но общото между всички е, че директорията винаги се казва BURST. Затова и във BAT файла проверявам по абсолютно всички възможни букви на дискове за точно тази директория:

Код за потвърждение: Избери целия код

@setlocal
@cd /d %~dp0
@PlotsChecker.exe C:\BURST
@PlotsChecker.exe D:\BURST
@PlotsChecker.exe E:\BURST
@PlotsChecker.exe F:\BURST
@PlotsChecker.exe G:\BURST
@PlotsChecker.exe H:\BURST
@PlotsChecker.exe I:\BURST
@PlotsChecker.exe J:\BURST
@PlotsChecker.exe K:\BURST
@PlotsChecker.exe L:\BURST
@PlotsChecker.exe M:\BURST
@PlotsChecker.exe N:\BURST
@PlotsChecker.exe O:\BURST
@PlotsChecker.exe P:\BURST
@PlotsChecker.exe Q:\BURST
@PlotsChecker.exe R:\BURST
@PlotsChecker.exe S:\BURST
@PlotsChecker.exe T:\BURST
@PlotsChecker.exe U:\BURST
@PlotsChecker.exe V:\BURST
@PlotsChecker.exe W:\BURST
@PlotsChecker.exe X:\BURST
@PlotsChecker.exe Y:\BURST
@PlotsChecker.exe Z:\BURST
@pause


За да заработи коректно този BAT файл (кръстил съм го CheckPlots.bat), трябва да се сложи в една и съща директория заедно с файла PlotsChecker.exe.