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

[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.

[go6ooo1212]

Do you need high speed CPU ,when using the GPU generator?

[unsoindovo]

i read 400 page and more here.
but until now i don't understand if it is better this configuration:

==== CONFIG ONE =============

12TB space
4 HDD
on each drive one miner who mine on 3 TB plots on each 4 directories.

==== CONFIG TWO =============

12TB space
1 big JBOD
just one miner who mine  12 TB plots in one directory.

any idea???

thanks

[bitminer82]

file name is 3243305246736502377_0_20800000_1000

Ok, so you started at zero and planned to go to 20800000 but it quit halfway through.  So you know it's ended somewhere between 0 and 20800000, right?  So just start the new plot at 30000000 and you are guaranteed to not have any overlapping plots.  Trying to start exactly where it left off is unnecessary and just making more work for yourself.

[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.

i would love to increase my stagger size currently at 8191 stock any higher crshes any lower is pointless. and well i dont think im even scanning 200 gb before block falls as best shares so far in excess of a week and im getting 2 maybe 3 coins per block hell last payment was 29/100 blocks!
and seen as the plot stagger resizer for windows dissapeared i cant go any bigger thus making mining very dificult vrs some farm of 25 tb with 32+gb ram :-(

[maxpayne1256]

i read 400 page and more here.
but until now i don't understand if it is better this configuration:

==== CONFIG ONE =============

12TB space
4 HDD
on each drive one miner who mine on 3 TB plots on each 4 directories.

==== CONFIG TWO =============

12TB space
1 big JBOD
just one miner who mine  12 TB plots in one directory.

any idea???

thanks

Config 1 is better, because you can read and write faster. If one drive crashes, you will lose all your data with config 2.

[bitminer82]

i read 400 page and more here.
but until now i don't understand if it is better this configuration:

==== CONFIG ONE =============

12TB space
4 HDD
on each drive one miner who mine on 3 TB plots on each 4 directories.

==== CONFIG TWO =============

12TB space
1 big JBOD
just one miner who mine  12 TB plots in one directory.

any idea???

thanks

With just one miner running you may not be able to scan though all the plots before the next block starts.  With four miners running they can all be looking at different plots and finish searching much faster.  Go with config one and if you decide later you want to just use one miner you can create symlinks.  

[Dzus1k]

file name is 3243305246736502377_0_20800000_1000

Ok, so you started at zero and planned to go to 20800000 but it quit halfway through.  So you know it's ended somewhere between 0 and 20800000, right?  So just start the new plot at 30000000 and you are guaranteed to not have any overlapping plots.  Trying to start exactly where it left off is unnecessary and just making more work for yourself.

so I have to change the code in run_generate from

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

to

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

[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.

i would love to increase my stagger size currently at 8191 stock any higher crshes any lower is pointless. and well i dont think im even scanning 200 gb before block falls as best shares so far in excess of a week and im getting 2 maybe 3 coins per block hell last payment was 29/100 blocks!
and seen as the plot stagger resizer for windows dissapeared i cant go any bigger thus making mining very dificult vrs some farm of 25 tb with 32+gb ram :-(

There was a stagger resizer?!

[Razerglass]

file name is 3243305246736502377_0_20800000_1000

Ok, so you started at zero and planned to go to 20800000 but it quit halfway through.  So you know it's ended somewhere between 0 and 20800000, right?  So just start the new plot at 30000000 and you are guaranteed to not have any overlapping plots.  Trying to start exactly where it left off is unnecessary and just making more work for yourself.

so I have to change the code in run_generate from

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

to

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

yes but if you still use the "count"  ....20800000 youre going to be generating the same size file you were trying to in the first place.. you said it got half done. so cut that number in half since you dont need to generate as big of a file for the remainder.


EDIT if you want to know how big to make the count... multiply it by 256.. that gives you the file size it will generate in bytes...

[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.

i would love to increase my stagger size currently at 8191 stock any higher crshes any lower is pointless. and well i dont think im even scanning 200 gb before block falls as best shares so far in excess of a week and im getting 2 maybe 3 coins per block hell last payment was 29/100 blocks!
and seen as the plot stagger resizer for windows dissapeared i cant go any bigger thus making mining very dificult vrs some farm of 25 tb with 32+gb ram :-(

There was a stagger resizer?!

yep! you could rre arrange the plot files say 5 on your drive from 3.7 sec scoops to 0 second scoops by upping from 8191 nonces per stagger to full file stagger so one scan per plot file. :-( it vanished quick.

[bitminer82]

file name is 3243305246736502377_0_20800000_1000

Ok, so you started at zero and planned to go to 20800000 but it quit halfway through.  So you know it's ended somewhere between 0 and 20800000, right?  So just start the new plot at 30000000 and you are guaranteed to not have any overlapping plots.  Trying to start exactly where it left off is unnecessary and just making more work for yourself.

so I have to change the code in run_generate from

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

to

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

yes

Not quite.  

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

The number in bold, the number of nonces to plot, needs to be lowered to fit the free space left on the drive.  How many bytes are free space?

[Dzus1k]

file name is 3243305246736502377_0_20800000_1000

Ok, so you started at zero and planned to go to 20800000 but it quit halfway through.  So you know it's ended somewhere between 0 and 20800000, right?  So just start the new plot at 30000000 and you are guaranteed to not have any overlapping plots.  Trying to start exactly where it left off is unnecessary and just making more work for yourself.

so I have to change the code in run_generate from

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

to

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

yes but if you still use the "count"  ....20800000 youre going to be generating the same size file you were trying to in the first place.. you said it got half done. so cut that number in half since you dont need to generate as big of a file for the remainder.


EDIT if you want to know how big to make the count... multiply it by 256.. that gives you the file size it will generate in bytes...

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 ?

[bitminer82]

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

[Alpinist]

I received this before miner has closed.
Any clue???

System has 16Gb RAM and I run two miners at a time.
2*4TB HDD.

Uncaught error from thread [default-akka.actor.default-dispatcher-6] shutting do
wn JVM since 'akka.jvm-exit-on-fatal-error' is enabled for ActorSystem[default]
java.lang.OutOfMemoryError: Java heap space
        at pocminer_pool.ScoopReader.readFile(ScoopReader.java:33)
        at pocminer_pool.ScoopReader.onReceive(ScoopReader.java:18)
        at akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.s
cala:167)
        at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
        at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97)
        at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
        at akka.actor.ActorCell.invoke(ActorCell.scala:487)
        at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)
        at akka.dispatch.Mailbox.run(Mailbox.scala:220)
        at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(Abst
ractDispatcher.scala:393)
        at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
        at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool
.java:1339)
        at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:19
79)
        at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThre
ad.java:107)
[ERROR] [09/11/2014 00:03:08.491] [default-akka.actor.default-dispatcher-6] [Act
orSystem(default)] Uncaught error from thread [default-akka.actor.default-dispat
cher-6] shutting down JVM since 'akka.jvm-exit-on-fatal-error' is enabled
java.lang.OutOfMemoryError: Java heap space
        at pocminer_pool.ScoopReader.readFile(ScoopReader.java:33)
        at pocminer_pool.ScoopReader.onReceive(ScoopReader.java:18)
        at akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.s
cala:167)
        at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
        at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:97)
        at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
        at akka.actor.ActorCell.invoke(ActorCell.scala:487)
        at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238)
        at akka.dispatch.Mailbox.run(Mailbox.scala:220)
        at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(Abst
ractDispatcher.scala:393)
        at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
        at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool
.java:1339)
        at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:19
79)
        at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThre

[bipben]

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.

[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.

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.

[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.

just a hunch but say your plotting 2 1 tb hdd could you not give windows the whole tb on one drive as say virtual memory to help it along?

[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.

So I would want to run more threads?

I guess I call it "weird" because I'm apparently "out of memory" on the card, yet I'm only using about half of it.

[bitminer82]

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?