XPlotter for optimized plots (CPU)
-
@k.coins said in XPlotter for optimized plots (CPU):
@IncludeBeer that is astronomical! compared to my nonce/min (6k/min with i7 2ghz) lol!
haha, that's almost double what I get on my $350 Dell laptop, Intel i5-5200U at 2.2 GHz 4 core using 1 GB of RAM.
I'll bet @IncludeBeer is going to have to hit about 2000 extra blocks to make up the cash difference between my laptop and that beast of a miner he has :)
-
@rds said in XPlotter for optimized plots (CPU):
@k.coins said in XPlotter for optimized plots (CPU):
@IncludeBeer that is astronomical! compared to my nonce/min (6k/min with i7 2ghz) lol!
haha, that's almost double what I get on my $350 Dell laptop, Intel i5-5200U at 2.2 GHz 4 core using 1 GB of RAM.
I'll bet @IncludeBeer is going to have to hit about 2000 extra blocks to make up the cash difference between my laptop and that beast of a miner he has :)
lol ya exactly! I built this puppy about 2 years ago now to be my gaming machine. But, since it can handle it easily, I shoved in a couple extra gpu's for mining and also run my burst mining from it since it can house so many hdd's. It makes for a great plotter for sure, but certainly wasn't built for it ( e.g. $/efficiency).
-
Is it safe to run multiple instances of xplotter?
-
@IncludeBeer I think it would be limited by the number of threads devoted to each.
-
-
@IncludeBeer are you doing three at the same time? If so it looks good.
-
@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


