Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150 - page 11. (Read 161727 times)
June 22, 2012, 12:20:39 PM
Works well. Thank you.
June 22, 2012, 03:42:10 AM
A new testing version has been released.
Binaries: http://www.ztex.de/btcminer/ZtexBTCMiner-120622.jar
Source: http://www.ztex.de/btcminer/ZtexBTCMiner-120622.tar.bz2
New features are:
Binaries: http://www.ztex.de/btcminer/ZtexBTCMiner-120622.jar
Source: http://www.ztex.de/btcminer/ZtexBTCMiner-120622.tar.bz2
New features are:
- Frequncy limit increased to 248 MHz (requires firmware update if dummy firmware is not used)
- Midstate check / auto-correction (BTCMiner considers all results as erroneous if midstate is wrong)
- Request new work interval randomized by +/- 12.5% (reduces network traffic peaks)
- Secondary Log (parameter -l2): Reports everything but statistics
- Secondary command input (parameter -c): Can be used the send commands through a named pipe
- LED2 of USB-FPGA Modules 1.15x flashes if a new share was found (requires firmware update if dummy firmware is not used)
- A few smaller changes requested by users
June 20, 2012, 03:06:18 PM
Quote
if you mean the power supply, this is a new 12V transformer from an external hard drive i bought recently.
thanks.
thanks.
Are you using a transformer instead of a regulated power supply? I would check to make sure the voltage is stable across different loads. I tested one from a Linksys router and it's voltage would spike to 17V under low resistance. Also, how many amps does it deliver? You would probably need at least 4 amps to power the quads stably.
Interesting, this may also be part of the problem then. It does not supply 4 amps.
I told stefan that this was fixed, but i spoke too soon, it crashed again.
I'll get a new power supply for the fpga.
and sorry for the email quote.
thank you all.
June 20, 2012, 11:14:09 AM
Quote
if you mean the power supply, this is a new 12V transformer from an external hard drive i bought recently.
thanks.
thanks.
Are you using a transformer instead of a regulated power supply? I would check to make sure the voltage is stable across different loads. I tested one from a Linksys router and it's voltage would spike to 17V under low resistance. Also, how many amps does it deliver? You would probably need at least 4 amps to power the quads stably.
June 20, 2012, 09:01:22 AM
The theoretical stale rate with "block monitoring" @212 MHz is (0.25s + 5.05s/) / 600s.
An measurement of the stale rate would have to be implemented into bitcoind because this require precise information about the time of occurrence of new block.
An measurement of the stale rate would have to be implemented into bitcoind because this require precise information about the time of occurrence of new block.
Thanks for the info. So in theory, the stale rate should be really low if you have a few miner running.
Yes.
June 20, 2012, 08:24:19 AM
I sent an e-mail to [...] for support but I guess I'll report my problem here also for the record.
First of all, please edit your posting in order to ensure that search engines can't read that email address. I already get a lot of spam and I don't need more. (The same for those who quoted that email address).
The answer to your question is the same I sent per email:
The USB connection goes lost. Most probable reasons are:
* Bad USB cable
* Bad USB hub
* Power supply interruption. This can be caused by cabling or if a
protection event of the PSU (e.g. overheat protection) is triggered.
If LED's go on it was a power supply interruption.
June 20, 2012, 07:02:09 AM
Stupid iPhone autocorrect....
I meant an other psu
I meant an other psu
June 20, 2012, 06:46:57 AM
I sent an e-mail to ztex support but I guess I'll report my problem here also for the record.
I have a new 1.15y board that i assembled and put to run.
I have a 12 volt power supply on CON3, for completeness of info.
It starts mining fine, but it only lasts for about 5 to 10 minutes and then crashes with the error on the following log:
http://pastebin.com/i2UKZ0M8
This happens on both Windows 7 and Ubuntu, so I am clueless as to why this happens.
Any help is appreciated. I have not been able to run this board on BFGminer and haven't tried other miners yet.
I have a new 1.15y board that i assembled and put to run.
I have a 12 volt power supply on CON3, for completeness of info.
It starts mining fine, but it only lasts for about 5 to 10 minutes and then crashes with the error on the following log:
http://pastebin.com/i2UKZ0M8
This happens on both Windows 7 and Ubuntu, so I am clueless as to why this happens.
Any help is appreciated. I have not been able to run this board on BFGminer and haven't tried other miners yet.
had that too .... eventually your hub or the cables are bad. second i would try a powered hub (that helped me) and an other opus for your quad
hmm i don't have a hub. it's only one board, so i connect directly to my desktop (windows 7) or laptop (Ubuntu). so maybe that USB cable is bad?
what do you mean by "another opus"? if you mean the power supply, this is a new 12V transformer from an external hard drive i bought recently.
thanks.
June 20, 2012, 04:25:35 AM
I sent an e-mail to .... for support but I guess I'll report my problem here also for the record.
I have a new 1.15y board that i assembled and put to run.
I have a 12 volt power supply on CON3, for completeness of info.
It starts mining fine, but it only lasts for about 5 to 10 minutes and then crashes with the error on the following log:
http://pastebin.com/i2UKZ0M8
This happens on both Windows 7 and Ubuntu, so I am clueless as to why this happens.
Any help is appreciated. I have not been able to run this board on BFGminer and haven't tried other miners yet.
I have a new 1.15y board that i assembled and put to run.
I have a 12 volt power supply on CON3, for completeness of info.
It starts mining fine, but it only lasts for about 5 to 10 minutes and then crashes with the error on the following log:
http://pastebin.com/i2UKZ0M8
This happens on both Windows 7 and Ubuntu, so I am clueless as to why this happens.
Any help is appreciated. I have not been able to run this board on BFGminer and haven't tried other miners yet.
had that too .... eventually your hub or the cables are bad. second i would try a powered hub (that helped me) and an other opus for your quad
June 19, 2012, 10:48:16 PM
How does the block monitoring work for BTCMiner?
If one of the miners detects a new block the others are forced to update their work.
Quote
I am solo mining and want to see if there is a way to tell what the stale percentage is, ie working on the old block when bitcoind has received a new block. I think we can probably derive this from the block log but that's probably more than I am capable.
The theoretical stale rate with "block monitoring" @212 MHz is (0.25s + 5.05s/
An measurement of the stale rate would have to be implemented into bitcoind because this require precise information about the time of occurrence of new block.
Thanks for the info. So in theory, the stale rate should be really low if you have a few miner running.
June 19, 2012, 05:48:37 PM
I sent an e-mail to ztex support but I guess I'll report my problem here also for the record.
I have a new 1.15y board that i assembled and put to run.
I have a 12 volt power supply on CON3, for completeness of info.
It starts mining fine, but it only lasts for about 5 to 10 minutes and then crashes with the error on the following log:
http://pastebin.com/i2UKZ0M8
This happens on both Windows 7 and Ubuntu, so I am clueless as to why this happens.
Any help is appreciated. I have not been able to run this board on BFGminer and haven't tried other miners yet.
I have a new 1.15y board that i assembled and put to run.
I have a 12 volt power supply on CON3, for completeness of info.
It starts mining fine, but it only lasts for about 5 to 10 minutes and then crashes with the error on the following log:
http://pastebin.com/i2UKZ0M8
This happens on both Windows 7 and Ubuntu, so I am clueless as to why this happens.
Any help is appreciated. I have not been able to run this board on BFGminer and haven't tried other miners yet.
June 19, 2012, 02:31:41 AM
How does the block monitoring work for BTCMiner?
If one of the miners detects a new block the others are forced to update their work.
Quote
I am solo mining and want to see if there is a way to tell what the stale percentage is, ie working on the old block when bitcoind has received a new block. I think we can probably derive this from the block log but that's probably more than I am capable.
The theoretical stale rate with "block monitoring" @212 MHz is (0.25s + 5.05s/
An measurement of the stale rate would have to be implemented into bitcoind because this require precise information about the time of occurrence of new block.
June 18, 2012, 05:00:27 PM
Ok, but why did the cluster stop!!!
In cluster modes the software only stops for the following reason:
* "q" command was entered
* All devices are disconnected (you will see a message)
* A appropriate signal was sent to the process
* A fatal error occurs / Java dies for some reason
Then you have a bug, the cluster stopped mining (lights where lit on all x1.15) because deepbit was unconnectable.
June 18, 2012, 03:02:37 PM
Hi Ztex,
How does the block monitoring work for BTCMiner? I am solo mining and want to see if there is a way to tell what the stale percentage is, ie working on the old block when bitcoind has received a new block. I think we can probably derive this from the block log but that's probably more than I am capable.
How does the block monitoring work for BTCMiner? I am solo mining and want to see if there is a way to tell what the stale percentage is, ie working on the old block when bitcoind has received a new block. I think we can probably derive this from the block log but that's probably more than I am capable.
June 18, 2012, 09:09:11 AM
Ok think I found out why the down throttling spiral occured. my local BTC server was only accepting connections from deepbit
The board clocks down the the software thinks that the results of the board are erroneous. This can also happen if the midstate is wrong. I think this was the reason (and this also explains some random downclocks issues in the past). I'will have to add an midstate check.
June 18, 2012, 09:05:38 AM
Ok, but why did the cluster stop!!!
In cluster modes the software only stops for the following reason:
* "q" command was entered
* All devices are disconnected (you will see a message)
* A appropriate signal was sent to the process
* A fatal error occurs / Java dies for some reason
June 16, 2012, 07:50:24 PM
Ah, ok... I piped debug.log to /dev/null because it filled my SSD... ;o
June 16, 2012, 06:03:13 PM
Yup, agree.
To answer my "How does one know that the mining is working?" is that "Total submitted hash rate: 979.7 MH/s"?
But how do I know my bitcoin client is working properly?
To answer my "How does one know that the mining is working?" is that "Total submitted hash rate: 979.7 MH/s"?
But how do I know my bitcoin client is working properly?
Yeah, there seems to be widespread DDoS going on. I am trying out solo on part of the cluster as well. To verify, besides the btcminer log, you can try "bitcoind getmininginfo" to make sure you're working on the right block. You can also try mining on testnet first, in which case you should be solving blocks like crazy
You can also check the bitcoin debug.log to make sure no major errors. Other than that, I don't know of any other way. Anybody else knows?
June 16, 2012, 04:16:25 PM
Yup, agree.
To answer my "How does one know that the mining is working?" is that "Total submitted hash rate: 979.7 MH/s"?
But how do I know my bitcoin client is working properly?
To answer my "How does one know that the mining is working?" is that "Total submitted hash rate: 979.7 MH/s"?
But how do I know my bitcoin client is working properly?
June 16, 2012, 04:04:39 PM
the attacks have their downsides.. we small users on the pools get hurt and have to monitor our (less dedicated) fpga-setup.
but i also see advantages..
- pools will get more robust
- field gets mixed a bit as one can see in the blockchain (solving pools) or e.g. bitcoinwatch.com
- improving the own setup to get backups in charge
- sensitizing pool-users to withdraw regularly (prevent losses on uncommon event - if pool stops working)
bit it doesnt seem to have a real impact on difficulty or global hash rate
but i also see advantages..
- pools will get more robust
- field gets mixed a bit as one can see in the blockchain (solving pools) or e.g. bitcoinwatch.com
- improving the own setup to get backups in charge
- sensitizing pool-users to withdraw regularly (prevent losses on uncommon event - if pool stops working)
bit it doesnt seem to have a real impact on difficulty or global hash rate
Jump to: