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

Did him accept bitcoin or only nxt ??

only solo. pool crashes and ddoses are too risky for my likeings.
my current setup is only for test purposes to get used to the mechanics used by poc.
forget about all read access caching methods except you want to integrate the minercode into your system cache algorythms.
maybe combined with a hdd bios mod you may improve the access time for reads ;-)
the most tricky part is to ensure that all your files get parsed in time if you go centralized.
this requires fast cpus during the mining and even faster diskio and a certain amount of memory.
at the moment my cheapest way to archive fast mining costs about 100-120$ a year for each tb if you think big.
if you build this in small (<.5 pb) costs almost explode above 150$-200$ for each tb in a year.
for the plot creation a centralized storage is really nice cause you can fire up as many workers as you have to fill the storage.
for the mining a centralized storage approach depends on how many cores can mine simultanously.
if you can afford quad smp 12 core servers the centralized thing works perfectly.
if you would split this to many quadcore machines you would have to run 12 machines and give them fast access to the plotfiles.
if you directly attach the storage to them it still costs more than if it is centralized.
finally you can only make a decision if you know how big you want to grow.
sas or sata also depends on how much disks you want to run in total. at a certain point you simply require the additional performance sas provides.
i also thought of setting up a rentable mining farm with 3-4 pb but at the moment i think its better to mine on my own.
if burst goes up to 5000 satoshi and more i am fine with it. if it stays low and goes lower i dont want to run a prepaid service which is unprofitable and blocks resources only because its paid.
at current volume and prices directly buying burst instead of mining it may be cheaper.
its really hard to predict how fast the network grows but i can fill up 100tb with one gpu node in less than 100h.
so if i put 10 gpu nodes on the job  one petabyte is plotted in less than 5 days.
this also means that i have only 5 days to add another petabyte to the storage.
the good thing about a hardware invest is that it takes 2 years or more before the current disk capacity doubles.
two years ago the first 4tb hdds were available and today (2 years later) the first 8tb samples are shipped.

in the wallet:
left side - assets exchange
top right add asset button (below navbar menu)
enter the asset id of the purchase ( the pool shares)
etc..

Ill take 5 shares but I have no idea how to do it. Make it simple for me. Keep it to the moron level. PM me or post here I don't care.

img fixed

He means trust on the forum. lol.

Please pm me about this so I get this setup asap. Again fees are 0!

Start with pressing print screen.

I have this problem



Can someone help me?  

Thanks to bipben's advances with the GPU plotter, I'm at a point where disk bandwidth writing to the file is the bottleneck.  Has anyone found a solution to this better than RAID0 or rewriting the plotter with some kind of buffered asynchronous I/O?

Edit: If I measure the disk bandwidth directly, it seems like it's good enough.  But if I point the plotter at a ramdisk or SSD or comment out the output command in the plotter source code, it's four times faster than the disk I actually want to plot to.

Edit 2: I think my earlier bandwidth measurements were corrupted by some kind of buffer in linux.  Seems to go very fast for the first gig, but not for a 4GB file.  

If you tell me what it means and how to do it, I probably will.  I'm new to NXT.

I bought 5, will buy more.

Are you solo mining?
If it takes so long for the plotting, would it make more sense to distribute the plotting over a bunch of computers that are each accessing a large ZFS device (say 1 PB) and plotting seperately? Would it make more sense to carve it up as seperate zVols and present each over 40 gig QDR to the plotter servers, or just hit the main server over 20 GB (2 x 10GB LACP bond) SMB?
It is made up of several hundred SAS disks and has PCI-E SSD level2 caches as well as half a petabyte of RAM for level1 caching.

64% load means the miner/kernel can be optimized still. The modded kernel seems to keep the nonces/min rates mostly nominal.

come on guys, only 25 shares have sold so far.
we need to raise enough capital to actually buy mining equipment.
if anyone wants to buy shares directly with BTC I can arrange to send you the shares in return for BTC (to save us from having to dump the BURST - we can use the c-cex/poloniex FMV to calculate the conversion)
once we have enough capital to actually acquire some miners we will be able to start paying dividends.

both works but if you mine on zfs you may require to disable prefetching and tweak some other stuff to optimize the read process.
i can confirm that 250 tb work great 

Common community do a little work here vote for this 2 exchanges

https://hitbtc.com/vote
https://bter.com/voting

Tweet bittrex @BittrexExchange about adding BURST

We cannot wait only for the dev to work here ....

Can I plot on ZFS block devices?
(ie, 400 TB devices)

can I plot via SAMBA/CIFS on remote shares???

I will right now. Thanks for doing that.

Doing all my trading on BTER so I can acquire more points to vote for BURST!