gusti
Legendary
Offline
Activity: 1099
Merit: 1000
|
|
December 02, 2011, 03:05:56 AM |
|
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.
|
|
|
Turbor
Legendary
Offline
Activity: 1022
Merit: 1000
BitMinter
|
|
December 10, 2011, 04:57:12 PM |
|
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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
December 10, 2011, 09:34:13 PM |
|
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. 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. 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
Activity: 1022
Merit: 1000
BitMinter
|
|
December 10, 2011, 10:36:51 PM |
|
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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
December 10, 2011, 11:55:16 PM |
|
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 )
|
|
|
|
Turbor
Legendary
Offline
Activity: 1022
Merit: 1000
BitMinter
|
|
December 11, 2011, 12:57:22 AM |
|
ok. Everything makes sense now (almost )
|
|
|
|
sadpandatech
|
|
December 11, 2011, 02:17:16 AM |
|
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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
December 14, 2011, 12:22:13 PM |
|
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
Activity: 1022
Merit: 1000
BitMinter
|
|
December 14, 2011, 10:27:57 PM |
|
|
|
|
|
nelisky
Legendary
Offline
Activity: 1540
Merit: 1002
|
|
January 24, 2012, 04:29:12 PM |
|
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 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: [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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
January 24, 2012, 07:59:02 PM |
|
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
Activity: 1540
Merit: 1002
|
|
January 24, 2012, 08:05:09 PM |
|
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
|
|
|
|
Turbor
Legendary
Offline
Activity: 1022
Merit: 1000
BitMinter
|
|
January 25, 2012, 09:54:06 PM |
|
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).
i hope this does not affect 1.15d boards... Why are they slower ? Different speedgrade or lower quality ?
|
|
|
|
ngzhang
|
|
January 26, 2012, 07:47:57 AM |
|
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).
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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
January 26, 2012, 09:10:53 AM |
|
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
Activity: 1540
Merit: 1002
|
|
January 26, 2012, 11:32:17 AM |
|
Hey, So I've been happily running BTCMiner with sudo for a while, but I don't want to anymore 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; ~$ 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: $ 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: (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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
January 26, 2012, 04:31:34 PM |
|
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
Activity: 1540
Merit: 1002
|
|
January 26, 2012, 04:39:35 PM |
|
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
Activity: 367
Merit: 250
ZTEX FPGA Boards
|
|
January 26, 2012, 05:06:35 PM |
|
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
Activity: 1540
Merit: 1002
|
|
January 26, 2012, 05:08:19 PM |
|
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: Linux charts 2.6.32-24-generic-pae #39-Ubuntu SMP Wed Jul 28 07:39:26 UTC 2010 i686 GNU/Linux
|
|
|
|
|