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

I have a QNAP nas with 10 HDDs split in 4 different folder where I have stored the plot, on container station I have 4 Linux VM running URAY BURST MINER (LINUX X64) in order to have a parallels submission of the deadline, is that behaviour correct or is better use a single VM with all plots ?

I just watched and gave thumbs up as the animation is really simple and understandable. She should make more animations.

I'll tell her!!
I'm sure that after she will read your words she will get motivated to produce a new video

Hehe, that FUD guy should read this: https://en.wikipedia.org/wiki/Burstcoin#Origin_to_community_takeover

Burst is still young, undervalued but growing healthy with a big community.
I think there are plenty of people outside this forum who support Burst and they don't even post here.
Just think about burst-team.us or burstnation etc...

Really good work! Nice animations, good presentation, just wow!

someone with minus 16 in trust. wow, people may just do the opposite. LOL

crazy idea!
why sone ico, instead to gather ETH or BTC, don't use a Smart Contract available in BurstCoin?
i think this could be a really good vehicle, to let spread, burst features.

My wife created this video few days ago

https://www.youtube.com/watch?v=noUYEp3Q0Bw (FACTS ABOUT BURSTCOIN)

It's a simple presentation about this amazing coin and its features!!

you are very good man..
i think there aren't so many people who want to spend time to teach other...
i give you mi biggest thank you!!!

Perhaps all the technical babble is too much, there is a
simple answer:

You get more the faster you mine, up to a point.
This is a concurrency effect, see the explanation for fast consecutive blocks above.
As the average block time is 240s, it makes no sense to spend 1.2x the money to get 1.2x speedup
as long as you stay below 120s. Any additional expense "to make it even faster" may be lost money.


The sweet, most profitable spot (60s? 120s? 240s?) is up to you to find - this cannot be generalized, as everybody
has a different angle on this - cheap used disks vs. new, USB vs. SATA vs. 90slot SAS JBOD, …


I have not analyzed statistical data (all you'd need is on the blockchain) on fast blocks and
the effect for a specific given miner-volume;
"With my 100 TB I could have gotten 10 blocks more last month, if I had submitted 7 seconds faster".
These 10 Blocks (or 120 if you look at a year, or ...) must be considerable more than the expense
for speeding up mining 7 seconds. Otherwise it might be a better idea to spend 100$ on diskspace instead of a GPU.

My gut tells me, drop raid0.

the xplotter writes optimized plots. It will write the file twice, first with all-zeroes to actually allocate sequential blocks, and then the nonces into the right spots in the file. You don't need to re-optimize that. The I/O you see will be twice that of the finished file size.

The reason for all this "optimizing" complication is that the plot algo depends on the amount of RAM present at the moment of computation.
The "stagger size" (the amount that can be computed in one go) is reflected by this:
stagger=1 means one nonce, 64 Bytes (a scoop) * 4096 (in one nonce) = 256KiB.
You cannot plot anything if you don't have at least 256 KiB (plus code, obviously).
If you plot on a 4 GB GPU your max stagger is (below) 16384, because 16384*256KiB= 4GiB.
The resulting file (id_start_length_16384) would have a terrible read-performance, as only a single scoop (in all nonces) is read;
16384*64Bytes=1MiB, seek +4095MiB, read, …

The xplotter takes these 4096x 1MiB scoops and writes them to the "correct locations" in the file, doing the seeking ONCE while plotting.
In order for that to work, the file must be laid out already (hence the all-zero run). Do not turn on compression for this target, this
would totally destroy the whole effort.

I can't answer any NTFS-related questions, don't have any experience with that. Oh yes, I have: we've configured a 4k playback workstation (uncomressed, 1,8 GB/s) and the windows-builtin-striping yielded 1 GB/s, whereas a (aside from presenting 8 disks as one target, mostly dumb) Adaptec HBA gave us 4 GB/s. I myself use a bsd-unix for all this, the configured blocksize is 128k.


A raid0 stripe would complicate things; e.g. what is the default stripe-factor, what is the ideal factor for this usage pattern and how do you manipulate it ?

The expected read-throughput on a stripe (ideally, 4x ~150 MB/s) must be processed by the miner. The difference between 1 or 4 streams is the amount of RAM needed (mostly for buffering in the process/OS, and for computation (on the GPU, but this is negligible, but may interfere with your other mining code running there).

I would stick to single disks,
  less complicated
  no hassle should one disk fail
  apart from memory requirement (which can be tuned in the code) no negative impact,
  you are still free to choose between sequential or parallel mining, whereas mining a stripe with 4 streams may be slower, depending on your setup.

All this is futile - if you want "the fastest?/cheapest?/maxROI? setup possible" you have to experiment a bit.
There are just too many variables - you did not specify enough.

really thank you for you time vaxman!!!

i will plot on a fresh disk, with blago plotter XPlotter for optimized plots (CPU) (https://forums.burst-team.us/topic/3002/xplotter-for-optimized-plots-cpu/4).
i need to optimize again, after all is plotted? 
i think a big spead up with biggest file is the cluster size...i presume you format your hdd with 64kb clusters... right?
do you advise me against do a BIG RAID0???
thank you again

Both configs will work.
I'd keep the disks separated.
With both GPU and CPU miners you can either mine them sequentially or in parallel.
That depends on your objective;

GPU, parallel: fastest,
        but you have to make sure the opencl code for Burst is working in parallel with your other mining codes or you "lose" a GPU

GPU, sequential: about 1/4 the speed
        you still have to make sure the opencl code for Burst is working in parallel with your other mining codes or you "lose" a GPU

CPU, parallel:
       ideally, you have (up to) 4 cores for that, or you don't mind other processing takes a hit if you have 4 cores or less

CPU, sequential:
       you need just one core for this, it is the slowest, but impact on system is the lowest.
       Like outlined above, this would take ~70s on a single 2.1 GHz AVX2 core for 32 TB (~142 MB/s for 60s on every 240s block)

So, even the slowest (CPU, seq) variant would still finish mining a block in ~70 seconds.
In general you have 240s, but when a succession of multiple very fast blocks is on the net (say, 3 blocks with 30s), your 20s deadline for the first block in this sequence will be discarded if your miner publishes it after 240s, when 3,4,5 other fast blocks are on the chain already - it is the longer chain.

Hence the optimization for fast scanning. The "60s rule" is just just a fictional target, you choose your own depending on what your setup can do.

But there is this one thing: Your storage should be able to deliver this datarate. And this is much less a question of how many disks you stripe, but how the files are laid out physically. Therefore I hinted "large files, optimized";

example 1:  128 GiB file, plotted with a stagger size of 4096.

id_start_length_stagger
12345678901234567890_0_524288_4096

on every block, 128GiB/4096=32MiB  Bytes are read (from every 128 GiB plotfile).
The stagger indicates the inner layout of the plotfile, and with a stagger of 4096 that means just
4096*64=262144 Bytes (256 KiB) are sequential,
skip 4095*4096*64=1023,75 MiB,
read another 256 Kib, …
So you'd have 128 unnecessary seeks.

example 2: 128 GiB file, optimized

12345678901234567890_0_524288_524288
here the interesting scoop is laid out sequentially; 524288*64=32MiB
This *may* deliver >100 MB/s on a not-too-old SATA disk

example 3: 1 TiB file, optimized

12345678901234567890_0_4194304_4194304
here the interesting scoop is laid out sequentially; 4194304*64=256MiB
this *will* deliver >100 MB/s on a not-too-old SATA disk

But only when you create this file on a fresh, empty filesystem. If you optimize (reorganize, merge, ..) from and to the same disk,
the file will be fragmented. The inner structure is sequential, but the physical sectors won't be. So plot to one disk, optimize from there to the target.

Again, I have no idea of the inner workings of the all-in-one package mentioned above.
You should consult the forums, lots of info to be found; eg forums.burst-team.us

wow..
this is really usefull...
so, many thanx to you vaxman!!!
you are very skilled!
now another question...
i know who it's very dangerous do largest RAID0...
1) but do you tink it's more profittable for performance, mine all burst plots with gpu ove 4 separate HDD (D:\, E:\, F:\, G:\)?
2) or mine plots with CPU but over on a RAID0 array with mine 4X8TB hdd???
i think the response is with all together.. but i can't..
so, what is better???
Config 1) or 2)
thank you

Mine looked like it stalled at one point but I just kept it going and it finished up fyi.

You could use the online wallet as well immediately while you're waiting.

 Need some help

 the windows wallet Will not sync up no more it stops at 99.87% the ver is 0.3.9.3

I have uninstalled it deleted all files  then reinstalled it 3 times and the same thing it stops at 99.85 to 99.87%

 and all so  try older version ver 0.3.9.2 will not work either it will not sync up

and the pc is updated and has java installed .

 Any help would be appreciated

   kprell40

wow, timk225 is still around.
Normally I wouldn't feed this troll, but this is too good to pass.

The return I see is in the mid 5 figure $$ range.
But I started to mine in 2014 and sold only as much as needed to cover the initial investment.
I'm holding the rest and smile whenever I look at the exchange rates.

The ROI for new equipment is at about 15 months now (with european VAT and energy costs, so much lower in other parts of the world).
If you put cheap used gear to work, it's even better.

I guess, could it be that you're just jealous ?

I have been running a mining rig since 8/2014 on a fat 32c machine with 6x PCIe (Gen2) slots.
Never had any io-bottleneck, and this is a very busy machine.

I/O:
To mine 1 TB you have to read 1TB/4096=256 MB.
If you want to finish in under 60 seconds, that is 4,5 MB/s of bandwith for one minute every 4 minutes.
Now lets say you connect 8x 8TB disks to your rig, that would mean 286 MB/s of bandwith for one minute every 4 minutes.
I/O wise this is not even saturating a single PCIe (Gen3, ~1 GB/s) lane, and even a single SSD yields about 500 MB/s.

compute:
If you have a AVX2-capable CPU, the computing takes up just seconds per block (4 minute block time).
I just ran a test; on my 2.1 GHz E5 combing 60 TiB takes 140 cpu-seconds (divisable by number of cores that you can spare for this).
The speed increase is (nearly) linear w/regard to clock speed, so you might easily get away with 2 cores @ 2.5 GHz for 64 TB in under 60 seconds.
Using a SSE4-only CPU roughly doubles the CPU time, using (part of) a GPU (via opencl, support included in the java-wallet) is faster by
a factor of 2-10, depending on your GPU.

plotting:
I did most of my plotting on several (now historic) 280x, yield was 170 MB/s per GPU.
To put this into perspective, the AVX2 code on 2.1 GHz gave me 3.8 MB/s per core. SSE4 is about half of that.
hint: If you're going the manual route (like real men do), use large files (500+ GB), plot to a temporary target,
optimize plotfiles from temporary to the final disk. I have no idea about the AIO package or Windows in general.

just my 0.02.

This one should work


https://db.burst-team.us/db.zip

 Help

   try to fine a good download file of the Blockchain

  this one not working

  https://web.burst-team.us/index.php/wallets/

  http://db.burst-team.us/


  can some one help

   ty

try to ask here http://forums.burst-team.us/