Topic: [ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000 - page 463. (Read 2170648 times)
January 23, 2015, 02:07:07 PM
Hmmm, thanks for the help. I'll throw more memory at it and see what happens later today. The SSD isn't sitting at 100% utilization though or anywhere close to it. It seems like it's all a CPU bottleneck.
January 23, 2015, 01:55:34 PM
The performance monitor is different than the resource monitor, it just allows for more tweaking of the information presented. Either way, it doesn't matter.
It looks like your page file on your C drive is being nailed during the plot reading, I wonder if this is whats causing the problem. Windows is trying to cache all of the plot files so it has to read it, write it to the page file, and then process it..... Burst and Linux defiantly play nicer, none of this caching.
Blago made a post a few pages back about how Windows will perform much better with plot files in the range of 200-300GB and this caching issue I believe was the reason
I blame the Windows caching issue with large file sizes, switch to multiple plot files within each drive and then optimize those files, I bet your problems go away.
Other than that I am all out of ideas.
Good-Luck
It looks like your page file on your C drive is being nailed during the plot reading, I wonder if this is whats causing the problem. Windows is trying to cache all of the plot files so it has to read it, write it to the page file, and then process it..... Burst and Linux defiantly play nicer, none of this caching.
Blago made a post a few pages back about how Windows will perform much better with plot files in the range of 200-300GB and this caching issue I believe was the reason
I blame the Windows caching issue with large file sizes, switch to multiple plot files within each drive and then optimize those files, I bet your problems go away.
Other than that I am all out of ideas.
Good-Luck
January 23, 2015, 01:05:03 PM
I may be wrong, but those performance graphs are only showing you Que length aka how many read operations are being stacked up waiting to be processed. The top graph is showing you the read performance for a drive and its only showing about 20MB/s.
(http://superuser.com/questions/331973/in-the-resource-monitor-of-windows-7-what-does-the-disk-queue-length-really-m)
Trying going to the actual performance monitor and add counters for physical disks to the chart. This should give you a better idea of what is happening with your drives. ( START MENU --> SEARCH MENU -->
It's still odd that your only reading 20MB/s what happens if you only use one of the 5TB plots, will your read rate increase?
Good-luck
(http://superuser.com/questions/331973/in-the-resource-monitor-of-windows-7-what-does-the-disk-queue-length-really-m)
Trying going to the actual performance monitor and add counters for physical disks to the chart. This should give you a better idea of what is happening with your drives. ( START MENU --> SEARCH MENU -->
It's still odd that your only reading 20MB/s what happens if you only use one of the 5TB plots, will your read rate increase?
Good-luck
That's the windows 8 resource monitor. Looking on the side, the drives are operating at 7MB/s a piece. The blue line on the graphs shows overall 'utilization' though, if it's maxed out it's saturated with seeks or it's at maximum sequential operation.
Top graph is all the drives averaged across the board. As per the last post, the miner is using 33MB/s maximum across all four drives.
Using one drive it reads at about 18MB/s.
January 23, 2015, 12:42:04 PM
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.
Good-Luck
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.
Good-Luck
Yeah, it's a A4-4000, typo.
Stagger size is 8192. Eight gigs of memory, SSD as well.
They're running on SATA 2.
I plotted using Cryo's GPU plotter. Would using more then one GPU, plotting using buffer mode instead of direct, or plotting more then one hard drive at the same time mess up the plots?
There seems to be a lot of hidden nuances here I tried to sort out with questions, but got conflicting information on or didn't know were a problem in the first place.
During the mining phase the CPU hits 100% but the HD usage is minimal, which I found as odd. Blue line is utilization, if it was maxing out the drive on seeks the blue line would be at 100%.
The 'bigger' read is when I'm not connected to the server (remote desktop). I may have to do some light overclocking.
It looks like the miner (Blagos) is reading at 35MB/s overall, to all the drives.
Already checked reads with HD Tune, sequential is from ~180-120.
I may be wrong, but those performance graphs are only showing you Que length aka how many read operations are being stacked up waiting to be processed. The top graph is showing you the read performance for a drive and its only showing about 20MB/s.
(http://superuser.com/questions/331973/in-the-resource-monitor-of-windows-7-what-does-the-disk-queue-length-really-m)
Trying going to the actual performance monitor and add counters for physical disks to the chart. This should give you a better idea of what is happening with your drives. ( START MENU --> SEARCH MENU -->
It's still odd that your only reading 20MB/s what happens if you only use one of the 5TB plots, will your read rate increase?
Good-luck
January 23, 2015, 12:15:20 PM
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.
Good-Luck
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.
Good-Luck
Yeah, it's a A4-4000, typo.
Stagger size is 8192. Eight gigs of memory, SSD as well.
They're running on SATA 2.
I plotted using Cryo's GPU plotter. Would using more then one GPU, plotting using buffer mode instead of direct, or plotting more then one hard drive at the same time mess up the plots?
There seems to be a lot of hidden nuances here I tried to sort out with questions, but got conflicting information on or didn't know were a problem in the first place.
During the mining phase the CPU hits 100% but the HD usage is minimal, which I found as odd. Blue line is utilization, if it was maxing out the drive on seeks the blue line would be at 100%.
The 'bigger' read is when I'm not connected to the server (remote desktop). I may have to do some light overclocking.
It looks like the miner (Blagos) is reading at 35MB/s overall, to all the drives.
Already checked reads with HD Tune, sequential is from ~180-120.
January 23, 2015, 11:58:14 AM
What's a good amount of time for reading on a block? I'm up to two minutes(133s~). I have four 5 TB drives. Based on the responses a few pages ago, I thought mining time wasn't that big of a deal. I'm using a A4-4420 with eight gigs of memory.
Can that be optimized or am I screwed without a better processor?
This makes me wish there was a GPU miner all the more.
If you take a look at this chart http://burstcoin.eu/charts/average-block-generation-time
you will see that it would be best to optimize your setup, plus you said yourself you get the error at least once a block.
I think your hardware should be able to manage 20tb, at least under linux.
Then again, you'll have to wait for one of the bigger miners to help you with that. I have peanuts in plots
I'm using w8.1 x64, I don't have any interest in switching to nix.
Yeah, I get that error about once per block, sometimes twice, sometimes not... Two minutes is too long then based on that chart. I got conflicting answers when I asked about mining hardware before then and a beefy processor is pretty much a requirement.
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
January 23, 2015, 11:53:36 AM
What's a good amount of time for reading on a block? I'm up to two minutes(133s~). I have four 5 TB drives. Based on the responses a few pages ago, I thought mining time wasn't that big of a deal. I'm using a A4-4420 with eight gigs of memory.
Can that be optimized or am I screwed without a better processor?
This makes me wish there was a GPU miner all the more.
If you take a look at this chart http://burstcoin.eu/charts/average-block-generation-time
you will see that it would be best to optimize your setup, plus you said yourself you get the error at least once a block.
I think your hardware should be able to manage 20tb, at least under linux.
Then again, you'll have to wait for one of the bigger miners to help you with that. I have peanuts in plots
I'm using w8.1 x64, I don't have any interest in switching to nix.
Yeah, I get that error about once per block, sometimes twice, sometimes not... Two minutes is too long then based on that chart. I got conflicting answers when I asked about mining hardware before then and a beefy processor is pretty much a requirement.
January 23, 2015, 11:37:49 AM
What's a good amount of time for reading on a block? I'm up to two minutes(133s~). I have four 5 TB drives. Based on the responses a few pages ago, I thought mining time wasn't that big of a deal. I'm using a A4-4420 with eight gigs of memory.
Can that be optimized or am I screwed without a better processor?
This makes me wish there was a GPU miner all the more.
If you take a look at this chart http://burstcoin.eu/charts/average-block-generation-time
you will see that it would be best to optimize your setup, plus you said yourself you get the error at least once a block.
I think your hardware should be able to manage 20tb, at least under linux.
Then again, you'll have to wait for one of the bigger miners to help you with that. I have peanuts in plots
January 23, 2015, 11:27:52 AM
If you get 'fast block or corrupt file' about once per block is that normal? It doesn't happen on the same plot, it seems to be random. Sometimes it happens two times per block, sometimes not at all.
have you optimized your plots?
this happend for my 2Tb drive until I optimized them, zero errors since then.
https://burstforum.com/index.php?threads/plot-optimizer-v1-6-j6jq.268/
Not sure how to optimize them. They're 5TB drives with a single plot on each of them.
Well I know it's a pain by you might consider replotting. You miss out on some deadlines you might catch just because you haven't had enough time to read your plots.
Smaller plots are also easier to optimize, to optimize a 5tb plot you need another empty drive to do it.
Usual suggestion I've seen is to make 200gb plots.
I'm mining solo, how do you know if you missed a deadline?
The message 'fast block or corrupt file' means, among other things, that new block was found before you managed to read through all your plots. For example if that block had a 28 sec time and it takes you 40 to read through all of your plots, the plot you did not have time to read MIGHT have contained a better deadline.
You cannot really tell whether it had a better one, however since the possibility does exist, it is better to protect yourself against it. Otherwise some of the space you plotted is, for all rights and purposes, wasted.
What's a good amount of time for reading on a block? I'm up to two minutes(133s~). I have four 5 TB drives. Based on the responses a few pages ago, I thought mining time wasn't that big of a deal. I'm using a A4-4420 with eight gigs of memory.
Can that be optimized or am I screwed without a better processor?
This makes me wish there was a GPU miner all the more.
January 23, 2015, 11:18:04 AM
If you get 'fast block or corrupt file' about once per block is that normal? It doesn't happen on the same plot, it seems to be random. Sometimes it happens two times per block, sometimes not at all.
have you optimized your plots?
this happend for my 2Tb drive until I optimized them, zero errors since then.
https://burstforum.com/index.php?threads/plot-optimizer-v1-6-j6jq.268/
Not sure how to optimize them. They're 5TB drives with a single plot on each of them.
Well I know it's a pain by you might consider replotting. You miss out on some deadlines you might catch just because you haven't had enough time to read your plots.
Smaller plots are also easier to optimize, to optimize a 5tb plot you need another empty drive to do it.
Usual suggestion I've seen is to make 200gb plots.
I'm mining solo, how do you know if you missed a deadline?
The message 'fast block or corrupt file' means, among other things, that new block was found before you managed to read through all your plots. For example if that block had a 28 sec time and it takes you 40 to read through all of your plots, the plot you did not have time to read MIGHT have contained a better deadline.
You cannot really tell whether it had a better one, however since the possibility does exist, it is better to protect yourself against it. Otherwise some of the space you plotted is, for all rights and purposes, wasted.
January 23, 2015, 11:12:21 AM
If you get 'fast block or corrupt file' about once per block is that normal? It doesn't happen on the same plot, it seems to be random. Sometimes it happens two times per block, sometimes not at all.
have you optimized your plots?
this happend for my 2Tb drive until I optimized them, zero errors since then.
https://burstforum.com/index.php?threads/plot-optimizer-v1-6-j6jq.268/
Not sure how to optimize them. They're 5TB drives with a single plot on each of them.
Well I know it's a pain by you might consider replotting. You miss out on some deadlines you might catch just because you haven't had enough time to read your plots.
Smaller plots are also easier to optimize, to optimize a 5tb plot you need another empty drive to do it.
Usual suggestion I've seen is to make 200gb plots.
I'm mining solo, how do you know if you missed a deadline?
January 23, 2015, 11:10:48 AM
If you get 'fast block or corrupt file' about once per block is that normal? It doesn't happen on the same plot, it seems to be random. Sometimes it happens two times per block, sometimes not at all.
have you optimized your plots?
this happend for my 2Tb drive until I optimized them, zero errors since then.
https://burstforum.com/index.php?threads/plot-optimizer-v1-6-j6jq.268/
Not sure how to optimize them. They're 5TB drives with a single plot on each of them.
Well I know it's a pain by you might consider replotting. You miss out on some deadlines you might catch just because you haven't had enough time to read your plots.
Smaller plots are also easier to optimize, to optimize a 5tb plot you need another empty drive to do it.
Usual suggestion I've seen is to make 200gb plots.
January 23, 2015, 10:52:08 AM
If you get 'fast block or corrupt file' about once per block is that normal? It doesn't happen on the same plot, it seems to be random. Sometimes it happens two times per block, sometimes not at all.
have you optimized your plots?
this happend for my 2Tb drive until I optimized them, zero errors since then.
https://burstforum.com/index.php?threads/plot-optimizer-v1-6-j6jq.268/
Not sure how to optimize them. They're 5TB drives with a single plot on each of them.
January 23, 2015, 09:44:05 AM
Due to scams of several BTC, Wulfcastle is no longer in anyway associated with BURST's community PR Team.
Do not do business with him.
Do not do business with him.
can you elaborate the miss understandig with wulf???
thanks
https://burstforum.com/index.php?threads/http-burstcoin-info.571/
January 23, 2015, 09:34:52 AM
Due to scams of several BTC, Wulfcastle is no longer in anyway associated with BURST's community PR Team.
Do not do business with him.
Do not do business with him.
can you elaborate the miss understandig with wulf???
thanks
January 23, 2015, 09:29:26 AM
Due to scams of several BTC, Wulfcastle is no longer in anyway associated with BURST's community PR Team.
Do not do business with him.
Do not do business with him.
January 23, 2015, 08:31:31 AM
Finally we are back 
Back with what?new plan or new high price?
Both actually
Prices should really move up in a few days, if the market isn't totally crazy. At the moment we work very hard on some "news". Part of the PR plan will also be posted sooner today.Meanwhile you are all very welcome to join our Twitter account, that has been rather busy the last two days: https://twitter.com/real_BURSTCOIN
EDIT: @xizmax: full steam, hehe..? Nah, I mostly try to get other people to do the work
There will come a "thank you" post to a lot of people in awhile from me. January 23, 2015, 07:23:21 AM
Finally we are back
Back with what?new plan or new high price?
I think he referred to btctalk being back up
However, mmmaybe is going full steam with PR efforts.
January 23, 2015, 07:20:15 AM
Finally we are back
Back with what?new plan or new high price?
January 23, 2015, 07:11:49 AM
I will, but it's unacceptable to act that way. If you don't understand something, kindly explain what you don't understand, I'll more than happily assist.
This community is nothing but helpful, I tried pointing the guide out gently
it is very easy to understand with basic computer knowledge.mine burstcoin it is much more easy to mine a lot of GPU/ASIC coins algo!!!
and this for sure!!!!
you install wallet/passphrase
then you plot files
then you mine files plotted..
that's all!!!
You forgot the part where you need to buy a shit ton of HDD's to mine any decent amount now =P
i hope they already have it!!!
maybe not a ton!!!
at least a dozen of libbre!!!
Jump to: