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

[Dzus1k]

My file size is 2 558 720 000 kB so I end at number 9 995 000.

So edited run_generate should be now -

C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate 3243305246736502377 9996000 20800000 1000 4 ?

or better

C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate 3243305246736502377 10000000 20800000 1000 4 ?

So if you've generated 9 995 000 and you wanted to generate a total of 20 800 000 then the amount you have left to generate is 20 800 000 - 9 995 000 = 10 805 000.

So, with the command being:

C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate accountNumber startingNonce numberOfNoncestoPlot staggerSize threads

You'd want:

C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate 3243305246736502377 10000000 10805000 1000 4

okay thanks, started it now like a that then.

So now I see it generate new file from 10 000 000.

Before when I was generating that file I was also mining it. How can I mine that both files at once now ?

[bitminer82]

okay thanks, started it now like a that then.

So now I see it generate new file from 10 000 000.

Before when I was generating that file I was also mining it. How can I mine that both files at once now ?

As long as the plot files are in the same folder it will check one, then the other.  You don't need to do anything.

[Blank]

I made the mistake of using a weak passphase and some douche has been stealing my Burst.
Is it possible to change the passphrase for the plot i have already generated?
From my understanding it's not possible and i would need to create a new account with a much stronger passphrase then start from scratch.

Although it's kinda my fault for only using a crappy password really i just put a simple password in to try and get this mining working and would have changed it later if it worked out to be worth it. Still disappointed in humanity though.

[Dzus1k]

okay thanks, started it now like a that then.

So now I see it generate new file from 10 000 000.

Before when I was generating that file I was also mining it. How can I mine that both files at once now ?

As long as the plot files are in the same folder it will check one, then the other.  You don't need to do anything.

Sure . Thank you all for help. Really appreciate it.

[regtable69]

I made the mistake of using a weak passphase and some douche has been stealing my Burst.
Is it possible to change the passphrase for the plot i have already generated?
From my understanding it's not possible and i would need to create a new account with a much stronger passphrase then start from scratch.

Although it's kinda my fault for only using a crappy password really i just put a simple password in to try and get this mining working and would have changed it later if it worked out to be worth it. Still disappointed in humanity though.

you could always make a new account ans send all the burst asap to it.

[jamoes]

Burstcoin difficulty continues to explode. The total plot size has been growing at an exponential rate since launch, and it doesn't appear that trend is breaking anytime soon:





Last time I posted these charts, I predicted we'd hit 10 PB on sept. 15th, and the 360-block moving average would hit 10 PB by sept. 17th. It's now looking like I might have been a little aggressive with those predictions, but they still might hit. Especially if growth continues as it is doing today.

It's interesting to see that it seems that difficulty doesn't seem to grow much on Sundays. The past two Sundays have seen very low growth of the total network plot size. Maybe this is because UPS and Fedex tend to not deliver on Sundays... It'll be interesting to see if this trend continues next Sunday.

[Alpinist]

Can anybody help?

What does it mean???
//16Gb RAM. 2*4TB HDD.//

"Uncaught error from thread [Uncaught error from thread [default-akka.actor.defau
lt-dispatcher-2] shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabl
ed for ActorSystem[default]
default-akka.actor.default-dispatcher-4] shutting down JVM since 'akka.jvm-exit-
on-fatal-error' is enabled for ActorSystem[default]
java.lang.OutOfMemoryError: Java heap space"

[regtable69]

Burstcoin difficulty continues to explode. The total plot size has been growing at an exponential rate since launch, and it doesn't appear that trend is breaking anytime soon:





Last time I posted these charts, I predicted we'd hit 10 PB on sept. 15th, and the 360-block moving average would hit 10 PB by sept. 17th. It's now looking like I might have been a little aggressive with those predictions, but they still might hit. Especially if growth continues as it is doing today.

It's interesting to see that it seems that difficulty doesn't seem to grow much on Sundays. The past two Sundays have seen very low growth of the total network plot size. Maybe this is because UPS and Fedex tend to not deliver on Sundays... It'll be interesting to see if this trend continues next Sunday.

im buying 40 tb tomorrow and plotting them on sundays only :-)

[SpeedDemon13]

Been running fine for me at a stagger size of 4096 and 128 thread. While system ram usage is at 6GB out of 8GB. I had issue with my miner closing, so I upped the heap size from 750 to 1024 and it's mining fine now.

Heap size?

The miner would crash after a period of time. The -Xmx in the miner is default 750, I put 1024 and it hasn't gave me any issues since.

[bitminer82]

The GPU plot generator v2.0.0 will allow you to do that. I will release it in few hours at most. Be patient

 

Will this also fix the weird double memory problem?

I was able to plot up to 2024 stagger with my 3GB 280x but anymore than that and I get the CL error.  Strange thing is that looking at MSI Afterburner I'm only using 1.1GB on the card and less than 20% of my system RAM.

The time it takes to look through the plots for valid shares is related to stagger size, right?  I'm noticing that my systems aren't always able to go through all my plots before the end of some blocks.  Most of my plots are at stagger 1000 because I was having problems going any higher with the Java miner.

The "weird" double memory problem is due to the limited amount of local memory for each workgroup thread on the GPU side (it would require more than 260KB per thread, what is really big in the graphic cards world). The only way I found for now is to allocate another huge buffer (of (PLOT_SIZE + 16) * staggerSize bytes) that each workgroup thread can use to store the processing data. Thus, the amount of memory needed by the GPU plot generator is more than twice the normal amount.
One solution to avoid this memory overhead is to find a mean to do the last algorithm step in an on-place fashion. I will try to work on that and on the kernel enhancement (to speed things up even more :p) for the 2.1.0 version.

I get the error "[-61] Unable to create the OpenCL GPU generation buffer" with any stagger sizes above about 2000.  Is that because of this memory problem or something else?

[fivebells]

Can anybody help?

What does it mean???
//16Gb RAM. 2*4TB HDD.// [Running two miners]

"Uncaught error from thread [Uncaught error from thread [default-akka.actor.defau
lt-dispatcher-2] shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabl
ed for ActorSystem[default]
default-akka.actor.default-dispatcher-4] shutting down JVM since 'akka.jvm-exit-
on-fatal-error' is enabled for ActorSystem[default]
java.lang.OutOfMemoryError: Java heap space"

Answered in the new forum (75 burst for signing up.)

[SpeedDemon13]

The GPU plot generator v2.0.0 will allow you to do that. I will release it in few hours at most. Be patient

 

Will this also fix the weird double memory problem?

I was able to plot up to 2024 stagger with my 3GB 280x but anymore than that and I get the CL error.  Strange thing is that looking at MSI Afterburner I'm only using 1.1GB on the card and less than 20% of my system RAM.

The time it takes to look through the plots for valid shares is related to stagger size, right?  I'm noticing that my systems aren't always able to go through all my plots before the end of some blocks.  Most of my plots are at stagger 1000 because I was having problems going any higher with the Java miner.

The "weird" double memory problem is due to the limited amount of local memory for each workgroup thread on the GPU side (it would require more than 260KB per thread, what is really big in the graphic cards world). The only way I found for now is to allocate another huge buffer (of (PLOT_SIZE + 16) * staggerSize bytes) that each workgroup thread can use to store the processing data. Thus, the amount of memory needed by the GPU plot generator is more than twice the normal amount.
One solution to avoid this memory overhead is to find a mean to do the last algorithm step in an on-place fashion. I will try to work on that and on the kernel enhancement (to speed things up even more :p) for the 2.1.0 version.

I get the error "[-61] Unable to create the OpenCL GPU generation buffer" with any stagger sizes above about 2000.  Is that because of this memory problem or something else?

How much system ram do you have? What Windows are you running? Are you using AMD 13.9 driver and APP SDK 2.9.1?

You should at least be able to get the same stagger size of your vram, 3GB/3072MB. I couldn't go higher than 4096 for stagger size and 128 threads. I'm running Windows 8.1.

[SpeedDemon13]

Can anybody help?

What does it mean???
//16Gb RAM. 2*4TB HDD.// [Running two miners]

"Uncaught error from thread [Uncaught error from thread [default-akka.actor.defau
lt-dispatcher-2] shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabl
ed for ActorSystem[default]
default-akka.actor.default-dispatcher-4] shutting down JVM since 'akka.jvm-exit-
on-fatal-error' is enabled for ActorSystem[default]
java.lang.OutOfMemoryError: Java heap space"

Answered in the new forum (75 burst for signing up.)

Try to increase the heap size from -Xmx750 to -Xmx1024.

[regtable69]

The GPU plot generator v2.0.0 will allow you to do that. I will release it in few hours at most. Be patient

 

Will this also fix the weird double memory problem?

I was able to plot up to 2024 stagger with my 3GB 280x but anymore than that and I get the CL error.  Strange thing is that looking at MSI Afterburner I'm only using 1.1GB on the card and less than 20% of my system RAM.

The time it takes to look through the plots for valid shares is related to stagger size, right?  I'm noticing that my systems aren't always able to go through all my plots before the end of some blocks.  Most of my plots are at stagger 1000 because I was having problems going any higher with the Java miner.

The "weird" double memory problem is due to the limited amount of local memory for each workgroup thread on the GPU side (it would require more than 260KB per thread, what is really big in the graphic cards world). The only way I found for now is to allocate another huge buffer (of (PLOT_SIZE + 16) * staggerSize bytes) that each workgroup thread can use to store the processing data. Thus, the amount of memory needed by the GPU plot generator is more than twice the normal amount.
One solution to avoid this memory overhead is to find a mean to do the last algorithm step in an on-place fashion. I will try to work on that and on the kernel enhancement (to speed things up even more :p) for the 2.1.0 version.

I get the error "[-61] Unable to create the OpenCL GPU generation buffer" with any stagger sizes above about 2000.  Is that because of this memory problem or something else?

How much system ram do you have? What Windows are you running? Are you using AMD 13.9 driver and APP SDK 2.9.1?

You should at least be able to get the same stagger size of your vram, 3GB/3072MB. I couldn't go higher than 4096 for stagger size and 128 threads. I'm running Windows 8.1.

surley if using the gpu to plot at stagger of 4096 but able to use java plotter to do 8191 its better to java plot all be it 3x as long because mining would run better due to larger stagger, right?

[SpeedDemon13]

The GPU plot generator v2.0.0 will allow you to do that. I will release it in few hours at most. Be patient

 

Will this also fix the weird double memory problem?

I was able to plot up to 2024 stagger with my 3GB 280x but anymore than that and I get the CL error.  Strange thing is that looking at MSI Afterburner I'm only using 1.1GB on the card and less than 20% of my system RAM.

The time it takes to look through the plots for valid shares is related to stagger size, right?  I'm noticing that my systems aren't always able to go through all my plots before the end of some blocks.  Most of my plots are at stagger 1000 because I was having problems going any higher with the Java miner.

The "weird" double memory problem is due to the limited amount of local memory for each workgroup thread on the GPU side (it would require more than 260KB per thread, what is really big in the graphic cards world). The only way I found for now is to allocate another huge buffer (of (PLOT_SIZE + 16) * staggerSize bytes) that each workgroup thread can use to store the processing data. Thus, the amount of memory needed by the GPU plot generator is more than twice the normal amount.
One solution to avoid this memory overhead is to find a mean to do the last algorithm step in an on-place fashion. I will try to work on that and on the kernel enhancement (to speed things up even more :p) for the 2.1.0 version.

I get the error "[-61] Unable to create the OpenCL GPU generation buffer" with any stagger sizes above about 2000.  Is that because of this memory problem or something else?

How much system ram do you have? What Windows are you running? Are you using AMD 13.9 driver and APP SDK 2.9.1?

You should at least be able to get the same stagger size of your vram, 3GB/3072MB. I couldn't go higher than 4096 for stagger size and 128 threads. I'm running Windows 8.1.

surley if using the gpu to plot at stagger of 4096 but able to use java plotter to do 8191 its better to java plot all be it 3x as long because mining would run better due to larger stagger, right?

To me, it never really made a difference. Once the plots were done, seeks and read seem to be the same.

[bitminer82]

How much system ram do you have? What Windows are you running? Are you using AMD 13.9 driver and APP SDK 2.9.1?

You should at least be able to get the same stagger size of your vram, 3GB/3072MB. I couldn't go higher than 4096 for stagger size and 128 threads. I'm running Windows 8.1.

I have 8GB (approx 1.4GB in use while plotting).  Windows 8.1.  Driver 13.251.9001.1001 and APP SDK 2.9.233.167.

[SpeedDemon13]

How much system ram do you have? What Windows are you running? Are you using AMD 13.9 driver and APP SDK 2.9.1?

You should at least be able to get the same stagger size of your vram, 3GB/3072MB. I couldn't go higher than 4096 for stagger size and 128 threads. I'm running Windows 8.1.

I have 8GB (approx 1.4GB in use while plotting).  Windows 8.1.  Driver 13.251.9001.1001 and APP SDK 2.9.233.167.

Try a clean uninstall with DDU driver cleaner, then try to install 13.9 with 2.9.1 APP SDK. That's how I got it to work for me.

[DMaster2008]

burst-pool.cryptoport.io has issues again? Current block 9846.

[regtable69]

burst-pool.cryptoport.io has issues again? Current block 9846.

#ui issues maybe, miners reporting correct block

[Sglasio]

Windows 8 x64
catalyst 13.9
sdk 2.9.1
max stagger 1024 (((