[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000 - page 300.

lmaonade80

member

Activity: 124

Merit: 10

Quote from: sellbuy on April 21, 2015, 09:03:05 PM

Quote from: lmaonade80 on April 21, 2015, 08:50:55 PM

I have 17 TB in my miner right now; just moved various HDD's to one rig due to a different mining algo I'm using would freeze it up when mining in conjunction. With 17 TB (blago's miner), my 16 gb of ram is not enough to let the miner run smoothly while also allowing me to work on the computer unaffected.. My question is... Is there a preferred ratio of HDD space (in terabytes) to ram ratio I should be shooting for? I'm going to pick up some more ram tomorrow, and I wanna know how much I need to get.

you need windows 8 or windows 10 for normal RAM using, windows 7 have problems with caching big files.
8gb of RAM is ok for mining on Windows 8.

try to set IO Priority & Cache Priority of burst miner to "idle" (System tool "Process Hacker" can do that, but manually)

anyway, high IO Load(big queque) may cause some lags even with 1 HDD mining.
for comfortable using PC you will need optimized miner

Hey, so if I set the IO load to idle, then it would help? I'm trying it now. I'm confused by your wording which stated no go on Win7, but try this? Thanks

sellbuy

full member

Activity: 158

Merit: 100

Quote from: lmaonade80 on April 21, 2015, 08:50:55 PM

I have 17 TB in my miner right now; just moved various HDD's to one rig due to a different mining algo I'm using would freeze it up when mining in conjunction. With 17 TB (blago's miner), my 16 gb of ram is not enough to let the miner run smoothly while also allowing me to work on the computer unaffected.. My question is... Is there a preferred ratio of HDD space (in terabytes) to ram ratio I should be shooting for? I'm going to pick up some more ram tomorrow, and I wanna know how much I need to get.

you need windows 8 or windows 10 for normal RAM using, windows 7 has problems with caching big files.
8gb of RAM is ok for mining on Windows 8.

try to set IO Priority & Cache Priority of burst miner to "idle" (System tool "Process Hacker" can do that, but manually)

anyway, high IO Load(big queque) may cause some lags even with 1 HDD mining.
for comfortable using PC you will need optimized miner

lmaonade80

member

Activity: 124

Merit: 10

I have 17 TB in my miner right now; just moved various HDD's to one rig due to a different mining algo I'm using would freeze it up when mining in conjunction. With 17 TB (blago's miner), my 16 gb of ram is not enough to let the miner run smoothly while also allowing me to work on the computer unaffected.. My question is... Is there a preferred ratio of HDD space (in terabytes) to ram ratio I should be shooting for? I'm going to pick up some more ram tomorrow, and I wanna know how much I need to get.

coinits

legendary

Activity: 1582

Merit: 1019

011110000110110101110010

Quote from: dystopian on April 21, 2015, 07:11:36 PM

Quote from: timk225 on April 21, 2015, 07:01:34 PM

You're all idiots for wasting your time and money on this shitcoin that will never amount to anything.

You're a serious troll dude Roll Eyes

He dips his pathetic self into a lot of threads and is always full of hate. The guy is a self-professed thief. He does computer repairs and troubleshooting and is always looking for bitcoin wallets to steal.

dystopian

member

Activity: 66

Merit: 10

Quote from: timk225 on April 21, 2015, 07:01:34 PM

You're all idiots for wasting your time and money on this shitcoin that will never amount to anything.

You're a serious troll dude Roll Eyes

timk225

hero member

Activity: 955

Merit: 1004

You're all idiots for wasting your time and money on this shitcoin that will never amount to anything.

dcct

sr. member

Activity: 280

Merit: 250

Quote from: katlogic on April 21, 2015, 04:32:10 PM

See https://bitcointalksearch.org/topic/m.10292524

Using single sha256 for nonce as a reference, the ballpark for conventional hardware of this TMTO is 25/75 pow/poc (bruteforce 8 bits of each 32bit nonce during a readout - assuming a disk can read 10Mnonce/s a second (*4 byte = 40Mbyte/s), that translates to 2560M nonce/s for top of the line GPU. The shorter the nonces are, the easier the PoW part is.

With dedicated hardware, 50/50 or more in favour of PoW.

As for your energy argument - if you have 1PB cluster eating 1kW and with a tiny (compared to HDDs) investment for PoW "booster" you have effectively 2PB cluster eating 2kW ... guess what most miners will opt for. Big appeal of current PoC is that most of capital investment is the equipment, not energy. POC2 as it is will drastically shift it towards conventional PoW.

On the upside - this can effectively get rid of NaS.

Fixing POW2 involves making the nonces large enough (at least 64 bit) so PoW becomes impractical for all intents and purposes.

Currently each scoop is 64 bytes - or 512 bits - long. Lets assume you brute force 16 bits of each, thats 65536 hashes per nonce the gpu needs to do - leaving 496 bits to store. You´d be able to store 3% more nonces, at the cost of massive CPU/GPU load.
The long scoop length is an effective protection against this "hack", I hope its not going to be changed drastically with poc2.

In my opinion the number of scoops should be increased (to 16 * 4096 maybe), the scoop size reduced to 32 bytes - that would total in 2MB of disk space per nonce and 16MB/TB to be read each block, at a VERY LOW cpu load. Energy efficiency is the main selling point of BURST, don´t give up on that.

Quote

5. High blocktime variance
Due to the high amount of diskspace used per nonce, the total amount of nonces checked per block is very low compared to PoW coins. This leads to higher variance in block times.

In my opinion this is not the reason for higher block time variance. Coins with "slow" pow-algorithms like scrypt-jane don´t have this problem either.

In fact, basetarget may be adjusting too fast.

katlogic

member

Activity: 75

Merit: 10

Quote from: mczarnek on April 19, 2015, 11:20:47 PM

Quote from: ltcnim on April 19, 2015, 12:49:25 PM

Quote from: bobafett on April 19, 2015, 10:46:57 AM

Quote from: jzhoulon on April 19, 2015, 10:00:03 AM

it seems that burst didn't be updated for more than 2.5month, and the dev seems disapear for a long time, i am wondering whether the dev is still developing this coin? i have asked the same question one month ago, it seems lots of people said the the new update will come soon, but i didn't see any updates from the top of the thread now?

also poc2 is developed and will be implementet parallel with poc. so you can mine with you gpu AND with your hdd. with poc2 you need no so much hdd space as with normal poc. that will bring the coin to much more people who has their gpu mining rigs allready at home.

atm we all wait for the world first acct that will be done, if qora is ready this month.

hmm...I'm not sure if GPU mining is such a good idea. It was always about low power usage when mining this coin. And now we should throw away one of the main advantages?
PoC was a revolutionary approach with all those GPU/ASIC coins..

POC2 will not really allow GPU mining much more than POC

Basically the idea is that if miners hack it, they can store only partial proofs on your hard drive and use their GPU to try to figure out in real time what those missing bits should be. However, realistically it doesn't make sense given that it is still much more cost and energy efficient to spend that money on an extra hard drive rather than a GPU.

Anyway, people are getting impatient.. but trust me, big things are happening in the background. That being said.. please dump more coins! I'm trying to make an effort to attract more developers and people who might have some venture capital for us and I'm sure they'd prefer to buy in cheaper!! Not that I'm having much luck yet.. but you know. Plus I told myself I wasn't allowed to buy any more Burst.. but at these prices, I splurged.. really hoping I don't regret it in the long run, though I really just don't see any way that Burst doesn't beat BTC some day.

And after some very through analysis of POC vs POS and POW.. POC has a lot more potential than most people realize.

See https://bitcointalksearch.org/topic/m.10292524

Using single sha256 for nonce as a reference, the ballpark for conventional hardware of this TMTO is 25/75 pow/poc (bruteforce 8 bits of each 32bit nonce during a readout - assuming a disk can read 10Mnonce/s a second (*4 byte = 40Mbyte/s), that translates to 2560M nonce/s for top of the line GPU. The shorter the nonces are, the easier the PoW part is.

With dedicated hardware, 50/50 or more in favour of PoW.

As for your energy argument - if you have 1PB cluster eating 1kW and with a tiny (compared to HDDs) investment for PoW "booster" you have effectively 2PB cluster eating 2kW ... guess what most miners will opt for. Big appeal of current PoC is that most of capital investment is the equipment, not energy. POC2 as it is will drastically shift it towards conventional PoW.

On the upside - this can effectively get rid of NaS.

Fixing POW2 involves making the nonces large enough (at least 64 bit) so PoW becomes impractical for all intents and purposes.

mmmaybe

sr. member

Activity: 462

Merit: 250

Quote from: skymax on April 21, 2015, 12:19:24 PM

mmmhh... burst at 0.00000122 TIME TO BUYYY Cool

Yup, 1,5mil to add to the good old pile

Loving it. Just want more BTC hehe

callmejack

sr. member

Activity: 256

Merit: 250

Quote from: ?? on ??

Quote from: FakeAccount on April 21, 2015, 11:52:31 AM

Quote from: bobafett on April 21, 2015, 10:31:28 AM

yes i also think so. got 3 miner, all win 8 and one has it every 5 days, the other 2 never had it until now.

if everything is the same, then maybe it's now trying to execute some code it hasn't tried/needed to run before.
some variable changed in size? i'm just thinking out loud here.

for me the error message sounds like a wrong index somewhere in the code.
maybe the cache filling thread doesn't get reset correctly on block change if the sata port or network times out and freezes the whole machine.
there may be included libraries which tend to crash the program if threads get simply terminated and not shutdown.
on average situations this works but if there are long response times somewhere (disk or network) the regular situation changes and a counter wont be reset (multithreading can be evil).

personally i have not reviewed the code to give a hint where to look for.
simply switch your rigs to linux using the dcct or java miner.
both combinations run totally unattended (except the wallet updates) without any of the windows related issues since month for me Tongue

even the last wallet update did not crash a single running miner instance.

what is special with the blago miner?
how many tb can be parsed per core per minute on a current average i7 cpu?
is it only useful for windows based mining?

skymax

member

Activity: 63

Merit: 10

mmmhh... burst at 0.00000122 TIME TO BUYYY Cool

Razerglass

legendary

Activity: 1036

Merit: 1000

https://bmy.guide

Quote from: catbref on April 21, 2015, 05:47:53 AM

ninja pool updated to v1.2.3
historic pie rendering fixed (data was okay, just stats page was wrong)

BONUS PAYMENT CODE coming very soon (yum yum)

nice work catbref

FakeAccount

full member

Activity: 248

Merit: 100

I'm not real

Quote from: bobafett on April 21, 2015, 10:31:28 AM

yes i also think so. got 3 miner, all win 8 and one has it every 5 days, the other 2 never had it until now.

if everything is the same, then maybe it's now trying to execute some code it hasn't tried/needed to run before.
some variable changed in size? i'm just thinking out loud here.

bobafett

hero member

Activity: 619

Merit: 500

yes i also think so. got 3 miner, all win 8 and one has it every 5 days, the other 2 never had it until now.

FakeAccount

full member

Activity: 248

Merit: 100

I'm not real

Quote from: bensam1231 on April 21, 2015, 05:45:05 AM

Quote from: FakeAccount on April 21, 2015, 12:29:42 AM

Quote from: Blago on April 20, 2015, 11:41:30 PM

Quote from: bensam1231 on April 20, 2015, 10:48:12 PM

...
This doesn't fix it. I'm not certain what does. I have some machines running fine with 401 and others that still crash even though they have identical setups. Memclean doesn't seem to be the issue. The crashing also seems sporadic. I have one that has been running fine for the last week. I thought it may have been the visual c++ redistributables, but they're all running the same versions now.

It is not yet fixed. Error spontaneous, so until I found the cause of its origin...

I noticed this error when the system loses a drive and you get a 0 or -1 size... maybe if USB drive gets disconnected but miner attempts to read it anyway you could try reproducing this error.

Yeah it's on a all SATA system. I've tried looking for the cause, but I can't find it. 319 doesn't have this issue. It seems as though the more drives the system has, the faster it crashes. But now I have some systems that were crashing with it that aren't (?!!?).

Quote from: bobafett on April 21, 2015, 12:38:36 AM

i got this error also on my miner with sata drives only. energy option on high power and no hdd sleep timer.

then it's it's all random.

catbref

member

Activity: 106

Merit: 10

ninja pool updated to v1.2.3
historic pie rendering fixed (data was okay, just stats page was wrong)

BONUS PAYMENT CODE coming very soon (yum yum)

bensam1231

legendary

Activity: 1750

Merit: 1024

Quote from: FakeAccount on April 21, 2015, 12:29:42 AM

Quote from: Blago on April 20, 2015, 11:41:30 PM

Quote from: bensam1231 on April 20, 2015, 10:48:12 PM

...
This doesn't fix it. I'm not certain what does. I have some machines running fine with 401 and others that still crash even though they have identical setups. Memclean doesn't seem to be the issue. The crashing also seems sporadic. I have one that has been running fine for the last week. I thought it may have been the visual c++ redistributables, but they're all running the same versions now.

It is not yet fixed. Error spontaneous, so until I found the cause of its origin...

I noticed this error when the system loses a drive and you get a 0 or -1 size... maybe if USB drive gets disconnected but miner attempts to read it anyway you could try reproducing this error.

Yeah it's on a all SATA system. I've tried looking for the cause, but I can't find it. 319 doesn't have this issue. It seems as though the more drives the system has, the faster it crashes. But now I have some systems that were crashing with it that aren't (?!!?).

muhrohmat

sr. member

Activity: 252

Merit: 250

ah ok wallet 1.2.3 got out i better see this and wait a bit in mining till burst come to 150 satoshis again and the btc goes to 250 euros soo nice of you guys to post this

bobafett

hero member

Activity: 619

Merit: 500

i got this error also on my miner with sata drives only. energy option on high power and no hdd sleep timer.

FakeAccount

full member

Activity: 248

Merit: 100

I'm not real

Quote from: Blago on April 20, 2015, 11:41:30 PM

Quote from: bensam1231 on April 20, 2015, 10:48:12 PM

...
This doesn't fix it. I'm not certain what does. I have some machines running fine with 401 and others that still crash even though they have identical setups. Memclean doesn't seem to be the issue. The crashing also seems sporadic. I have one that has been running fine for the last week. I thought it may have been the visual c++ redistributables, but they're all running the same versions now.

It is not yet fixed. Error spontaneous, so until I found the cause of its origin...

I noticed this error when the system loses a drive and you get a 0 or -1 size... maybe if USB drive gets disconnected but miner attempts to read it anyway you could try reproducing this error.

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