[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000

[bobafett]

could blago miner be used for devs v2 pool?

[Blago]

could blago miner be used for devs v2 pool?

Yes.

[miner]

new update miner-burst-1.141115
https://www.dropbox.com/s/nvyaw0md2qpb4om/miner-burst-1.141115.zip?dl=0

changes:
+ Added support for V2 pool  ("poolV2")


   "Mode" : "poolV2",
   "Server" : "178.62.39.204",
   "Port": 8121,
   "UpdaterAddr" : "178.62.39.204",
   "UpdaterPort": 8121,




*** only 1 day tested

and for V2-users I recommend the program Burst pool V2 stats by Tex81 https://bitcointalk.org/index.php?action=profile;u=183813   for check your progress
https://www.dropbox.com/s/grl0ozlbzwwqi1q/Pool2%20stats.exe?dl=0

[bobafett]

blago, you are great.

do i have to update also my proxys oder is it enought to update the master?

Best Regards
boba

[Blago]

blago, you are great.

do i have to update also my proxys oder is it enought to update the master?

Best Regards
boba

update only the master

[bobafett]

seems to work for me now. i give now the devs v2 pool a try......

again. perfect work blago!

[equipoise]

I now have those plots:
Plot 1: X:\plots\XXXXXXXXXXXXXXXXXXX_10000001_4368000_8000 - 1.04 TB
Plot 2: X:\plots\XXXXXXXXXXXXXXXXXXX_15000001_4368000_8000 - 1.04 TB
Plot 3: X:\plots\XXXXXXXXXXXXXXXXXXX_20000001_2704000_8000 - 660 GB
Plot 4: Z:\plots\XXXXXXXXXXXXXXXXXXX_1_4000000_8000 - 976 GB
Plot 5: Z:\plots\XXXXXXXXXXXXXXXXXXX_4000001_3624000_8000 - 884 GB
Plot 6: Y:\plots\XXXXXXXXXXXXXXXXXXX_8000001_1904000_8000 - 464 GB

Now my X, Y and Z hard disks are full and those plots takes forever to read. I have 320GB free on another drive. Could anyone tell me how I could optimize those plots without recalculating the plots (which also takes forever) or with the minimum possible recalculation? Thank you.

[boliu]

Only 3 more minutes, and my 771 deadline will give me the first block in nearly 2 days. Everyone pls stay off the network ;-)

NOOOooooooo

I feel your pain.   My 89 deadline was snatched by a 32.

[pinballdude]

Only 3 more minutes, and my 771 deadline will give me the first block in nearly 2 days. Everyone pls stay off the network ;-)

NOOOooooooo

I feel your pain.   My 89 deadline was snatched by a 32.

yea' 10 mins ago my 231 deadline was taken out by something slightly faster. it's 2+ days since i got a block. I usually get 3-7 of them each day. randomness suck sometimes ;-)

[FakeAccount]

Only 3 more minutes, and my 771 deadline will give me the first block in nearly 2 days. Everyone pls stay off the network ;-)

NOOOooooooo

I feel your pain.   My 89 deadline was snatched by a 32.

how did you figure out that you were beaten by a 32?

[mmmaybe]

could blago miner be used for devs v2 pool?

Yes.

[miner]

new update miner-burst-1.141115
https://www.dropbox.com/s/nvyaw0md2qpb4om/miner-burst-1.141115.zip?dl=0

changes:
+ Added support for V2 pool  ("poolV2")


   "Mode" : "poolV2",
   "Server" : "178.62.39.204",
   "Port": 8121,
   "UpdaterAddr" : "178.62.39.204",
   "UpdaterPort": 8121,


*** only 1 day tested

blago, I tested this. I'm not sure if it submits all valid shares when using proxy mode. If the miner receives a low deadline first the following valid shares aren't sent to the pool, it seems. An example:

Code:

21:55:31 [ 21947873133127455279] confirmed DL
[100%] 6479 GB. DL: 113303s     sdl:8(0) cdl:8(0) ss:537(0) rs:537(0)

--- 21:58:38 ---    New block 34466, basetarget 3432597    ------------
21:58:44 [ 21947873133127455279] sent DL:            9618     0d 02:40:18
21:58:44 [ 21947873133127455279] confirmed DL
21:58:49 [ 21947873133127455279] received DL:      137584 {10.0.0.6}
21:58:50 [ 21947873133127455279] received DL:       79086 {10.0.0.8}
[100%] 6479 GB. DL: 9618s       sdl:9(0) cdl:9(0) ss:579(0) rs:579(0)

--- 22:00:05 ---    New block 34467, basetarget 3369942    ------------
22:00:14 [ 21947873133127455279] received DL:      159686 {10.0.0.6}

Deadlines 137584 and 79086 weren't sent in block 34466?

Edit:
In non-proxy mode, when connecting all miners directly to the pool, something similar might be evident. If the miner finds a low deadlines first, the following deadlines are only sent if they are lower than the first, even  if the miner finds valid shares for the pool (below required pool deadline)

Thanks  

[FakeAccount]

I hope i'm not imagining, but so far every re-plotted file has stopped producing low deadlines and no more blocks have been found by any re-plotted file in windows.

. . .

original file got deleted. (which I didn't like since I had to re-create oroginal file again... maybe it would be better to create a parameter to control this?)

i did not use any delaying.  just specified 1 gig of memory

2 scoops

don't know if every plot.  can try on another plot, but first need to make a copy of it since I don't want to lose the original plot, so this will take some time.

using this works OK: Optimizer.exe 30 Y:\plots -m 4g X:\plots\XXXXXXXXXXXXXXXXXXX_XXXXXXXXX_XXXXXXX_XXXX

re-plotted file is working OK.  correct deadlines are found, submitted and verified. sorry it took a while to test on a different file with different parameters. this was tested not using 1.6 but prior ver.

I am glad to hear it is working now. 1.6 was only a small update to prevent deleting and the plot file should not be any different from the previous versions.

[Blago]

blago, I tested this. I'm not sure if it submits all valid shares when using proxy mode. If the miner receives a low deadline first the following valid shares aren't sent to the pool, it seems. An example:

Code:

21:55:31 [ 21947873133127455279] confirmed DL
[100%] 6479 GB. DL: 113303s     sdl:8(0) cdl:8(0) ss:537(0) rs:537(0)

--- 21:58:38 ---    New block 34466, basetarget 3432597    ------------
21:58:44 [ 21947873133127455279] sent DL:            9618     0d 02:40:18
21:58:44 [ 21947873133127455279] confirmed DL
21:58:49 [ 21947873133127455279] received DL:      137584 {10.0.0.6}
21:58:50 [ 21947873133127455279] received DL:       79086 {10.0.0.8}
[100%] 6479 GB. DL: 9618s       sdl:9(0) cdl:9(0) ss:579(0) rs:579(0)

--- 22:00:05 ---    New block 34467, basetarget 3369942    ------------
22:00:14 [ 21947873133127455279] received DL:      159686 {10.0.0.6}

Deadlines 137584 and 79086 weren't sent in block 34466?

Edit:
In non-proxy mode, when connecting all miners directly to the pool, something similar might be evident. If the miner finds a low deadlines first, the following deadlines are only sent if they are lower than the first, even  if the miner finds valid shares for the pool (below required pool deadline)

Thanks  

The server counts only the best deadline.
In your case the first was sent to 9618, which is less than 137584 and 79086 , so the others were not sent.

[vipervince2002]

Blago, I have a feature request for your miner.  Can the program create a text file (or .csv file) that contains only the line with the best deadlines for each row?  

From your last post, it appears that the best deadline is the only one submitted.  This means that the code can write to the text file right after submission or if necessary, while it is on the same block, keep appending to the same line until the block changes.  Since not all blocks reach 100% scan, some deadlines may not be written, but that would be fine for the file's purpose.  

The reason for the text file is to allow users to load it in Excel and get important statistics like average deadline and standard deviation.  From this information, the community can piece together an approximate payout per pool for a certain plotting size range(1-2 TB, 2-5 TB, etc.).  A size range is needed because most of the pools give shares based on an exponential formula and an average burst per TB for each pool would vary based on total plotted size.  Each pool has its own formula and the complaints to go with it. This new feature may help the pool devs refine their formulas and give the community a better idea of which pool to mine on.  I see a non-writable (except for the creator and a select few) Google Docs file with the statistics of the community from posts on this forum (assuming they back up their numbers with Excel chart pictures).


FakeAccount, your plots should be fine since my plots seem to work.  What I found was throwing off my deadlines was my system clock.  After syncing it manually to internet time, my deadlines got much better and this leads to my other feature request.  My system clock is really bad at keeping time despite changing the battery on the motherboard about a year ago.  My solution was to download a program here: http://www.worldtimeserver.com/atomic-clock/.  I have been varying my update interval between 10 minutes and 1 hour.  Unfortunately, syncing while the miner is looking for a block seems to be a bad idea and ruins my deadline for that block (although I have no proof of this except some blocks with a best deadline of thousands of days).  

My second proposed feature is to make an option for the miner to try syncing the system clock between blocks.  The two issues that I can see with this possible feature is that a program requires admin access to sync the clock and the other issue is if a new block happens to begin at the same moment that it is syncing.  For these reasons, the default option would have to be off.  Alternatively, I will keep using the program that I have been using already.  

On a side note, cryo's newest GPU plotter creates optimized plots if using the direct writing option.  Don't freak out if the progress stays at 0% for a while because it will start updating the progress once the plot file size reaches the output size.  Cryo will probably fix this in a future update once he bases the initial progress meter on the size of the file before basing the meter on the number of scoops plotted *hint hint to cryo.

[mmmaybe]

blago, I tested this. I'm not sure if it submits all valid shares when using proxy mode. If the miner receives a low deadline first the following valid shares aren't sent to the pool, it seems. An example:

Code:

21:55:31 [ 21947873133127455279] confirmed DL
[100%] 6479 GB. DL: 113303s     sdl:8(0) cdl:8(0) ss:537(0) rs:537(0)

--- 21:58:38 ---    New block 34466, basetarget 3432597    ------------
21:58:44 [ 21947873133127455279] sent DL:            9618     0d 02:40:18
21:58:44 [ 21947873133127455279] confirmed DL
21:58:49 [ 21947873133127455279] received DL:      137584 {10.0.0.6}
21:58:50 [ 21947873133127455279] received DL:       79086 {10.0.0.8}
[100%] 6479 GB. DL: 9618s       sdl:9(0) cdl:9(0) ss:579(0) rs:579(0)

--- 22:00:05 ---    New block 34467, basetarget 3369942    ------------
22:00:14 [ 21947873133127455279] received DL:      159686 {10.0.0.6}

Deadlines 137584 and 79086 weren't sent in block 34466?

Edit:
In non-proxy mode, when connecting all miners directly to the pool, something similar might be evident. If the miner finds a low deadlines first, the following deadlines are only sent if they are lower than the first, even  if the miner finds valid shares for the pool (below required pool deadline)

Thanks  

The server counts only the best deadline.
In your case the first was sent to 9618, which is less than 137584 and 79086 , so the others were not sent.

Perhaps I've misunderstood how dev's pool2 works, but I was under the impression that it counts all deadlines under 200k sec and that you get payments relative the number of valid shares you have sub-200k, not for your best deadline. That's why I asked.

Can someone, perhaps burstcoin, clarify how it's designed...?

[majere]

Perhaps I've misunderstood how dev's pool2 works, but I was under the impression that it counts all deadlines under 200k sec and that you get payments relative the number of valid shares you have sub-200k, not for your best deadline. That's why I asked.
Can someone, perhaps burstcoin, clarify how it's designed...?

That is correct. It needs all deadlines below target deadline.

[tex81]

But pool pays only for last 2000 deadlines when it find block (PPLNS).

[Blago]

Perhaps I've misunderstood how dev's pool2 works, but I was under the impression that it counts all deadlines under 200k sec and that you get payments relative the number of valid shares you have sub-200k, not for your best deadline. That's why I asked.
Can someone, perhaps burstcoin, clarify how it's designed...?

That is correct. It needs all deadlines below target deadline.

Then it is better not to use a proxy

[hashes4.me]

Played a bit around, if someone wants to know what aliases are taken -> http://pastebin.info/?paste=106
And the Top 250 Burst Holders -> http://pastebin.info/?paste=107

[paduser]

Played a bit around, if someone wants to know what aliases are taken -> http://pastebin.info/?paste=106
And the Top 250 Burst Holders -> http://pastebin.info/?paste=107

Good job. Would be nice to have a site with a live or daily update on the most Burst holderst. Maybe once I will be under them.

[FakeAccount]

Played a bit around, if someone wants to know what aliases are taken -> http://pastebin.info/?paste=106
And the Top 250 Burst Holders -> http://pastebin.info/?paste=107

Good job. Would be nice to have a site with a live or daily update on the most Burst holderst. Maybe once I will be under them.

here you go: http://burstcoin.eu/charts/addresses-by-balance