|
|
|
|
|
Even in the event that an attacker gains more than 50% of the network's
computational power, only transactions sent by the attacker could be
reversed or double-spent. The network would not be destroyed.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
bensam123
|
 |
January 23, 2015, 02:52:08 PM |
|
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. |
|
|
|
|
|
xizmax
|
|
January 23, 2015, 03:10:48 PM |
|
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. |
|
|
|
|
bensam123
|
|
January 23, 2015, 03:12:21 PM |
|
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? |
|
|
|
|
|
xizmax
|
|
January 23, 2015, 03:18:04 PM |
|
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. |
|
|
|
|
bensam123
|
|
January 23, 2015, 03:27:52 PM |
|
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.  |
|
|
|
|
|
xizmax
|
|
January 23, 2015, 03:37:49 PM |
|
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-timeyou 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  |
|
|
|
|
bensam123
|
|
January 23, 2015, 03:53:36 PM |
|
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-timeyou 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. |
|
|
|
|
|
Merick
|
|
January 23, 2015, 03:58:14 PM |
|
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-timeyou 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 |
|
|
|
|
|
bensam123
|
|
January 23, 2015, 04:15:20 PM
Last edit: January 23, 2015, 04:27:25 PM by bensam123 |
|
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 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. |
|
|
|
|
|
Merick
|
|
January 23, 2015, 04: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 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 --> <type "Performance Monitor") 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 |
|
|
|
|
|
bensam123
|
|
January 23, 2015, 05: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 --> <type "Performance Monitor") 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. |
|
|
|
|
|
Merick
|
|
January 23, 2015, 05: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
|
|
|
|
|
|
bensam123
|
|
January 23, 2015, 06: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.
|
|
|
|
|
crowetic
Legendary
 Offline
Activity: 2282
Merit: 1072
https://crowetic.com | https://qortal.org
|
|
January 23, 2015, 06:38:35 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.
Memory upgrade and CPU overclocking is what I would try first. Also, make sure your page file is set to AUTO for the drives. I noticed that when I manually set the pagefile, nasty things happened. |
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▒ ▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓ ▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓ ▒▒▒▒▒▒ ▓▓▓▓▓▓▒ ▓▓▓
▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▒ ▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓
|
ORTAL
| .⊙.Web and Application hosting.
⊙ decentralized infrastructure
.⊙.leveling and voting.
| Founder/current dev group facilitator |
[/td][/tr][/table] [/table] |
|
|
|
ik_do
|
|
January 23, 2015, 07:23:49 PM |
|
a few things
-download page on official website doesnt work and has broken images
-twitter page has no logo or link to main website
-readme.txt contains no instructions beyond telling people how to sync clocks so I can't figure out how to get the wallet running; if I try and run the bat file I get an error saying I need Java despite already having it installed.
|
|
|
|
|
|
SecretsOfCrypto
|
|
January 23, 2015, 07:29:10 PM |
|
I really like this coin but when will the mining deflation slow down?
|
|
|
|
|
|
xizmax
|
|
January 23, 2015, 07:46:33 PM |
|
a few things
-download page on official website doesnt work and has broken images
-twitter page has no logo or link to main website
-readme.txt contains no instructions beyond telling people how to sync clocks so I can't figure out how to get the wallet running; if I try and run the bat file I get an error saying I need Java despite already having it installed.
The site is being redeveloped due to issues described a few pages back. https://twitter.com/real_BURSTCOIN does infact have a logo Java is a bit trickier, out of the box you need java7. Burst is reported to work with java8 but you'd need to edit files yourself to change the references from java7 to java8. Also, mac people for example have had to get jdk in some cases, not only jre. Crowetic's guide has it laid out well https://docs.google.com/document/d/1ytq47AmQZ1rzjoFuMW33c82JkuJ1L61Pdp95ZLbi3-k/edit?usp=sharingI really like this coin but when will the mining deflation slow down?
What exactly do you mean? Block reward decreases 5% a month |
|
|
|
coinits
Legendary
Offline
Activity: 1582
Merit: 1019
011110000110110101110010
|
|
January 23, 2015, 08:01:37 PM |
|
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.
you need to add this to the trust system to protect others |
Jump you fuckers! | The thing about smart motherfuckers is they sound like crazy motherfuckers to dumb motherfuckers. | My sig space for rent for 0.01 btc per week.
|
|
|
|
mmmaybe
|
|
January 23, 2015, 08:34:11 PM |
|
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.
you need to add this to the trust system to protect others Personally I wasn't scammed, I'm only very angry, but I really hope those who were victims use the trust system, just as you say. |
|
|
|
|
