rupy
|
|
June 16, 2012, 07:34:49 PM |
|
Hm, my cluster just stopped working when deepbit was unconnectable for a while: Lots of: Followed by: Warning: 4 overflows occured. This is usually caused by a slow network connection. Ok, but why did the cluster stop!!! If I hadn't been by the computer I might have lost hashing time. Edit: ZtexBTCMiner-120221.jar
|
BANKBOOK GWT Wallet & no-FIAT Billing API
|
|
|
rupy
|
|
June 16, 2012, 08:07:39 PM |
|
Hm, since deepbit is down I tried starting the miner against localhost. Then the FPGA's keep dropping the frequency like crazy until they stop because of overheat but they are dead cold... ?! Now I'm back on deepbit and everything is fine. Seems it must be polling that craps out?!
|
BANKBOOK GWT Wallet & no-FIAT Billing API
|
|
|
vv01f
|
|
June 16, 2012, 08:19:38 PM Last edit: June 16, 2012, 08:58:00 PM by vv01f |
|
Did you try another pool? Also try to use another software (cgminer with the fpga or others with yout cpu/gpu) to verify that the problem is not you or the pools connection.
I had to change them several times yesterday (seems ongoing DDOSon some pools). BitParking had problems and BTCGuild too.
The problem of BTCMiner stopping when connection-problems arise has to be fixed, also occurred during my testing of pools and somelike every 2 days in the morning on BitParking - couldnt identify the problem but think its the software (e.g. string handling with unhandled exceptions).
Right now mining at osco.in with no problem since yesterday evening.. looking forward to the next morning and monday morning...
/*break*/ besides: one of my quad-baords now is mailed to ztex due to one downclocking core, looking forward to be told I am too stupid using mx4 :\ or cleaning with isopropanol .
|
|
|
|
rupy
|
|
June 16, 2012, 08:41:04 PM Last edit: June 16, 2012, 08:56:24 PM by rupy |
|
Ok think I found out why the down throttling spiral occured. my local BTC server was only accepting connections from deepbit IP... hm wierd... since second time I started BTCMiner it complained about URL... Now mining happily locally... or how does one know they are mining properly... since I only have 1 GH it would take weeks to know right?... :/ these attacks are really smart! improves the chance of getting blocks for the attackers!!!
|
BANKBOOK GWT Wallet & no-FIAT Billing API
|
|
|
vv01f
|
|
June 16, 2012, 09: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
|
|
|
|
rupy
|
|
June 16, 2012, 09: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?
|
BANKBOOK GWT Wallet & no-FIAT Billing API
|
|
|
CA Coins
Donator
Sr. Member
Offline
Activity: 305
Merit: 250
|
|
June 16, 2012, 11: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?
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?
|
|
|
|
rupy
|
|
June 17, 2012, 12:50:24 AM |
|
Ah, ok... I piped debug.log to /dev/null because it filled my SSD... ;o
|
BANKBOOK GWT Wallet & no-FIAT Billing API
|
|
|
ztex (OP)
Donator
Sr. Member
Offline
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
June 18, 2012, 02:05:38 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
|
|
|
|
ztex (OP)
Donator
Sr. Member
Offline
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
June 18, 2012, 02:09:11 PM |
|
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.
|
|
|
|
CA Coins
Donator
Sr. Member
Offline
Activity: 305
Merit: 250
|
|
June 18, 2012, 08: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.
|
|
|
|
rupy
|
|
June 18, 2012, 10: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.
|
BANKBOOK GWT Wallet & no-FIAT Billing API
|
|
|
ztex (OP)
Donator
Sr. Member
Offline
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
June 19, 2012, 07: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. 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/<number of miners-1>) / 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.
|
|
|
|
riclas
|
|
June 19, 2012, 10:48:37 PM Last edit: June 20, 2012, 08:02:10 PM by riclas |
|
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/i2UKZ0M8This 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.
|
portuguese p2p trader. telegram @riclas
|
|
|
CA Coins
Donator
Sr. Member
Offline
Activity: 305
Merit: 250
|
|
June 20, 2012, 03:48:16 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. 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/<number of miners-1>) / 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. Thanks for the info. So in theory, the stale rate should be really low if you have a few miner running.
|
|
|
|
BR0KK
|
|
June 20, 2012, 09:25:35 AM Last edit: June 22, 2012, 08:31:26 AM by BR0KK |
|
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/i2UKZ0M8This 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
|
|
|
|
riclas
|
|
June 20, 2012, 11:46:57 AM Last edit: June 20, 2012, 08:02:32 PM by riclas |
|
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/i2UKZ0M8This 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.
|
portuguese p2p trader. telegram @riclas
|
|
|
BR0KK
|
|
June 20, 2012, 12:02:09 PM |
|
Stupid iPhone autocorrect....
I meant an other psu
|
|
|
|
ztex (OP)
Donator
Sr. Member
Offline
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
June 20, 2012, 01:24:19 PM |
|
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.
|
|
|
|
ztex (OP)
Donator
Sr. Member
Offline
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
June 20, 2012, 02:01:22 PM |
|
The theoretical stale rate with "block monitoring" @212 MHz is (0.25s + 5.05s/<number of miners-1>) / 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.
Thanks for the info. So in theory, the stale rate should be really low if you have a few miner running. Yes.
|
|
|
|
|