Bitcoin Forum
March 19, 2024, 10:55:53 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 34 35 36 37 38 39 40 [41] 42 43 44 45 46 47 48 49 50 »
  Print  
Author Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards  (Read 182325 times)
randomguy7
Hero Member
*****
Offline Offline

Activity: 527
Merit: 500


View Profile
July 10, 2012, 06:56:02 PM
 #801

Does someone know how much current the quads pull from the usb connection?

In my hands they need to be fully powered (500mA) to run stable.  I have hubs that can deliver 2.5A to 10 ports.  The singles will run fine if all 10 ports are used.  But the quads won't run stable if 10 quads are plugged into the hub providing only 2.5A.  5 quads into the hub: no problem.

What error do you get when you connect 10 quads to one usb hub? After some runtime 1-2 of my FPGAs always get shut down by the overheat protection (hash rate drop usually is about 5,x %), but it doesn't look like a cooling problem as it doesn't only occur with some specific FPGAs (it seems to affect all by random).

Is a -oh parameter of 0.06 still safe? Currently I use the default of 0.04.

Please try out the pre-release: http://www.ztex.de/btcminer/ZtexBTCMiner-120703.jar . It fixes two possible random downclock issues:  A multi-threading bug which occurs on 1.15y FPGA boards if there are more than 10 miners and automatic midstate correction.

Thx, just switched to the new version. I'm gonna report back after I got some results.

It seems the new btcminer version solved my problem, the boards are running since 22h now without a single FPGA shutting down. Thx ztex.
1710845753
Hero Member
*
Offline Offline

Posts: 1710845753

View Profile Personal Message (Offline)

Ignore
1710845753
Reply with quote  #2

1710845753
Report to moderator
1710845753
Hero Member
*
Offline Offline

Posts: 1710845753

View Profile Personal Message (Offline)

Ignore
1710845753
Reply with quote  #2

1710845753
Report to moderator
The block chain is the main innovation of Bitcoin. It is the first distributed timestamping system.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710845753
Hero Member
*
Offline Offline

Posts: 1710845753

View Profile Personal Message (Offline)

Ignore
1710845753
Reply with quote  #2

1710845753
Report to moderator
1710845753
Hero Member
*
Offline Offline

Posts: 1710845753

View Profile Personal Message (Offline)

Ignore
1710845753
Reply with quote  #2

1710845753
Report to moderator
1710845753
Hero Member
*
Offline Offline

Posts: 1710845753

View Profile Personal Message (Offline)

Ignore
1710845753
Reply with quote  #2

1710845753
Report to moderator
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
July 12, 2012, 10:18:32 AM
 #802

2 Feature requests/suggestions:
- Would be nice to be able to print out boards stats with a command. Now it automatically does it from time to time, but the wait is pretty long..

Has been implemented since the test version 120622. It's the "i(nfo)" command.

Quote
- Also, identifying boards in a cluster is quite impossible (without labeling them). Would it possible to add a command to blink an LED on a board by entering it's serial number?

For that purpose the labeling / serial number function was implemented. Use it, if you need it.

A disconnect command is planned for future. It would allow to identify the disconnected device by the "configure-me" LED's

punin
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500


View Profile WWW
July 12, 2012, 11:45:45 AM
 #803


A disconnect command is planned for future. It would allow to identify the disconnected device by the "configure-me" LED's


Ok, good. This makes it easier to spot a unit with a low hash rate due to heatsinking problems.

Head of Product Development
Bitfury Group
www.bitfury.com
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
July 13, 2012, 08:04:32 AM
 #804


A disconnect command is planned for future. It would allow to identify the disconnected device by the "configure-me" LED's


Ok, good. This makes it easier to spot a unit with a low hash rate due to heatsinking problems.

I strongly recommend the serial number function in clusters. What happens if there is a faulty USB cable in a 100 board cluster and the boards are not labeled? No BTCMiner command will help ...

rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
July 13, 2012, 10:12:59 AM
Last edit: July 13, 2012, 02:58:42 PM by rupy
 #805

If BTCMiner block monitor detects a new block, shouldn't the longpoll request be reset?

BANKBOOK GWT Wallet & no-FIAT Billing API
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
July 16, 2012, 07:10:54 AM
 #806

If BTCMiner block monitor detects a new block, shouldn't the longpoll request be reset?

If block monitor detects a new block new work is requested.

rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
July 16, 2012, 09:59:04 AM
 #807

Yes, of course, but that also means that the longpoll probably doesn't work (timed out or was cut off by some router) and should be reset too?

BANKBOOK GWT Wallet & no-FIAT Billing API
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
July 18, 2012, 10:58:13 AM
 #808

Yes, of course, but that also means that the longpoll probably doesn't work (timed out or was cut off by some router) and should be reset too?

LP and BM (block monitoring) are two independent mechanisms. The pool server (that responds to the LP) does not know when BTCMiner detected a new block by BM.

rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
July 18, 2012, 09:41:46 PM
 #809

Yes, again I know (having written my own pool) but if the longpoll doesen't trigger it's very likely that the longpoll connection is dead (TCP layer) and will never trigger, so to make sure the longpoll is used as much as possible, you should reconnect it!

BANKBOOK GWT Wallet & no-FIAT Billing API
vv01f
Sr. Member
****
Offline Offline

Activity: 314
Merit: 250


View Profile
July 19, 2012, 03:45:05 PM
Last edit: July 19, 2012, 04:04:32 PM by vv01f
 #810

What happens if there is a faulty USB cable in a 100 board cluster and the boards are not labeled? No BTCMiner command will help ...
It would be nice to use the setserial-function via some "blinkserial"-option so that the called serial(s) begin to blink leds (for e.g. 3min or a time in seconds set via the option) without disconnecting. Also this could help identifying all boards while running and enabling the admin to (re)label them if needed..

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

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
July 20, 2012, 09:00:22 AM
 #811

Yes, again I know (having written my own pool) but if the longpoll doesen't trigger it's very likely that the longpoll connection is dead (TCP layer) and will never trigger ...

Not never, only for 16min 40s. This is the read timeout.

ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
July 20, 2012, 09:06:43 AM
 #812

What happens if there is a faulty USB cable in a 100 board cluster and the boards are not labeled? No BTCMiner command will help ...
It would be nice to use the setserial-function via some "blinkserial"-option so that the called serial(s) begin to blink leds (for e.g. 3min or a time in seconds set via the option) without disconnecting.

It's difficult to send a command over USB if USB cable is broken. Therefore: label it.

Furthermore only 1.15x boards have a general purpose LED which could be used for this purpose.

rupy
Hero Member
*****
Offline Offline

Activity: 725
Merit: 500



View Profile
July 20, 2012, 04:20:03 PM
 #813

Yes, again I know (having written my own pool) but if the longpoll doesen't trigger it's very likely that the longpoll connection is dead (TCP layer) and will never trigger ...

Not never, only for 16min 40s. This is the read timeout.

Where did you get 16:40 from? just random or is it in some spec.?

BANKBOOK GWT Wallet & no-FIAT Billing API
mrb
Legendary
*
Offline Offline

Activity: 1512
Merit: 1027


View Profile WWW
July 20, 2012, 05:09:36 PM
 #814

Where did you get 16:40 from? just random or is it in some spec.?

It equals to a nice round number: 1000 sec.
Only programmers notice these things Smiley
punin
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500


View Profile WWW
August 16, 2012, 12:04:21 PM
 #815

I'm having issues running a cluster of 16 Ztex 1.15x boards with CGMiner or BFGMiner on Raspberry Pi. For some reason, 1random board dies within 1 hour and LED 2 goes on. Then it keeps mining nicely as long as I leave the dead board connected. If I disconnect the dead board, soon another board dies. Everything works on BTCMiner, so I doubt it's a USB cable. LED 2 points to the EZ USB, any ideas?

Head of Product Development
Bitfury Group
www.bitfury.com
ztex (OP)
Donator
Sr. Member
*
Offline Offline

Activity: 367
Merit: 250

ZTEX FPGA Boards


View Profile WWW
August 16, 2012, 01:02:17 PM
 #816

I'm having issues running a cluster of 16 Ztex 1.15x boards with CGMiner or BFGMiner on Raspberry Pi. For some reason, 1random board dies within 1 hour and LED 2 goes on.

It's still alive, it's just twiddling thumbs. If LED2 is on the board is in power save mode. This happens if the board receives no new work for 5min.

I'm not familiar with BFGMiner please report this bug in the BFGMiner thread (or use BTCMiner).


punin
Hero Member
*****
Offline Offline

Activity: 560
Merit: 500


View Profile WWW
August 16, 2012, 04:18:15 PM
 #817

I'm having issues running a cluster of 16 Ztex 1.15x boards with CGMiner or BFGMiner on Raspberry Pi. For some reason, 1random board dies within 1 hour and LED 2 goes on.

It's still alive, it's just twiddling thumbs. If LED2 is on the board is in power save mode. This happens if the board receives no new work for 5min.

I'm not familiar with BFGMiner please report this bug in the BFGMiner thread (or use BTCMiner).


Thank you for your analysis. I've already contacted developers of both programs, but was trying to get some more clues as to what is causing this. You see the miner software thinks the board is not responding and thus first declares it as "sick" after 60 or 90 sec of inactivity (don't remember precisely) and tries to restart it. That seems to fail every time. Then it's finally declared "dead" after 10 minutes of inactivity. Interestingly enough, this bug doesn't seem to affect rigs which also have GPUs in them.

Head of Product Development
Bitfury Group
www.bitfury.com
kunibopl
Full Member
***
Offline Offline

Activity: 184
Merit: 100


View Profile
August 24, 2012, 11:38:26 AM
Last edit: August 24, 2012, 12:10:34 PM by kunibopl
 #818

I can provide solid copperplates to cool the backside of the ZTEX platine.
these professionally milled plates are 5mm thick and should increase the MH/s at least a little bit and support the longevity of the board.
prices strongly depend on volume. assuming at least 20 plates for the y-version (4 FPGAs) are ordered,
the price would approximately be 29€.
for singles approximately 15€. you can pay in BTC of course.
postage is extra. every y-plate weights about 400g. I send from germany.
please post your interest or send pm.

NXT: 5231236538923913892
narousberg
Legendary
*
Offline Offline

Activity: 1749
Merit: 1007



View Profile
August 24, 2012, 12:47:19 PM
 #819

I can provide solid copperplates to cool the backside of the ZTEX platine.
these professionally milled plates are 5mm thick and should increase the MH/s at least a little bit and support the longevity of the board.
prices strongly depend on volume. assuming at least 20 plates for the y-version (4 FPGAs) are ordered,
the price would approximately be 29€.
for singles approximately 15€. you can pay in BTC of course.
postage is extra. every y-plate weights about 400g. I send from germany.
please post your interest or send pm.

please send pictures of this.

I AM NOT SELL MY BITCOINTALK ACCOUNT !!!
deeplink
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500


In cryptography we trust


View Profile
August 24, 2012, 12:58:07 PM
 #820

I can provide solid copperplates to cool the backside of the ZTEX platine.
these professionally milled plates are 5mm thick and should increase the MH/s at least a little bit and support the longevity of the board.
prices strongly depend on volume. assuming at least 20 plates for the y-version (4 FPGAs) are ordered,
the price would approximately be 29€.
for singles approximately 15€. you can pay in BTC of course.
postage is extra. every y-plate weights about 400g. I send from germany.
please post your interest or send pm.

Can you be more specific on how many MH/s increase to expect?
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 34 35 36 37 38 39 40 [41] 42 43 44 45 46 47 48 49 50 »
  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!