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

We would all like for uray to come back, he did great work for BURST and we would like for him to continue to do so.
Website is under development, but it will be ready.

Tutorials are a good idea, while some do exist I would like to have a video tutorial for some things up. Unfortunately I am a noob when it comes to video and lack the equipment. If I manage to edumacate myself I might do them myself. Don't hold your breath about it though

As for Android, I imagine a "web wallet" should do fine. I am unsure how easy would it be to adapt the current wallet for it.


Time to swap all your old drives for this little baby

Neat little thing:

http://www.extremetech.com/computing/189813-western-digital-unveils-worlds-first-10tb-hard-drive-helium-filled-shingled-recording

Okay , thanks for caring , I recently got aware of BURST and I am actively supporting its rapidly increasing adoption .
Uray's Project is a great idea and he should update it as soon as possible , also a cover page on the main domain with a BURST Logo is a must .

URAY is in The Future

I like that .

What are we doing in The Past ?!  

The wallet application is full of features most don't know how to use ,
some could create little tutorials which show step by step how to proceed .

OSX Users could use an easy to install BURST Wallet , too . And what about BURST for Android ?

BURST is better distributed than NXT , highly undervalued , Bter , and btc38 should trade it , too !

I imagine it will require a replot, since it entails a different way of storing nonces.
You did get it correctly with regards to optimizing and you should optimize your plots. Before I optimized mine you could really hear the drives seeking like mad

Unfortunately I cannot recall now who already did raspberry pi tests in this thread. That member came to the conclusion that it is good for, at most, 8tb. IIRC he did plot on another intel machine.

i think raspberry,
here is intendend to mine.
not to plot files...

to plot file you need  high end CPU o a good GPU.
i think 280X.
but with the latest CPU [i7 haswell] plotter i can see the performance are similar...
and more...
if you use CPU plotter you can rise stagger size to optimize plot...

I think that a raspberry pi has to low cpu-capacities for calculating those hashes. Maybe it'll work for <1TB, but not more. You also need a lot of cpu-power for the USB-Port (data transfer).

So PoC2 will lighten hardware requirements extensively? Will PoC2 require a replot?

Thank you for the link dev!
I'm going to read it!

Have a nice day!

PoC1 and 2 will be storing different things. PoC1 is storing a bunch of hashes which are used each block, but PoC2 will be storing nonces that meet certain conditions. PoC1 stores 64bytes / scoop / nonce, but for PoC2 only 4 bytes / scoop / nonce is needed since the nonces can be stored as 4 byte differences between them to save space.

PoC2 will be added to burst, and you'll be able to use either. At some point in the future PoC1 might have to be disabled, although that will not happen soon.

If you're interested in more in-depth details as how PoC2 will work, or why it is better, you might want to read this post https://bitcointalksearch.org/topic/m.10222877

hi dev!!!

can you explain in a few words,
how can ensure transaction/blockchain consistency with 1/16 of data?

and then... for the future

we will have this scenario?

1) burst --> POC
2) burts2[new coin] -->POC2

or we will have this scenario?

1) only burst with a new implementation from POC --> POC2?


thanks

If the USB 2.0 is the main issue, then maybe we can try banana pi with sata port, or maybe look for sata module for raspberry pi...

If crowetic already planned to start the raspberry test, and since I do not have a raspberry on hand yet, then I will wait for your proof-of-concept, 

Will PoC2 be adapted to Burst or are you planning on created a completely new coin?

PoC reads 1 4096th of the data each block, or more simply 256MB / TB.

PoC2 will most likely be around 16MB / TB

Not sure if that's in response to me Merick, but the weird thing is when I watch the transfer rates, it never gets anywhere near the drive sequential speeds. The drives aren't being maxed out on random seeks or the utilization would be much higher. It seems like it's entirely CPU bottlenecked.

On my Intel rig, I removed all but one drive and got it down to 42s. So 42s for 5TB, 106s for 25TB.

Can someone explain what optimizing does? From what I understand it reorders the plot so it's all sequential reads instead of any seeks? Doesn't the plotter do this when you plot? I only have one plot per drive and it doesn't seem like there are a lot of random seeks happening. Would/how would this help me?

I just did some calculations on my bottleneck and my issue is related to the PCIe 1.1 slot that I have my 4 port SATA III card installed in.

PCIe 1.1 has a max transfer rate of 250MB/s  split that between 4 drives and each drive can at most feed teh CPU data at 62.5MB/sec.  If I use itop in Linux to watch my I/O % rate I can see that my I/O goes from 50%-60% maybe a touch more sometimes.  This tells me that my CPU is waiting on data, bu it is pegged at 100% on both cores.... maybe its a miner optimization issue I'm note sure.

So, in my case under ideal conditions I am guessing that my system will peak out at 11.25TB to reach the 45 second marker.

62.5MB/sec max read,  256MB needs to be read per 1TB plot

4 seconds to read 1TB plot.

45sec / 4sec/TB

11.25TB can be scanned in that 45sec  for my crappy old Optiplex 380.

This is just quick 2:30am napkin math but it goes along with the current convo that mining burst is not just about having massive amounts of storage.

Or, maybe it's late and I am just missing something...  When I get to 11.25TB I will find out

sources:
http://blog.scoutapp.com/articles/2011/02/10/understanding-disk-i-o-when-should-you-be-worried
http://www.tested.com/tech/457440-theoretical-vs-actual-bandwidth-pci-express-and-thunderbolt/

Good-Luck

Yeah, more I look at it, the more it seems like you need a pretty beefy processor when you start tacking on the TBs. I added more memory and it definitely helped (I'll check the auto pagefile thing too), but it seems to have hit a wall.

I'm currently trying out a low end Intel I also have and it's better, but it's still not good enough. I'm at 25TB in 106s (last five finished plotting today).

Are there any plans for a GPU assisted miner? It was said a few pages back it's not needed, but it sorta seems like it is. I can imagine the low end GPUs would be put to good use. Based on the block height chart it seems like you want to get in under 45s, lower the better.

I didn't know you lost your chance at the block if a new block is issued before you finish reading the last, something that probably should be a explained somewhere. It's pretty fundamental and important, but since PoC is new, I had no idea that was a thing.

Also should be listed somewhere that plotting also takes a decently beefy CPU, even while using a GPU plotter. I ran into a wall around 60k nonces a second using the GPU plotter. No matter the number of HDs or GPUs I threw at it, it wouldn't go higher.


Hmmm maybe I'm not fully understanding this. Looking at the read numbers in Resource Monitor, on the Intel setup, it's reading the drives at about 16Mb/s, there is no way it could finish the entire drive in 106s at that speed. So mining doesn't read the whole drive, just parts of it?

I bet that it's good for about 2.5TB of optimized Plots in roughly 35-45 seconds. A Beagle Bone Black would be interesting to see also, better RAM and CPU but still that poor little USB 2.0 bottleneck.

 I look forward to seeing the results
Good-Luck

I'm already planning a test I'll keep ya posted.

Why don't you try, likr a proof-of-concept....? 

It would be quite interesting to know how a raspberry would do, especially as we call BURST "enegy-friendly".