Bitcoin Forum
March 19, 2024, 07:06:45 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 [22] 23 24 25 26 27 28 29 30 31 32 33 »
  Print  
Author Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150  (Read 161481 times)
rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
June 16, 2012, 07:34:49 PM
 #421

Hm, my cluster just stopped working when deepbit was unconnectable for a while:

Lots of:

Error: connect timed out: Disabling URL http://pit.deepbit.net:8332 for 30s

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
1710832005
Hero Member
*
Offline Offline

Posts: 1710832005

View Profile Personal Message (Offline)

Ignore
1710832005
Reply with quote  #2

1710832005
Report to moderator
"In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
June 16, 2012, 08:07:39 PM
 #422

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
Sr. Member
****
Offline Offline

Activity: 314
Merit: 250


View Profile
June 16, 2012, 08:19:38 PM
Last edit: June 16, 2012, 08:58:00 PM by vv01f
 #423

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 .

donations to me please send via bitcoin 1vvo1FDwSAwNdLVA1mFkM7v76XPZAAUfb
a good European exchange: bitcoin.de (ref-link)
rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
June 16, 2012, 08:41:04 PM
Last edit: June 16, 2012, 08:56:24 PM by rupy
 #424

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
Sr. Member
****
Offline Offline

Activity: 314
Merit: 250


View Profile
June 16, 2012, 09:04:39 PM
 #425

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 Smiley

donations to me please send via bitcoin 1vvo1FDwSAwNdLVA1mFkM7v76XPZAAUfb
a good European exchange: bitcoin.de (ref-link)
rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
June 16, 2012, 09:16:25 PM
 #426

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 Offline

Activity: 305
Merit: 250


View Profile
June 16, 2012, 11:03:13 PM
 #427

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 Smiley
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
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
June 17, 2012, 12:50:24 AM
 #428

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 Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
June 18, 2012, 02:05:38 PM
 #429

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 Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
June 18, 2012, 02:09:11 PM
 #430

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 Offline

Activity: 305
Merit: 250


View Profile
June 18, 2012, 08:02:37 PM
 #431

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
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
June 18, 2012, 10:00:27 PM
 #432

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 Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
June 19, 2012, 07:31:41 AM
 #433

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/<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
Full Member
***
Offline Offline

Activity: 208
Merit: 106


View Profile
June 19, 2012, 10:48:37 PM
Last edit: June 20, 2012, 08:02:10 PM by riclas
 #434

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.

portuguese p2p trader. telegram @riclas
CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 305
Merit: 250


View Profile
June 20, 2012, 03:48:16 AM
 #435

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/<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
Hero Member
*****
Offline Offline

Activity: 784
Merit: 500



View Profile
June 20, 2012, 09:25:35 AM
Last edit: June 22, 2012, 08:31:26 AM by BR0KK
 #436

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.

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
Full Member
***
Offline Offline

Activity: 208
Merit: 106


View Profile
June 20, 2012, 11:46:57 AM
Last edit: June 20, 2012, 08:02:32 PM by riclas
 #437

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.

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
Hero Member
*****
Offline Offline

Activity: 784
Merit: 500



View Profile
June 20, 2012, 12:02:09 PM
 #438

Stupid iPhone autocorrect....

I meant an other psu

ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
June 20, 2012, 01:24:19 PM
 #439

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 Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
June 20, 2012, 02:01:22 PM
 #440

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.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 [22] 23 24 25 26 27 28 29 30 31 32 33 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!