Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
You wont use that much normally, during plotting you could make use of about ~10 cores per disk. After that CPU usage is relatively low.
OK so maybe that isn't so bad. 100TB for $500/mo isn't great but it isn't necessarily bad either.
I am not sure I follow what you mean by that? It isnt that you need a certain number of cores perse....More that it takes a ton of compute to plot(prep) the drives for mining. Plotting two drives right now I am loading a pair of 2670v1's to %100
I dont know about better.....just different. Burst will use all of the disk you give it and cannot be used for anything else. Storj you are leasing out storage so only what is actively leased is consumed so to speak.
CPU use is supposed to be low.
Every block (difficulty retargets for an average time of 4 minutes), you need to read 1/4000th of each hard drive, and do some processing on that data. The miner uses one thread per cpu core so that cpu doesn't become a bottlebeck.
People report that the entire process runs in a fairly short amount of time (20-60 seconds depending on drive size and who is reporting it). In 30 seconds a modern drive can read 3-5GB of data sequentially. 1/4000th of an 8tb drive is 2gb.
So if people are reporting 30 second processing on 8tb drives, odds are that the drive is the main bottleneck. That cpu core probably sees a decent workout there too, but only for at most 1/8th of the time (30 seconds every 4 minutes)
If you've got 6 drives in a server mining Aeon on Dual E5-2680v2's, you'll need 3 real cores / 6 threads, out of 20 cores / 40 threads available.
With Aeon, I see 4200-4300 H/s with all 20 cores enabled, using as much cache as possible. I see 4000-4100 H/s with 16 cores enabled, using as much cache as possible (and 20w less power use).
You could easily enough bump down the thread count for Aeon by about 5MB total (say, 8 main threads per cpu at 2MB per thread, and 4 hyperthreads per cpu at 1MB per thread) and you'd have 8 idle hyperthreads and 10MB idle L3 cache available for burstcoin. My best guess is that would be sufficient. If not, can enable all 10 cores in bios and that should do the trick.
This takes you away from my "ideal 8-cores settings" which has you using 8x2 + 6x1 on CPU1 (22MB cache) and 8x2 + 7x1 on CPU2 (23MB cache), down to 8x2 + 4x1 on each (20MB cache ea, 40MB total).
Just in terms of cache that's going from 45MB to 40MB, an 11% drop. However, the hyperthreads don't improve performance in a linear way. Looking at one of these servers now that's performing at 3900H/s currently under the "ideal" configuration, I decided to stop the 6x1 and 7x1 hyperthreads and only run the 8x2 and 8x2 "real cores" threads and see the results.
This puts cache use at 16MB per CPU instead of 22 / 23MB. So 32MB total out of 50MB available. As 45MB is used with my ideal settings, this is 29% less cache use. Of course, performance went down, but not that much. Hash rate dropped to 3300H/s, 600H/s loss. For losing 29% of 3900 you would have expected a loss of 1130H/s, but that actual loss was a little more than half of that.
So overall, if you need a bit of CPU or cache for other processes, it shouldn't be a deal breaker for other mining. Also, the Burst threads will at most be active 25% of the time, and probably closer to 10% of the time. If you had 6x3tb drives doing burst in a Dual E5-2680v2, my best guess is you could still maintain 95% of your baseline Aeon performance.
If I enabled all 10 real cores and could use 40MB cache it would probably give hash rates quite close to my ideal settings, but with a bit more power use, and still leave 5MB cache per CPU and 10 hyperthreads idle for burst mining. Given the revenue per watt is so much better on Burst vs Aeon, spending a few more watts enabling all cores seems like a fair tradeoff. Plugging 12x3tb hitachis into a 2-node chassis, I saw power use increase by only 80w. Adding 40w by putting both nodes to use all 10 cores, you would be at a total of 10 watts per drive, effectively. That should still earn above $1/mo/watt, which is 50-150% more revenue per watt than other mining. So that would be another option as well.
I have been trying to get the GPU plotter to work well and have been struggling to get consistent performance. If you dont mind please share you results and/or experiences.
As I said earlier, you generally want 1 core for reading, 1 core for verifying per drive. I mine Aeon av2 or Monero av1/av2 and mine burst at the same time. Verifying does use cache while it's running so there is a sizeable hit when it's going. Average block time is 4 min, out of which the cpu is going for about 15-30 seconds, you're going to lose about 5%-10% of your hash power over time. If you have 12 hyperthreads w/12 megs cache you can use 6 threads for Monero/Aeon and 6 for burst with 3 attached drives. You can attach more drives if you're willing to forgo some hashrate.
Been running tests with different settings and GPUs. Seems there's minimal improvement going from a 1070 to a 1080ti. Presumably for similar reasons as ethereum not scaling well either.
With a 1.6tb dc p3605 scratch disk and dual e5-2660v1, a pair of gtx 1070's can get up to 73k nonce / minute running 2 copies of gpu plotter at once, and up to 78k nonces / minute running 4 copies at once.
Test settings:
gpuPlotGenerator generate buffer c:\plots\(address)_0_65536_4096
gpuPlotGenerator generate buffer c:\plots\(address)_100000_65536_4096
gpuPlotGenerator generate buffer c:\plots\(address)_200000_65536_4096
gpuPlotGenerator generate buffer c:\plots\(address)_300000_65536_4096
devices.txt
2 copies at once:
1 0 960 8 8192
1 1 960 8 8192
73k nonce / minute
4 copies at once:
1 0 768 6 8192
1 1 768 6 8192
78k nonce / minute
A single 1070 can do 40-48k nonce / min. Running at least two processes keeps the gpu busy more of the time. In between staggers, data gets written to disk and the gpu idles. Having at least two processes going minimizes this.
The best settings will vary by gpu. "direct" might be better than "buffer" -- I'm using buffer for testing to isolate gpu performance, as buffer uses less disk i/o than direct. I plan to try direct for my real plots -- the test plots above are 16GB apiece.
While I'm at it, here's a pic of the server I'm testing out for plotting:
Lexan to act as an air guide without the top on.
2x GTX 1070 (one upgraded to water cooling)
2x E5-2660v1
1x LSI 9211-8i HBA
1x 1.6TB Intel DC P3605
1tb boot drive hdd
various 3tb drives to plot to (qty 11)
Oh, and just one other minor bit:
384GB ram. Stagger sizes to the moon!
Lexan to act as an air guide without the top on.
2x GTX 1070 (one upgraded to water cooling)
2x E5-2660v1
1x LSI 9211-8i HBA
1x 1.6TB Intel DC P3605
1tb boot drive hdd
various 3tb drives to plot to (qty 11)
Oh, and just one other minor bit:
384GB ram. Stagger sizes to the moon!
Haven't gotten that far yet, will let you know. Trying to get plotting working (windows) first. Having wallet blockchain sync issues to deal with next. I'm told that linux mining is feasible once you've done plotting, so plan to be doing that as well.
It looks like you are running 2 copies per GPU correct? At one point I heard that a 1070 could do quite a bit more nonce/min than that....Has definitely not been my experience.
Finally got my production settings going (hopefully). Having 2 copies of the program run at once, and both are "allowed" to use both gpus. Each copy runs 46k nonce / minute during the plotting portion, then takes a long break to write the data to disk.
I've decided to use a 175GB stagger size, with 175GB plot files. No optimization needed. Running two copies at once has me using up 360gb out of 384gb ram.
These settings make full use of the NVMe write speed once the plot file has completed -- 1.2-1.3GB/s. Put together two batch files; one for each process. The batch file generates a 175GB plot, saves it to the SSD, then moves it to a hard drive, and then starts generating a new plot.
I -believe- the command prompt "move" command will allow the batch file to continue processing the following commands while the data is still being moved from one drive to the other, but I'm not 100% sure. Fingers crossed. If so, this process should be quite a lot faster than what I had been trying at first.
Wow, I have never seen anyone use such a large stagger size, interesting. Curious to see how it goes for you....Looking to get 100 drives plotted so any methods of speeding that up are great.
When I tested with smaller files, it seemed that the move command could execute asyncronously. On this production run, that's clearly not the case. I do see a "start" command that should do this for me. If I run every other "move" asyncronously, that should cause the gpu processing and disk i/o to stagger better between the two processes, hopefully without running out of disk space. Going to stop this run and try that.