bobafett
|
|
November 15, 2014, 04:28:49 PM |
|
could blago miner be used for devs v2 pool?
|
|
|
|
Blago
|
|
November 15, 2014, 04:41:54 PM Last edit: November 15, 2014, 05:00:26 PM by Blago |
|
could blago miner be used for devs v2 pool?
Yes. [miner]new update miner-burst-1.141115https://www.dropbox.com/s/nvyaw0md2qpb4om/miner-burst-1.141115.zip?dl=0changes: + 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
|
Relax, I’m russian!... BURST-B2LU-SGCZ-NYVS-HZEPK
|
|
|
bobafett
|
|
November 15, 2014, 04:46:16 PM |
|
blago, you are great.
do i have to update also my proxys oder is it enought to update the master?
Best Regards boba
|
|
|
|
Blago
|
|
November 15, 2014, 04:49:10 PM |
|
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
|
Relax, I’m russian!... BURST-B2LU-SGCZ-NYVS-HZEPK
|
|
|
bobafett
|
|
November 15, 2014, 05:08:48 PM |
|
seems to work for me now. i give now the devs v2 pool a try......
again. perfect work blago!
|
|
|
|
equipoise
|
|
November 15, 2014, 08:03:36 PM |
|
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
Sr. Member
Offline
Activity: 267
Merit: 250
6th BTC reached. Thank you for your support
|
|
November 15, 2014, 08:31:40 PM |
|
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
|
|
November 15, 2014, 08:47:12 PM |
|
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
Full Member
Offline
Activity: 248
Merit: 100
I'm not real
|
|
November 15, 2014, 08:57:08 PM |
|
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
|
|
November 15, 2014, 09:24:53 PM Last edit: November 15, 2014, 09:40:21 PM by 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: 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
Full Member
Offline
Activity: 248
Merit: 100
I'm not real
|
|
November 15, 2014, 10:51:35 PM |
|
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
|
|
November 16, 2014, 05:07:34 AM |
|
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: 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.
|
Relax, I’m russian!... BURST-B2LU-SGCZ-NYVS-HZEPK
|
|
|
vipervince2002
Newbie
Offline
Activity: 22
Merit: 0
|
|
November 16, 2014, 06:57:29 AM Last edit: November 16, 2014, 07:08:41 AM by 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
|
|
November 16, 2014, 09:47:43 AM |
|
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: 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
Newbie
Offline
Activity: 44
Merit: 0
|
|
November 16, 2014, 09:53:15 AM |
|
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
|
|
November 16, 2014, 11:51:55 AM |
|
But pool pays only for last 2000 deadlines when it find block (PPLNS).
|
Russia
|
|
|
Blago
|
|
November 16, 2014, 03:48:27 PM |
|
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
|
Relax, I’m russian!... BURST-B2LU-SGCZ-NYVS-HZEPK
|
|
|
|
paduser
|
|
November 16, 2014, 04:22:15 PM |
|
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.
|
|
|
|
|
|