XPlotter for optimized plots (CPU)
-
@IncludeBeer so basically if I had 8 cores I would use 4 and 4 and divide the available RAM in two as well in order to run two instances at the same time. I have never tried this but I would assume that the plotting speed will be divided by two as well, so it will be probably the same speed after all if using the 8 cores and available RAM to do one plot alone.
-
@vExact Yep, running 3 instances to plot 3 drives. You're generally right: it seems like a clean split (4 core plotting is ~1/2 the speed as 8 core plotting). But with my OC'd 17-5930k (12 threads), and 32gb of ddr4, my hard drives quickly become the bottleneck in the plotting process. Even by splitting my compute power over 3 instances (not evenly, btw, as can be seen in the pic), my cpu still isn't working at 100%, 100% of the time. So for me, this is freaking awesome!
-
@IncludeBeer thanks for the note. I will try that as well for my new plots next time :)
-
I run two instances. I have a 4 core laptop and run each instance as 4 threads and 1GB RAM. My max Nonce/min is around 3900. That is split between the two instances. My drives are what reduces my actual nonce/min below my max, but I've seen that most of the time if on instance is gray the other is yellow. As long as one is yellow, you are putting out max available.
-
@rds and does this not saturate CPU operation for you?
-
My CPU is always at 99-100%. The two instances eat about 45% each until the miner kicks in then they drop down to about 25% as the miner pick up CPU time. When the miner is running (30-50 seconds) the nonce rates drops proportionately. The machine will still support soft browsing and light file transfers etc.
-
When using xplotter I use 3 threads out of 4. It limits cpu usage up to 85% on my cpu. It allows other system components to work without lag and reduces overhead (and the heat) even though it adds several hours to the plot completion. When i plot i plot up to 1tb at a time. At the moment i give it an 8gb buffer. My point is if you dont want to loose mining efficiency let loose at least 1 thread when plotting and set xplotter into below normal priority. Besides, Rome wasn't built in a day ... right? and 1 thread in most cases can allow people to mine and surf too
-
While plotting multiple drives at the same time, I noticed something weird. 2 of the HDDs have extremely slow write rates, like ~3-8 mbps. Sometimes they will spike to ~40-50mbps, but always slow back down.
I've been mining on them for over a year now, and I always format/disk check before plotting (in this case, replotting), so I know the drives themselves are good. Both are internal drives: 5tb and 8tb.
BTW, my cpu is idle most of the time, and I have plenty of compute resources left even with both are generating plots, so I know I'm bottle-necked by cpu.
Any ideas?
-
I can tell you one thing, if the bottleneck is your write speed, the resources being available makes sense. Xplotter writes and calculates nonces in parallel, so if your writing takes forever, then the intensive calculations will finish early and free up a lot of resources. You'll also be wasting a lot of time.
I've had this 4 TB WD HDD give me tremendously slow write speeds (and reads) and I'm starting to suspect it was the way it was formatted. I believe @haitch has mentioned it should be NTFS with 64 kb allocation size.
-
@IncludeBeer said in XPlotter for optimized plots (CPU):
While plotting multiple drives at the same time, I noticed something weird. 2 of the HDDs have extremely slow write rates, like ~3-8 mbps. Sometimes they will spike to ~40-50mbps, but always slow back down.
I've been mining on them for over a year now, and I always format/disk check before plotting (in this case, replotting), so I know the drives themselves are good. Both are internal drives: 5tb and 8tb.
BTW, my cpu is idle most of the time, and I have plenty of compute resources left even with both are generating plots, so I know I'm bottle-necked by cpu.
Any ideas?
I see the same thing. That's why I run two plotters. If the one is writing slowly, the other may not be. I can see no discernable pattern. Sometimes plotter 1 is fast other times it's plotter 2. Sometimes both other times neither.
All my drives are NTSF 64kb formatted.
-
@k.coins, @rds Ok, thanks guys. I'd be interested in knowing more about how the drive format affects plotting/mining. Can you elaborate, @haitch?
I just find it weird because, with the exception of my 8tb drive which has smr, all my other drives tend to write closer to ~40-60 mb/s, while these 2 are barely breaking 5mb/s. I was originally thinking it had something to do with the SATA connection, but that seems unlikely.
-
@IncludeBeer Block size wouldn't make that difference. Basically the 64KB Block means on an optimized plot you read 1 64KB block, rather than 16 individual 4KB blocks. If you're not using optimized plots, use the default.
-
@haitch Very cool. And there is a noticeable reduction in time to read the drive (assuming other variables are controlled)? I guess it would depend on the drive and its capacity. I'm interested....maybe I'll experiment with my 2tb drive to try and get some figures.
Does anyone mine with non-optimized plots anymore? XD
-
I currently do
-
When you plotting by wplotgenerator or GPU-plotter - don't unplug your drives after plotting - OS need some time (1-15 mins) for flush cache to drive
-
@Blago said in XPlotter for optimized plots (CPU):
When you plotting by wplotgenerator or GPU-plotter - don't unplug your drives after plotting - OS need some time (1-15 mins) for flush cache to drive
Doesn't "Safely Remove Hardware" flush the cache before it tells you that you can remove the USB device? I wouldn't just unplug a drive without doing that under any circumstances.
-
I'm just starting out with Burstcoin and my plan is to mine using 10TB. Right now, I'm plotting simultaneously on two vastly different machines. Both are writing to identical 1TB drives. One is a home-built PC with a 3-core AMD A6-3500 and 8GB of ram:

The other is an HP workstation with dual E5-2670s and 64GB of ram:

Quite a difference. :-D
As others have experienced, the bottleneck on the HP is write speed, and watching that has me wondering about how RAM and threads affect performance.
I get that the amount of RAM allocated to plotting determines the stagger size. So then is the stagger the number of nonces generated per pass ("Generating nonces from xxxxxxx to yyyyyyy")? So the more RAM allocated, the more nonces created per pass? And then the number of threads and processor speed determines how fast nonces are generated?
Thank you blago for your work on this. And thank you to everyone else contributing. I've been digging through the forums for the past few days trying to wrap my head around all this and have found a ton of great info here. I hope to be up and mining by the weekend.
-
@RatPatrol better when nonces_per_thread = multiple by 1024.
In your case try -t 30 -mem 30G (will 2048)
or -t 30 -mem 45G (will 3096)
-
@Blago said in XPlotter for optimized plots (CPU):
@RatPatrol better when nonces_per_thread = multiple by 1024.
In your case try -t 30 -mem 30G (will 2048)
or -t 30 -mem 45G (will 3096)Thanks for the tip. I'll give it a try this weekend.
-
@Blago said in XPlotter for optimized plots (CPU):
@RatPatrol better when nonces_per_thread = multiple by 1024.
In your case try -t 30 -mem 30G (will 2048)
or -t 30 -mem 45G (will 3096)@Blago didn't quite understand your tip. What do you exactly call nonces_per_thread?
