|
Merick
|
 |
January 30, 2015, 02:49:49 PM |
|
...
So far it's running just fine for a day now. I run through plot_optimizer_1.6-j6jq... does it really help speed up hashing when optimizing plot? Thanks again. Optimizing your plots will decrease the amount of time it takes to scan through all of them and potentially find a block before someone else. An example: It takes your computer 3 minutes to check all of the unoptimized plot files and you will have a deadline of 1 minute after 2.5 minutes of scanning. Someone else may have a deadline of 2 minutes after 1.5 minutes of scanning. The other person will get the block reward despite having a worse deadline because your deadline will never have a chance to submit. You also won't know you missed a block because it will start scanning for the next block. An optimized plot may find the deadline of 1 minute after 45 seconds of scanning and you would receive the block reward. (Made the numbers up, but you get the idea) To answer your question, it will speed up hashing in a matter of speaking, but in terms of hashrate as you think of BTC, then no, your overall "hashrate," or chance of finding a block, will not increase. In the example above, you would eventually find the block either way assuming no one beats you to it, but an optimized plot would find it faster. I also updated the plot optimizer with a GUI in the Burst forum: https://burstforum.com/index.php?threads/plot-optimizer-gui-1-0-6.589/I have heard of someone with 10x faster reading with optimized high stagger plots vs. low stagger plots. I would defo recommend optimizing!!! This comparison was done with two WD RED 3TB drives. One drive contained a 890GB plot file with a stagger of 1024 the other drive contained a 890GB plot file that was optimized. Watching iostat and sysmon the non staggered file would read at ~5.5MB/sec while the optimized file would read at ~55MB/sec. My 1024 file was waiting to be optimized hence I did not care about the ultra low stagger, but this does give a good representation of optimized vs un-optimized results. The next test would be to repeat this but with increase stagger sizes by 1024 each run to create a stagger vs MB/sec graph. I'm guessing this graph will start to roll off at a particular stagger size. This would verify the possibility of diminishing returns when comparing different staggers with an optimized file. I only have 8GB ram so I cannot do a very thorough check. If I don't see this type of graph posted on the forums I will try and produce one from 1024 to 8192 stagger and see what happens. Happy Bursting.  |
|
|
|
|
vaxman
Member
 Offline
Activity: 99
Merit: 10
|
|
January 30, 2015, 03:05:58 PM |
|
Speaking of java problems, it seems as though the wallet has a memory leak... I've had one open over a week and it's slowly creeping up on memory usage. It's at about 2GB right now, which is starting to interfere with mining (I mine with 8GB of memory).
Hm, varies a lot here. I have 3 wallets running; 1. 10 days uptime, 800 MB used of 2 GB assigned - running NAT'ed 2. 30 hours uptime, 298 MB used of 8 GB assigned - this has a fixed IP and the "nxt.myAddress=" configured, so directly reachable for other peers 3. 10 days uptime, 540 MB used of 8 GB assigned - this is also on fixed IP with "nxt.myAddress=" configured -?- |
|
|
|
|
|
bensam123
|
|
January 30, 2015, 03:21:01 PM |
|
do you guys know why versions of balgo miner for windows donot work proprietly in my computer i got only version from deceber working i need a better version if possible do contact me for issues if possible here
What exactly is not working? PM to me screenshots and miner's version Not sure about him, but I'm still running into the "Microsoft Visual C++ Runtime Library - R6010 Abort() has been called". Just had it happen again today. May I know what is your OS version, 32 bits or 64 bits? Windows 8.1 x64 When trying to use the 'direct write' feature of the GPU plotter, is it normal when writing a 5 TB plot the program will not output anything, but continue writitng to the disk then when it reaches the second phase it starts outputting text again, but the nonces/s seems completely off? It also seems like it's all random I/Os. Is there anyway to help with this? My 5TB disks are slower 5,900 RPM, so constant seeks means the plotting goes really slow. While using direct write it seems as though the graphics cards aren't even really used because everything goes so slow (looking at utilization in MSI afterburner). I'm going on close to four days and it finally reached the second stage today, but it's still really slow. I think it'll probably finish in the next day or two at the current speed. Using the same rig I was able to plot with 'buffer' at 60k nonces/s |
|
|
|
|
|
burstcoin (OP)
|
|
January 30, 2015, 03:37:44 PM |
|
|
BURST-QHCJ-9HB5-PTGC-5Q8J9
|
|
|
|
lagur
|
|
January 30, 2015, 03:50:20 PM |
|
...
So far it's running just fine for a day now. I run through plot_optimizer_1.6-j6jq... does it really help speed up hashing when optimizing plot? Thanks again. Optimizing your plots will decrease the amount of time it takes to scan through all of them and potentially find a block before someone else. An example: It takes your computer 3 minutes to check all of the unoptimized plot files and you will have a deadline of 1 minute after 2.5 minutes of scanning. Someone else may have a deadline of 2 minutes after 1.5 minutes of scanning. The other person will get the block reward despite having a worse deadline because your deadline will never have a chance to submit. You also won't know you missed a block because it will start scanning for the next block. An optimized plot may find the deadline of 1 minute after 45 seconds of scanning and you would receive the block reward. (Made the numbers up, but you get the idea) To answer your question, it will speed up hashing in a matter of speaking, but in terms of hashrate as you think of BTC, then no, your overall "hashrate," or chance of finding a block, will not increase. In the example above, you would eventually find the block either way assuming no one beats you to it, but an optimized plot would find it faster. I also updated the plot optimizer with a GUI in the Burst forum: https://burstforum.com/index.php?threads/plot-optimizer-gui-1-0-6.589/I have heard of someone with 10x faster reading with optimized high stagger plots vs. low stagger plots. I would defo recommend optimizing!!! This comparison was done with two WD RED 3TB drives. One drive contained a 890GB plot file with a stagger of 1024 the other drive contained a 890GB plot file that was optimized. Watching iostat and sysmon the non staggered file would read at ~5.5MB/sec while the optimized file would read at ~55MB/sec. My 1024 file was waiting to be optimized hence I did not care about the ultra low stagger, but this does give a good representation of optimized vs un-optimized results. The next test would be to repeat this but with increase stagger sizes by 1024 each run to create a stagger vs MB/sec graph. I'm guessing this graph will start to roll off at a particular stagger size. This would verify the possibility of diminishing returns when comparing different staggers with an optimized file. I only have 8GB ram so I cannot do a very thorough check. If I don't see this type of graph posted on the forums I will try and produce one from 1024 to 8192 stagger and see what happens. Happy Bursting. This make sense a lot. Now if only I could find more space for the optimized plot! Thanks! |
|
|
|
|
|
mmmaybe
|
|
January 30, 2015, 04:19:06 PM |
|
Very nice, that made my day! |
|
|
|
|
mmmaybe
|
|
January 30, 2015, 04:30:54 PM |
|
Just a perfect day.
Just a perfect day in the park.
Just a question and an answer, some day, somewhere: We have a plan. You will get a guide/Manuel. But some things are more important atm Join the PR Team and you understand...
How to join?
Am I qualified to join?
I often think we (forum and me) are in a competition, so I rather stayed in the background. We both have similar assets, we both operate a pool, ...
If that is not an objection, ... I can join!
You can...? Read this, https://bitcointalk.org/index.php?topic=731923.msg10248577#msg10248577 , it's enough if you email burst@countermail.com. It might not be me answering but we'll establish a dialog about membership and Burst-work - we are still terribly understaffed and your email is very welcome, as are others'. Would every Burster spend 20 minutes a day working with us, the price would be completely different, even if you might find those 20 minutes meaningless when doing them occasionally. Yesterday I and a few more did 22h Burst work straight (without payment); I had to stay home from work today due to that. I'm not really complaining as we still have much fun, just saying it could look way different.
It's such a perfect day
I'm glad I spent it with you
Such a perfect day
You just keep me hanging on
|
|
|
|
FakeAccount
Full Member
Offline
Activity: 248
Merit: 100
I'm not real
|
|
January 30, 2015, 04:37:16 PM |
|
...
So far it's running just fine for a day now. I run through plot_optimizer_1.6-j6jq... does it really help speed up hashing when optimizing plot? Thanks again. Optimizing your plots will decrease the amount of time it takes to scan through all of them and potentially find a block before someone else. An example: It takes your computer 3 minutes to check all of the unoptimized plot files and you will have a deadline of 1 minute after 2.5 minutes of scanning. Someone else may have a deadline of 2 minutes after 1.5 minutes of scanning. The other person will get the block reward despite having a worse deadline because your deadline will never have a chance to submit. You also won't know you missed a block because it will start scanning for the next block. An optimized plot may find the deadline of 1 minute after 45 seconds of scanning and you would receive the block reward. (Made the numbers up, but you get the idea) To answer your question, it will speed up hashing in a matter of speaking, but in terms of hashrate as you think of BTC, then no, your overall "hashrate," or chance of finding a block, will not increase. In the example above, you would eventually find the block either way assuming no one beats you to it, but an optimized plot would find it faster. I also updated the plot optimizer with a GUI in the Burst forum: https://burstforum.com/index.php?threads/plot-optimizer-gui-1-0-6.589/java 8 64 bit, dbl clicking causes: "A Java Exception has occurred." |
|
|
|
|
|
lagur
|
|
January 30, 2015, 04:51:22 PM
Last edit: January 30, 2015, 05:48:11 PM by lagur |
|
New question guys regarding multiple plot files. I started with a 250GB for testing...
wplotgenerator {id} 0 900000 32000 8
How do I create a 2nd 250gb, like these?
wplotgenerator {id} 900001 1800001 32000 8Ok nevermind, just figured  |
|
|
|
|
|
Equate
|
|
January 30, 2015, 05:37:05 PM |
|
Great news , burst getting more attention. |
|
|
|
|
|
xizmax
|
|
January 30, 2015, 05:44:07 PM |
|
New question guys regarding multiple plot files. I started with a 250GB for testing...
wplotgenerator {id} 0 900000 32000 8
How do I create a 2nd 250gb, like these?
wplotgenerator {id} 900001 1800001 32000 8
Short and simple answer. Yes |
|
|
|
|
Merick
|
|
January 30, 2015, 06:01:54 PM |
|
New question guys regarding multiple plot files. I started with a 250GB for testing...
wplotgenerator {id} 0 900000 32000 8
How do I create a 2nd 250gb, like these?
wplotgenerator {id} 900001 1800001 32000 8
Short and simple answer. Yes I just want to convert your settings into english. you started at 0 and created 900000 nonces with a stagger of 32000 using 8 threads, ( this should be a ~220GB) file Next start at 900001 create 1800001 nonces with a stagger of 32000 using 8 threads. So. You wanted to create a 250GB plot file, in order to do this you need to create 1,024,000 nonces but your second line is going to create 1,800,001 nonces., so your second command is not going to do what you want. wplotgenerator <account id> <start nonce> <number of nonces> <stagger size> <threads> https://burstforum.com/index.php?threads/new-plotter-for-windows.114If you want to create a plot file that is 250GB then you will need to use wplotgenerator <account id> <start nonce> <number of nonces> <stagger size> <threads> wplotgenerator <account id> 900001 1024000 32000 8 Link on Nonce size and calculating plot file size https://burstforum.com/index.php?threads/windows-gpu-plotter-walk-through.54/page-3#post-4614Please, someone tell me if I am wrong I don't like to spread misleading information. |
|
|
|
|
|
fastBeast
|
|
January 30, 2015, 06:44:31 PM |
|
GREAT!!! i love the burst_db link!!! really useful!!! many thank!!! |
|
|
|
|
|
hefty
|
|
January 30, 2015, 07:36:30 PM |
|
i want to mine this coin but i dont know where to start, can some of you provide me with a link how to install wallet and start mining step by step for like dummies thank you |
|
|
|
|
|
|
hefty
|
|
January 30, 2015, 07:41:45 PM |
|
Thank You so much  |
|
|
|
|
|
|
Blazin604
|
|
January 30, 2015, 08:53:32 PM |
|
Hello all I am new to burst. is this the only poc coin?....very undervalued |
|
|
|
unsoindovo
Legendary
Offline
Activity: 1932
Merit: 1042
https://locktrip.com/?refId=40964
|
|
January 30, 2015, 09:20:01 PM |
|
i continue to get this error.. wallet 1.2.1 how i can fix it? thanks!!!  |
|
|
|
|
daWallet
|
|
January 30, 2015, 09:25:41 PM |
|
i continue to get this error..
wallet 1.2.1
how i can fix it?
thanks!!!
Don't worry. It's just debug information of the Automated Transactions. They said in the next release it won't be there. |
github/dawallet Burst Client for Win & Burstcoin.biz
|
|
|
|
