From what we know his OS should not detect the device any differently on either port on the pc side right?
Yes. In order to connect the FPGA board to an USB 3.0 host (A type connector) an USB 2.0 cable has to be used.
Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150 - page 23. (Read 161727 times)
January 26, 2012, 04:24:47 PM
Yes. In order to connect the FPGA board to an USB 3.0 host (A type connector) an USB 2.0 cable has to be used.
January 26, 2012, 03:53:29 PM
The only catch is that usb type b 'plugs', i.e.,usb 3 mini b and usb 3 micro b will not fit into usb 2 micro and mini b receptacles.
That is what I meant. USB 3.0 cables does not fit into the mini USB 2.0 type B connectors of the FPGA boards.
aye, i get what you are saying. my wording was a bit off too.
From what we know his OS should not detect the device any differently on either port on the pc side right?
January 26, 2012, 03:44:22 PM
The only catch is that usb type b 'plugs', i.e.,usb 3 mini b and usb 3 micro b will not fit into usb 2 micro and mini b receptacles.
That is what I meant. USB 3.0 cables does not fit into the mini USB 2.0 type B connectors of the FPGA boards.
January 26, 2012, 03:34:23 PM
Is it possible that my new boards don't like their USB3 ports ? 
I don't understand this question.
You can't plug USB 3.0 cables into USB 2.0 ports, if you meant that.
Why not? Is not USB 3 still using the standard Type A connectors? The techs are listed as cross compatible. The only catch is that usb type b 'plugs', i.e.,usb 3 mini b and usb 3 micro b will not fit into usb 2 micro and mini b receptacles.
His question though seems to be about his USB 3 ports 'edit' on the pc side not picking up the device.
A partial answer;
The port should not matter as USB 3 is backwards compatible with USB 2 devices. But, if you have a USB 2 port, try plugging it into there and see if the computer reconizes it then. What OS are you running?
January 26, 2012, 02:46:38 PM
Is it possible that my new boards don't like their USB3 ports ?
I don't understand this question.
You can't plug USB 3.0 cables into USB 2.0 ports, if you meant that.
January 26, 2012, 02:22:30 PM
Is it possible that my new boards don't like their USB3 ports ?
January 26, 2012, 12: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:
Code:
Linux charts 2.6.32-24-generic-pae #39-Ubuntu SMP Wed Jul 28 07:39:26 UTC 2010 i686 GNU/Linux
January 26, 2012, 12: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.
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.
January 26, 2012, 11:39:35 AM
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.
January 26, 2012, 11:31:34 AM
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).
January 26, 2012, 06: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;
I've changed the udev rule for USB to give the user's group write access and now I can query it just fine:
But when I try to run the miner:
Sudo'ing BTCMiner uploads the bitstream and runs the miner just fine... what am I missing?
Thanks!
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;
Code:
~$ java -cp bin/ZtexBTCMiner-111214.jar BTCMiner -m t -i
0: bus=001 device=2 (`002') ID=221a:100
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
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.
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!
January 26, 2012, 04: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 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
January 26, 2012, 02: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.
January 25, 2012, 04: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 ? January 24, 2012, 03: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.
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
January 24, 2012, 02: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.
January 24, 2012, 11:29:12 AM
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:
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
[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
December 14, 2011, 05:27:57 PM
December 14, 2011, 07:22:13 AM
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://bitcointalksearch.org/topic/ztex-usb-fpga-modules-115x-and-115y-215-and-860-mhs-fpga-boards-49180
See the initial post for details.
I also updated the prices for USB-FPGA Modules 1.15x, see https://bitcointalksearch.org/topic/ztex-usb-fpga-modules-115x-and-115y-215-and-860-mhs-fpga-boards-49180
December 10, 2011, 09:17:16 PM
I think I'm going more crazy. :/ I could have sworn I posted here within the last 3 posts with a feature suggestion...............?
Jump to: