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

This is the worst coin i have tried to setup! It's annoying as hell and time consuming! For two days i have been trying -.-

I did a 1 optimized vs a 1 unoptimized comparison on two different systems and both unoptimized drives were faster. I just did 2x optimized vs 2x unoptimized and the unoptimized pair were still faster. I can imagine the unoptimized drives are even faster with more memory and a higher stagger size.

Watching the reading numbers in resource monitor, the unoptimized drives read faster then the optimized drives as per my screenshot on the last page, which I confirmed on two different systems.

I understand what 'optimizing' is supposed to do (sequential vs random seeks), but it doesn't seem to be doing it, I messed up the optimization somehow, or I'm supposed to tweak Blagos miner somehow to better utilize the optimized plots. If a disk goes from mainly random seeks to sequential transfers, it should be much, much faster, especially on my 5900RPM drives, it's not doing that though. That should be a given regardless the number of disks on the system.

Sequential throughput on these drives is from 80-180MB/s. It's reading the optimized disks at 10MB/s.

Also worth mentioning, these are 5TB drives.


It could very well be that my systems are too slow to properly utilize the optimized drives, however, the unoptimized drives shouldn't be faster. I mean I'm not making this stuff up, I'm reading this out of resource monitor and looking at the mine times on Blagos.

This may have something to do with the unoptimized drives still using a stagger, while the optimized ones no longer use a buffer(stagger?). Is there anyway to force a optimized drive to continue to use a buffer?

I plot & optimize at my high-end system (i7+32gb) but I mine on a very low-end system (atom+4gb) for 24/7.

My questions regarding mining performance...
 - Is there a recommended settings for generator_plot & miner using low-end system I should keep in mind?
 - Is it normal to see a lot of "no deadline" mining status on a 1TB plotted disk?
 - Let say using couple of 3TB, is there a mining performance difference with 1 plot per drive vs. multiple plots per drive?
 - does USB 2.0 overhead scanning of HDD?

Thanks in advance!

^I'm on core i7 16GB, 30 TB plots on 8 external USB 3 drives. The optimization is ordering your plots in a way that each block it reads sequential from your HDD with much less seeks. HDDs are much, much faster with sequential reading. When some of the plots are optimized and others are not you can't see a big difference, but when they are all optimized you'll read your plots much faster.

It'd only be different for 'bulk' mining, where my CPU and memory are being maxed out. It seems inferior from a performance perspective on a faster PC (CPU and memory).

Considering this takes a day and a half to optimize each drive, and a day to replot if this ends up messed up, I really am not very interested in just taking another leap of faith here as the answers I'm starting to find are more and more conflicting.

Like the 'merge' tool, which isn't really a merge tool... It increases your stagger size to it's maximum?!? I was under the impression your stagger size is equivalent to the amount of memory I have. In some spots I'm reading the optimizer and the merge tool are one in the same, just called different things.


Edit: Put both optimized disks into the A4-4000. 2x optimized disks being mined takes 79s, 2x unoptimized disks being mined takes 67s.

That's what i thought at the begging. Just optimize all your plots on all your drives and then you'll see the difference.

Alright... What am I doing wrong? Optimized plots take longer to scan then unoptimized plots.

It's starting to seem like the only way to improve scan times is with a faster processor and more memory (bigger stagger size), contrary to what I've been told. Optimizing only helps on really low end systems (CPU/Memory). It's counterproductive if you have a fast CPU and lots of memory.

I may try to create an croedfunding AT for this project of mine: zRMicroArray - phase 2 - Gene Expression Analysis software. Phase 2 of the project won't be expensive, so I may be able to collect the funds needed to reach phase three by crowdfunding. Meanwhile if anyone is interested to send some BURST for this project: BURST-GFWT-LEP4-Q592-62JQZ

Wow, I'm new to burst and I have nearly 6TB but cannot even get 1.2k per day most of the time at burst.ga, and was thinking to try pool.burstcoining.com... But I thought that was normal because https://bchain.info/BURST/tools/calculator shows that average of 1.5k per day with 6TB, I never think of can have more than expected, or the calculator shows a conservative earning?
Do you mind to share which pool do you used previously with 4TB that made 3~4k per day? Thank you very much 

And I forged a block 19 hours ago but still no reward payment yet... Don't tell me this is the same bug that happened to me again in V2 pool   

Any pool with bug fixed? Or maybe I really should spare time to create a new pool with brand new coding~~   

This is weird... Could anyone tell me why a optimized drive takes longer to scan then a non-optimized one? I just finished one of my 5TB drives and it takes more time to scan then one of the unoptimized drives. I used J6s optimizer, the drives are identical. I tested it against a different drive on the same machine. It doesn't seem to use any memory and overall uses less CPU then the unoptimized drive, but that doesn't matter if it takes longer to read through.

Unoptimized drive, same size, make, plot size, and model, takes 9 seconds less to read through then a optimized drive. 60s vs 69s.

Also the read pattern for the optimized drive looks like little spikes, compared to the optimized drive which has long 'bursts' of data transfer, even if it's at 100% utilization.

This is on my A4-4000 with 8GB of memory.





Optimized drive is H: Unoptimized drive is D:


Edit: Just completed another drive on my low end Intel PC. That disk (optimized) takes 57s to read through vs 46s (unoptimized) to read through. The optimized disk uses less ram and CPU, but still takes longer to read through.

crowetic regarding your pool http://pool.burstcoining.com:8124/ how does payments work on this as I seem to be earning a lot less than I use to make and generating about 4 to 5K burst per day I am currently growing my plots to about 10TB or so and when I was mining on other pools with only 4TB plotted was making about 3 to 4k per day. What is different  on your pool that is causing a reduced pay out daily.

Also the payments that are set is their any option to increase them as my wallet getting attacked with liek 5 burst 4 burst or 10 burst payments

It always looks like that at the end of the day, it must be some bugg

 

nice too see this coin going up and increasing on prices. Am doing nothing but holding my stash of coins no point in selling any time soon. Maybe coin will hit 10x this in the coming months and improvements that are made to the coin.

@Blago: i've reached 24 threads with the miner. Should i just run another instance of the miner with the additional drives/threads? I liked keeping it consolidated within a single window.

We now have 220sat on poloniex with nice volume and 215 at bittrex. The trend is clear since early November:



We are now at 260sat and 40btc in volume. Innovation can influence the market; not only big IPO.



***EDIT: updated the pic

This is amazing news. Keep up the innovation! Perhaps this is the next NXT.

I love how well the supply is distributed. Probably the most fair distribution I've seen so far.

I would like to expand on this a bit.

Technically our Devs are ready to launch the first crowdfunding (CF) case as we planned to do, but during intensive and very constructive discussions on the subject, a number of new ideas emerged.

One of them concerned a roadmap specifically for CF cases handled by the PR Team. From the responses here and on BurstForum.com, we can identify a rather limited number of CF cases. Considering that, we'd like to have a flexible roadmap, where all Bursters can suggest a new case at any time. Priorities might change with time. Conclusively, we'd like to create a roadmap highly influenced by the community and various supporters. It's you - miners and traders - who really experience BURST's needs now as well as when new emerge.

Acting responsible must involve listen to the community to a large extent. A successful CF will require community support. Launching today, as we had planned, we'd simply risked not to earn your trust. We will present a flexible model how to manage these "Community-supported Crowd-funding Cases".



Due to this, and a few other issues discussed, we agreed to postpone the launch of the first (of many) CF cases in about ~24 hours. Offering, among other things, a flexible roadmap.

Besides the quoted text by vbcs, I want to point out that we are working on a more detailed guide. Also, in future versions of the wallet, it will be a lot easier to find the ATs like to recurrent LuckyAT.

Hot annoucement directly from the PR Team:
 
Soon @vbcs will release the Crowdfunding AT Beta! There you can support or create a new crowdfunding for your future big project, helping a social cause like a charity for Ebola or "Save the Children", scientific investigations, or to get funds to record your music. All the funds will go to the owner of the CF if he gets the 100% of the funds by the closing date.

Remember that you can keep updated on Burst in our twitter @real_BURSTCOIN, follow us!