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

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

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).

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, 

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

PoC2 will most likely be around 16MB / TB

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

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

PoC2 will most likely be around 16MB / TB

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.

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

PoC2 will most likely be around 16MB / TB

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'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".

Mmmm... I was thinking to try mining with raspberry pi b+ to save electricity, and I don't it is possible now after reading you post above. I think that the reason why I did not see anyone mine burstcoin with raspberry pi yet...

I cannot find the specs on that CPU, is this a laptop?

When you say your at 2min for reading a block, does that mean it takes you 2min to scan your plot file?

I compared a AMD A4-4000 to my old Intel E5800 and the specs are sorta similar so I'm guessing your processor is similar to mine.

Everyone keeps saying that hard disk space is all that matters, but this is very misleading.  You also need a CPU that can process the data and a decent hard drive connection interface to get the data from the drive and into the CPU.  The hard-drive connection is more important that the CPU.

What is your stagger size on that 5TB plot?  If 8GB ram I am guessing your stagger is not greater than 10000.  What is your hard-drive connection?  if your reading this through USB 2.0 your max on paper read rate will be 60MB/s but take into account overhead and a low plot stagger and your probably looking at ~30MB/s.

I believe that 256MB/TB of plot size is read during each block (dev post on POC vs POCv2), if this is so then at 30MB/s it would take a USB 2.0 ~43 seconds to read the plot.  If your using windows go to the performance monitor --> Disks and watch the read rate for your drive, you can do the same thing in Linux.  This will give you an idea of were you are.

With the CPU I compared your's to I am able to read ~8TB of plots across 5 drives in about 35 seconds.  This speed will increase once I optimize my larger 3TB plots.

Reading a plot that is optimized will utilize your drives sequential read specifications.  Reading a plot that has a low stagger will utilize your drives random read specifications.  I higher stagger will move closer to optimized levels.  I have not created a graph showing this relationship so I do not know the cut-off point but there is a significant difference between the two ends of the scale.

Download a utility like CrystalDiskMark http://crystalmark.info/software/CrystalDiskMark/index-e.html or HDTune and see what your drive is capable of, especially the sequential read indicator, this will be the max you can read with an optimized plot.  Doing this will help pin point the bottle neck, and I am guessing it is not the CPU but a combination of hard drive connection type and low stagger.

* Edit * I just re-read your post, I missed the 4 x 5TB part.  Sorry.  But still basic benchmark testing to find bottle necks still applies.

Good-Luck

Uray seems to have disappeared, strange it was right after my declining his offer to purchase all of his projects. Hoping he's in good health, and okay.