Bitcoin Forum
March 19, 2024, 05:35:24 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)
gusti
Legendary
*
Offline Offline

Activity: 1099
Merit: 1000


View Profile
December 02, 2011, 03:05:56 AM
 #181

Is it possible that Gustie tries to get this thread locked?

Why I would like that kind of censorship ? Discussion is enlightening.

If you don't own the private keys, you don't own the coins.
"You Asked For Change, We Gave You Coins" -- casascius
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710826524
Hero Member
*
Offline Offline

Posts: 1710826524

View Profile Personal Message (Offline)

Ignore
1710826524
Reply with quote  #2

1710826524
Report to moderator
1710826524
Hero Member
*
Offline Offline

Posts: 1710826524

View Profile Personal Message (Offline)

Ignore
1710826524
Reply with quote  #2

1710826524
Report to moderator
Turbor
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000


BitMinter


View Profile WWW
December 10, 2011, 04:57:12 PM
 #182

After running and observing the board for a while i have some questions. From time to time the connection times out or there are read (write) errors. The more backup pools i set up the more often that happens. The software disables then all backup pools for 30 or 60 seconds, even when they are up for sure. cgminer is running on the same machine and there is no indication that this is a network (bandwith) problem.

Is it possible to reset the hashrate counter after such a breakdown ? Or perhaps an auto restart function after a connection loss ? Hashrate seems fine 99% of the time. Sometimes it's stuck @160 or so MH/s... at less than 2% error rate @ 192 MHz. I have to restart the miner then and all works fine. Why is a FPGA hashrate less constant than a GPUs ? It goes from 160 to 220 sometimes.

ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
December 10, 2011, 09:34:13 PM
 #183

After running and observing the board for a while i have some questions. From time to time the connection times out or there are read (write) errors. The more backup pools i set up the more often that happens.

If no backup server is defined the pool server is disabled for 60s after 4 failed attempts. If a backup server is defined servers are disabled for 30s after 2 failed attempts. This is the reason why you see more warnings if you define backup pools.

Quote
The software disables then all backup pools for 30 or 60 seconds, even when they are up for sure. cgminer is running on the same machine and there is no indication that this is a network (bandwith) problem.

Probably cgminer tries it harder.

Unlike cgminer BTCMiner is optimized to run more than hundred FPGA boards per PC. Since connection errors block the whole thread a lot of counter overflows would occur in such a configuration if BTCMiner tries it as hard as cgminer.

I will modify the retry algorithm such that the retry effort is higher if only a small number of board is connected.

Quote
Is it possible to reset the hashrate counter after such a breakdown ? Or perhaps an auto restart function after a connection loss ? Hashrate seems fine 99% of the time. Sometimes it's stuck @160 or so MH/s... at less than 2% error rate @ 192 MHz. I have to restart the miner then and all works fine. Why is a FPGA hashrate less constant than a GPUs ? It goes from 160 to 220 sometimes.

Resetting counters (on todo list) is just cosmetics. The FPGA performance is constant and not influenced by connection errors. Only the rate of submitted hashes is influenced by network problems.

Turbor
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000


BitMinter


View Profile WWW
December 10, 2011, 10:36:51 PM
 #184

Thanks for your explanations. So the number of submitted shares in time x defines the hashrate displayed ? Sometimes 4 nonces are submitted at the same time and sometimes there are zero new nonces up to six times in a row. Seems to be the reason why the rate "looks" not constant.

ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
December 10, 2011, 11:55:16 PM
 #185

Thanks for your explanations. So the number of submitted shares in time x defines the hashrate displayed ? Sometimes 4 nonces are submitted at the same time and sometimes there are zero new nonces up to six times in a row. Seems to be the reason why the rate "looks" not constant.

x in "submitted x new nonces" denotes the amount of shares found within the message interval (15s in single board mode). At 190 MH/s the probability of 4 shares within 15s is 0.42% (happens about one time per hour) and the probability of 0 shares within 90s is 1.86% (about 4.5 times per hour).

"submitted hash rate" is computed by <total number of submitted shares>/<runtime>*2^32. This number converges to <frequency>*(1-<error rate>)*(1-<total disabled time>/<runtime>)*(1-<total overflow time>/<runtime>)*0.99994 (approximately Wink)




Turbor
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000


BitMinter


View Profile WWW
December 11, 2011, 12:57:22 AM
 #186

 Cheesy ok. Everything makes sense now (almost  Tongue)

sadpandatech
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500



View Profile
December 11, 2011, 02:17:16 AM
 #187

I think I'm going more crazy. :/ I could have sworn I posted here within the last 3 posts with a feature suggestion...............?

If you're not excited by the idea of being an early adopter 'now', then you should come back in three or four years and either tell us "Told you it'd never work!" or join what should, by then, be a much more stable and easier-to-use system.
- GA

It is being worked on by smart people.  -DamienBlack
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
December 14, 2011, 12:22:13 PM
 #188

A new version of BTCMiner with improved performance (typically 200 MH/s on LX150) has been released on http://www.ztex.de/btcminer/ (release number 111214).
See the initial post for details.

I also updated the prices for USB-FPGA Modules 1.15x, see https://bitcointalk.org/index.php?topic=49180.0

Turbor
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000


BitMinter


View Profile WWW
December 14, 2011, 10:27:57 PM
 #189




nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
January 24, 2012, 04:29:12 PM
 #190

A new version of BTCMiner with improved performance (typically 200 MH/s on LX150) has been released on http://www.ztex.de/btcminer/ (release number 111214).

I got my first ztex board today (yiipee!!!) and got it mining in no time, quite a different experience from the GPU realm Smiley

Now, I'm using release 111214 but as soon as it tries 200MHz the error rate goes from 0 to ~4.5%, making it fall back to 192MHz where I'm getting less than 180MHs average. Is there anything I can do to improve this or was I just unlucky with the board I received?

FYI, I tried both a separate 12v 2A power supply from an external hard drive and have it now connected to the computer PSU. I do get some complains from the usb subsystem but I'm assuming they are normal:

Code:
[64741.636023] usb 1-2: new high speed USB device using ehci_hcd and address 3
[64742.148040] hub 1-0:1.0: unable to enumerate USB device on port 2
[64742.492020] usb 3-2: new full speed USB device using ohci_hcd and address 2
[64742.651107] usb 3-2: not running at top speed; connect to a high speed hub
[64742.663179] usb 3-2: configuration #1 chosen from 1 choice
[64749.446973] usb 3-2: USB disconnect, address 2
[64764.648024] usb 1-2: new high speed USB device using ehci_hcd and address 4
[64764.740034] hub 1-0:1.0: unable to enumerate USB device on port 2
[64765.008021] usb 1-2: new high speed USB device using ehci_hcd and address 5
[64765.520045] hub 1-0:1.0: unable to enumerate USB device on port 2
[64765.864027] usb 3-2: new full speed USB device using ohci_hcd and address 3
[64766.023105] usb 3-2: not running at top speed; connect to a high speed hub
[64766.035181] usb 3-2: configuration #1 chosen from 1 choice
[67311.250255] usb 3-2: USB disconnect, address 3
[67350.024024] usb 1-1: new high speed USB device using ehci_hcd and address 6
[67350.696082] hub 1-0:1.0: unable to enumerate USB device on port 1
[67351.040024] usb 3-1: new full speed USB device using ohci_hcd and address 4
[67351.199100] usb 3-1: not running at top speed; connect to a high speed hub
[67351.211176] usb 3-1: configuration #1 chosen from 1 choice
[67356.567730] usb 3-1: USB disconnect, address 4
[67367.368022] usb 1-1: new high speed USB device using ehci_hcd and address 7
[67367.501362] usb 1-1: configuration #1 chosen from 1 choice
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
January 24, 2012, 07:59:02 PM
 #191

Now, I'm using release 111214 but as soon as it tries 200MHz the error rate goes from 0 to ~4.5%, making it fall back to 192MHz where I'm getting less than 180MHs average. Is there anything I can do to improve this or was I just unlucky with the board I received?

The 1.15x FPGA boards delivered in January 2012 are a few percent slower (192 MHz or 200 MHZ) than the ones delivered in 2011 (200MHz or 208Mhz).

Nevertheless, make sure that you mounted the heat sink using the push pins and thermal grease (do not use the adhesive pad).

The FPGA calculates one hash per clock, i.e. the (actual) hash rate always corresponds to the frequency minus error rate.

The value "submitted hash rate" from the BTCMiner output is empirical and based on the measurement of submitted shares. This value is influenced by statistics and things like network errors (check log for warnings). This value should (if no network errors occur) converge to the (actual) hash rate.




nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
January 24, 2012, 08:05:09 PM
 #192

The 1.15x FPGA boards delivered in January 2012 are a few percent slower (192 MHz or 200 MHZ) than the ones delivered in 2011 (200MHz or 208Mhz).

Nevertheless, make sure that you mounted the heat sink using the push pins and thermal grease (do not use the adhesive pad).

The FPGA calculates one hash per clock, i.e. the (actual) hash rate always corresponds to the frequency minus error rate.

The value "submitted hash rate" from the BTCMiner output is empirical and based on the measurement of submitted shares. This value is influenced by statistics and things like network errors (check log for warnings). This value should (if no network errors occur) converge to the (actual) hash rate.

Ok, that does explain it. I have mounted the heat sink with the thermal grease (I didn't even notice the pad, to be honest) and, while reading back this thread, decided to take it off, clean it up and apply some of the better thermal grease I use for GPUs. Same difference. It is very stable at 192Mhz, error rate is 0%, and nothing of relevance appears on the logs.

Looking at the pool hash rate calculation I see it spiking to 220MHs but more often than note stay below 180MHs. I guess that's just variance at its best, I very satisfied with the ease of use, stability and power dissipation of this little thing. Great job!

Now I just need to get more boards asap Wink
Turbor
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000


BitMinter


View Profile WWW
January 25, 2012, 09:54:06 PM
 #193

The 1.15x FPGA boards delivered in January 2012 are a few percent slower (192 MHz or 200 MHZ) than the ones delivered in 2011 (200MHz or 208Mhz).

 Shocked i hope this does not affect 1.15d boards... Why are they slower ? Different speedgrade or lower quality ?

ngzhang
Hero Member
*****
Offline Offline

Activity: 592
Merit: 501


We will stand and fight.


View Profile
January 26, 2012, 07:47:57 AM
 #194

The 1.15x FPGA boards delivered in January 2012 are a few percent slower (192 MHz or 200 MHZ) than the ones delivered in 2011 (200MHz or 208Mhz).

 Shocked i hope this does not affect 1.15d boards... Why are they slower ? Different speedgrade or lower quality ?

i also find a newer batch of spartan6 FPGAs has a lower quality. lead to a lower stabilized freq.
it can't be helped.
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
January 26, 2012, 09:10:53 AM
 #195

Shocked i hope this does not affect 1.15d boards... Why are they slower ? Different speedgrade or lower quality ?

1.15x FPGA boards shipped in 2011 and all 1.15d  FPGA boards have speed grade -3 FPGA's, newer 1.15x FPGA boards have speed grade -N3 FPGA's. According to the specs this is as fast as speed grade 3. The difference is that the memory controller is disabled.

AFAIK there are no special production lines for the different speed grades, i.e. the FPGA's get their speed grades after testing:

  • The fastest FPGA's get speed grade -3
  • If the MCB is out of specs (Xilinx had problems with that) but all other SG -3 specifications are met, the FPGA get speed grade -N3
  • The other ones which meet at least SG -2 specs get sped grade -2.
In other words, the production goal is SG -3. If this is not achieved it becomes SG -N3 or SG -2.

In practice this means:

  • SG -2 us usually closer to SG-3 than the data sheet says
  • SG -N3 should be somewhere between SG -2 and SG -3
  • The variance of SG -N3 is larger than that of SG -3
  • The variance of SG -2 is larger than that of SG -N3




nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
January 26, 2012, 11:32:17 AM
 #196

Hey,

So I've been happily running BTCMiner with sudo for a while, but I don't want to anymore Smiley The questions are relative to ubuntu 10.04.

My user has read on /dev/bus/usb/*/* which allows "BTCMiner -m t -i" to see, but not query the board;

Code:
~$ java -cp bin/ZtexBTCMiner-111214.jar BTCMiner -m t -i
0: bus=001  device=2 (`002')  ID=221a:100

I've changed the udev rule for USB to give the user's group write access and now I can query it just fine:

Code:
$ java -cp bin/ZtexBTCMiner-111214.jar BTCMiner -m t -i
0: bus=001  device=2 (`002')  ID=221a:100
   Manufacturer="ZTEX"  Product="btcminer for ZTEX FPGA Modules"    SerialNumber="0000000001"
   productID=10.0.1.1  fwVer=0  ifVer=1

But when I try to run the miner:

Code:
(Re)Scanning bus ...
ztex_ufm1_15d1-0000000001: New device: bitfile=ztex_ufm1_15d1   f_default=192.00MHz  f_max=224.00MHz
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes went lost;  checksum=203 , should be 203;  INIT_B_HIST=211): Retrying it ...
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes went lost;  checksum=203 , should be 203;  INIT_B_HIST=211): Retrying it ...
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes went lost;  checksum=203 , should be 203;  INIT_B_HIST=211): Retrying it ...
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes went lost;  checksum=203 , should be 203;  INIT_B_HIST=211): Retrying it ...
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes went lost;  checksum=203 , should be 203;  INIT_B_HIST=211): Retrying it ...
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes went lost;  checksum=203 , should be 203;  INIT_B_HIST=211): Retrying it ...
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes went lost;  checksum=203 , should be 203;  INIT_B_HIST=211): Retrying it ...
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes went lost;  checksum=203 , should be 203;  INIT_B_HIST=211): Retrying it ...
Warning: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes went lost;  checksum=203 , should be 203;  INIT_B_HIST=211): Retrying it ...
Error: Error uploading bitstream: FPGA configuration failed: DONE pin does not go high (size=4220313 ,  0 bytes went lost;  checksum=203 , should be 203;  INIT_B_HIST=211)

Summary:
  Total         : 0 devices


Disconnect all devices or press Ctrl-C for exit.
Press "r" Enter for re-scanning.


Sudo'ing BTCMiner uploads the bitstream and runs the miner just fine... what am I missing?

Thanks!
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
January 26, 2012, 04:31:34 PM
 #197

Sudo'ing BTCMiner uploads the bitstream and runs the miner just fine... what am I missing?

Looks like a very strange permission problem. It seems that EP0 data packages are disordered if you do not run it as root. Are you using vmware?

Please try out the pre-release (still requires some testing) from http://www.ztex.de/btcminer/ZtexBTCMiner-120126.jar . This new version uses a bulk EP for configuration (about 60% faster).

nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
January 26, 2012, 04:39:35 PM
 #198

Sudo'ing BTCMiner uploads the bitstream and runs the miner just fine... what am I missing?

Looks like a very strange permission problem. It seems that EP0 data packages are disordered if you do not run it as root. Are you using vmware?

Please try out the pre-release (still requires some testing) from http://www.ztex.de/btcminer/ZtexBTCMiner-120126.jar . This new version uses a bulk EP for configuration (about 60% faster).


It is certainly much, much faster to configure. It seems to work fine without sudo now, I'll post if it happens again.

Also, no, not vmware. Plain bare metal ubuntu server.
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
January 26, 2012, 05:06:35 PM
 #199

It is certainly much, much faster to configure. It seems to work fine without sudo now, I'll post if it happens again.

Also, no, not vmware. Plain bare metal ubuntu server.

Which kernel do you use (version, standard or modified kernel)? It seems to be a kernel bug, namely a EP0 handshaking problem.

nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001


View Profile
January 26, 2012, 05:08:19 PM
 #200

Which kernel do you use (version, original kernel)? It seems to be a kernel bug. (EP0 handshaking seems not to work properly.)

It's all plain vanilla from ubuntu-server-10.04:

Code:
Linux charts 2.6.32-24-generic-pae #39-Ubuntu SMP Wed Jul 28 07:39:26 UTC 2010 i686 GNU/Linux
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!