Topic: [ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000 - page 299. (Read 2170648 times)

Mining with Runaurufu's miner with no problems; all 17 TB's. I'll have to check to make sure that all the TB's show up in the pool tomorrow since this miner is a bit crude. I still believe it is a RAM issue.

This depends on the CPU performance and the number of cores therein.
try a few options:
"CacheSize": 51200
"CacheSize": 5120
"CacheSize": 25600
"CacheSize": 2560

the best option - it is when the thread ends earlier in time

Based on haitch's observations, it would appear my 2.8 ghz i5 is not enough CPU juice to power 5 4 GB HD's, and the RAM maxing out is background noise; Windows would free up the cache RAM as it needed it. The maxing out of RAM and unresponsiveness of the computer was just coincidental, I suppose.

If I come across a copy of Win8 or 10, I'll give it another shot, but I'm being told its my CPU.

Join now !!
Get some shares of "Photovoltaic power station" by  your harddisk

your read speed is quite low: 20 to 25 MB/s ...
too many hdds not enough true cores 

stealing, cheatin thieving waste of water and biomass

i switched to win 10. all issues you are experiencing are gone with win 10.

I mine 90TB on a 32GB machine (server 2012) and with one CPU excluded, and I can't even tell when I'm mining.

I mine 10TB on a 18GB Win 7 machine I use all day/night with one CPU excluded, and I can't even tell when I'm mining.

https://www.dropbox.com/s/ev3f5e009hvn1lc/memusage.jpg?dl=0

some ppl don't have time to learn Linux.

I have win 10, it runs flawlessly now.

machine 1 (i7-5960X):
22:14:21 Thread "M:\plots" in 31.4 sec (22.2 MB/s) CPU 98.82%
22:14:21 Thread "N:\plots" in 31.5 sec (22.2 MB/s) CPU 99.15%
22:14:21 Thread "Q:\plots" in 31.5 sec (22.1 MB/s) CPU 99.14%
22:14:22 Thread "P:\plots" in 31.7 sec (22.0 MB/s) CPU 98.65%
22:14:22 Thread "O:\plots" in 31.8 sec (21.9 MB/s) CPU 99.09%
22:14:30 Thread "L:\plots" in 40.1 sec (23.2 MB/s) CPU 99.37%
22:14:31 Thread "V:\plots" in 41.3 sec (22.5 MB/s) CPU 97.65%
22:14:47 Thread "H:\plots" in 57.2 sec (24.4 MB/s) CPU 99.21%
22:14:47 Thread "Y:\plots" in 57.5 sec (24.3 MB/s) CPU 97.72%
22:14:47 Thread "J:\plots" in 57.6 sec (24.2 MB/s) CPU 98.99%
22:14:47 Thread "I:\plots" in 57.7 sec (24.2 MB/s) CPU 99.24%
22:14:48 Thread "S:\plots" in 58.0 sec (24.1 MB/s) CPU 98.14%
22:15:03 Thread "F:\plots" in 73.1 sec (25.5 MB/s) CPU 98.57%
22:15:03 Thread "K:\plots" in 73.2 sec (25.4 MB/s) CPU 98.39%
22:15:03 Thread "G:\plots" in 73.2 sec (25.4 MB/s) CPU 98.38%
100% 72596 GB. DL=61361 sdl:5083(0) cdl:5083(0) ss:548(0) rs:548(0)

machine 2 (AMD 8350 8 cores):
22:14:22 Thread "F:\plots" in 32.7 sec (21.3 MB/s) CPU 97.85%
22:14:22 Thread "G:\plots" in 32.7 sec (21.3 MB/s) CPU 98.09%
22:14:48 Thread "J:\plots" in 59.0 sec (19.7 MB/s) CPU 98.17%
22:14:49 Thread "H:\plots" in 59.7 sec (19.5 MB/s) CPU 95.62%
22:14:53 Thread "L:\plots" in 64.2 sec (21.7 MB/s) CPU 98.55%
22:14:58 Thread "D:\plots" in 68.7 sec (20.3 MB/s) CPU 98.70%
22:14:58 Thread "M:\plots" in 68.8 sec (20.3 MB/s) CPU 98.68%
22:15:12 Thread "K:\plots" in 82.5 sec (22.6 MB/s) CPU 98.31%
22:15:16 Thread "E:\plots" in 86.8 sec (21.5 MB/s) CPU 98.83%
100% 47024 GB. DL=53045 sdl:5746(0) cdl:5736(0) ss:138(0) rs:138(0)

GPU Plotting I can do about 30K nonces/min on a single GPU, which is about 122M shabal256/min.

Scaling that down,a single shabal256 takes 0.00000048828125 seconds, and 4096 take 0.002 seconds.

H.

Unfortunately, none of this solved my issue. The miner eats up RAM like nobody's business. I'll keep looking for realtime cache-clearing solutions in my free time, but it looks like I'm SOL until Win10 for burst and my 17 TB.

He's very loyal to Burst. Pops in every now and then. Says something shitty.

From my testing, it doesn't make a huge difference. You can test from 4096 to 65536 you won't see much of a difference. I'd make it a multiple of 1024 so that your seeks & reads are on sector boundaries, but even that doesn't make a significant difference.

Says the guy who decided to start his own Burst clone a couple months ago... and runs a computer store and admits that any time he gets a computer to repair he'll look through the users drive trying to find BTC passwords.

haha.. hope he isn't invested in it!  Wouldn't want this guy to get rich someday..


What do you think about this fix for NaS?

Basically every block instead of getting a block reward you get votes, so simple example, I get one vote per block I mine.  I can later use those votes to vote for a block on the correct chain say 1000 blocks later.  This vote can be redeemed between blocks 1010 and 1210.

You get 1/3 of your block reward immediately, 1/3 if you include at least one other vote into your block, and 1/3 when your vote it used.  Note this method does have an issue and I'd prefer to say have it so that you get 10 votes, each only redeemable during different periods but that's the basic idea.

The only thing is, I can't tell whether or not that opens the door to a Byzantine General's issue, meaning we have a 33% attack on the system.. don't understand the Byzantine General's thing well enough.  Just started looking into that today.  I don't see why that would be an issue but if anyone understands Byzantine General's, please explain how you could attack that.  I'm thinking it is not an issue because the Byzantine General's attack is only an issue if someone carrying the message can change it, which due to the signature from someone who can be trusted due to their high POC, this can be trusted?


Regarding POC2 vs POC:

The motivation for POC2 was to make it faster to verify blocks, this should both improve the speed of blockchain parsing as well as limit the likelihood of a DDOS attack where someone can throw out random numbers claiming they are valid POCs and require all the miners to work through all 4096 hashes to get there.

Here are my thoughts on how you could combine POC and POC2:
https://burstforum.com/index.php?threads/poc2-and-asic-resistance.796/

idk.. maybe it's not worth it.  Question is, how long does it take to verify a hash and does making it 500 to 1000 times faster to verify a block significantly decrease DDOS attack risk?  What about how long would it take to verify a couple years worth of block headers?  Burstdev did come up with an interesting way to essentially checkpoint our chain so that customers could only download one blockheader per week.. maybe that fixes the problem and this is no longer needed

So, to me the most important number is, how long does it take to do 4096 Shabal256's vs 1 Shabal256.  Anyone have a precise number?

Hi blago,

what do you recommend to set the cachesize to?

xxxx_yyyy_2048000_2048000
xxxx_yyyy_1024000_1024000
xxxx_yyyy_332800_332800
xxxx_yyyy_1433600_51200

The file caching shouldn't impact your usage, over time it can cause performance issues, but with the memory cleaning it's mostly resolved. during the mining process windows will use pretty much all available memory for caching, but it will not swap out other apps to make space for caching. On my daily PC, which is mining, memory usage during mining goes from around 4GB to just short of the 18GB installed, and I can't tell when mining is happening.

The memory clean does clean out everything that's cached, so that can impact your performance, but not to the level of your CPU getting maxed. To use the cleanmem setting, make sure you have Blagos latest miner, and have in your miner.conf

  "UseCleanMem" : true,

Miner is available from: https://github.com/Blagodarenko/miner-burst/releases/download/v1.150401/miner-burst-1.150401.zip

H.

On Win7 you will always get lags, because on every read it try to cache the file, while caching (system IO always maxed) you will get lags. So first of all you need to change OS to Win8 or Win10.

Changing IO Priority On Win7 only help with system response by 20-50% depending on stagger/file size. Used or available amount of RAM anyway will not be affected.

Changing CPU(Process) Priority of Burst Miner never helped me, because problem was always with System process playing with Cache/RAM.
But disabling 1 core is a good idea.


cleaning RAM will not help you much, every clean run(every 4 minutes) = lag.

Thanks! That was helpful in regards to my CPU. My question in regards to RAM usage is still the problem. Resource manager watches my RAM fill up until I can no longer operate my computer. Unless I've misread your post, all your help was in use to my CPU, which does not run into any issues.

Could you elaborate on this "cleanmem" setting, and if I read your post correctly, it is only helpful BEFORE and AFTER mining process and not DURING, so my only real correction is using a new Windows OS, or is there clearing of the ram during the mining process I can write in?

Memory doesn't really help - the miner itself uses very little memory, it's windows trying to be "helpful" and cache the data from the drives that sucks up the ram, enable the "cleanmem" setting and all memory will be retruned after the mining process. Add more memory and windows will just suck up more, until you force it to be released.

The problem issue you can run into, especially when mining multiple drives, is that you max out the CPU. Blagos miner will use one core/thread per drive/directory you specify. If you're mining with more drives than you have threads, your CPU will be maxed out. To get around this you can adjust the CPU affinity to leave some of the cores untouched by the miner - generally I allow the miner to use all but one thread. You can either do it manually by going into task manager -> processes, right clicking miner.exe, select Set Affinity, and unselect CPU 0. If you're launching it from a batch file, you can set the affinity in the batch file.

To do it via the batch file, do:  start "Burst Miner" /wait /affinity miner

The affinity mask is a hex representation of a binary value of your cpus. eg, if you have four threads, the binary mask is XXXX, where X is 0 or 1 - 0 means don't use that CPU, 1 means use it. So on a 4 thread CPU, to disable CPU0 for miner, the binary vale would be 1110, which is 0xE. So the command would be:

start "Burst Miner" /wait /affinity 0xD miner

For a 8 thread CPU, it'd be 1111 1110, => 0xFE, so start "Burst Miner" /wait /affinity 0x0FE miner

To leave two threads available:

start "Burst Miner" /wait /affinity 0xFD miner

Windows calc.exe has a programmers mode that can do the binary -> hex conversions for the hexidecimally challenged ;-)

H.