Bitcoin Forum
December 08, 2016, 08:22:20 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
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 51 »
  Print  
Author Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards  (Read 174173 times)
catfish
Sr. Member
****
Offline Offline

Activity: 270


teh giant catfesh


View Profile
May 12, 2012, 08:32:18 AM
 #701

Grin I was able to bring chip number 3 back to life ! For all those who wondered, the board will work fine if one chip fails. Since the chip was working on arrival I refused Ztex's offer to send the board back for warranty. I was sad but it turned out that the mistake was on my side. It looks like I used a bit too much thermal grease at the wrong place. Somehow, the grease must have found a way to some components on the board or even the pins of the FPGA.

I removed the heatsink, cleaned the FPGA with ethanol and gave it a good spray of WD40. BAAAM, I'm back in business Cool

Yes, electrically conductive thermal grease should be avoided. It's something I have to add the the red warning slips.
I agree with you on a technical basis, and it's definitely a good idea to put a red warning slip in for Gusti types, but I'm using Nano Silver thermal compound under extreme thermal conditions and it works well.

The risk is over-application of thermal compound, especially if it is low viscosity - resulting in the compound being squeezed off the surface of the FPGA package and onto nearby surface-mount components, shorting them out (you know this Stefan, I'm writing this for everyone else).

Over-application of electrically conductive thermal compound may trash your boards, and Stefan has clearly stated 'no electrically conductive thermal compound', so NOES WARRANTY if you short out your board.

HOWEVER.... if you apply the compound *correctly* such that it is merely adequate to fill the micrometres between the surface of the FPGA package and the bottom of the heatsink, and ensure that the thickness of the layer of compound is lowest adjacent to the USB controller chip (which has exposed pins - hence the danger), then the risk of damaging the boards with electrically conductive thermal compound is LOW.

Not many thermal compounds are *highly* electrically conductive - even Arctic Silver, which obviously contains silver (an element with exceptional electrical conductivity), is formulated to be electrically non-conductive. Not sure how they manage that, and I'm assuming that my 'Nano Silver' thermal compound *is* slightly electrically conductive, but I'd rather have maximum heat transfer whilst relying on my judgement to apply the compound precisely.

I've double checked this procedure with an old university mate who is now Head Engineer at a rather well known telecoms company, and spent a decade as a VHDL consultant. He knows his FPGAs.


Not meaning to argue with you Stefan - not in the slightest - after all, better safe than sorry. But if you have 'difficult' thermal conditions and need to maximise the heat transfer from the FPGA package to the heatsink, the silver-based compounds work best. I'd rather use a very thin film of silver compound than a big blob of white goop. Ideally, the compound shouldn't extrude past the perimeter of the FPGA package.

And the fact that Turbor's FPGA wasn't permanently destroyed by the short is testament to the quality and toughness of Stefan's boards. Ztex may be on the high end of the price spectrum, but you get what you pay for. I haven't had any problems with my 26 boards yet but the anecdotal evidence from threads here all points to the Ztex boards being very high quality products, and able to withstand more abuse than most.


Time to wire my boards up *properly* according to Stefan's cluster recommendation... currently (heh) my daisy-chain wires are hot to the touch, and that's never good. Pics once finished...

...so I give in to the rhythm, the click click clack
I'm too wasted to fight back...


BTC: 1A7HvdGGDie3P5nDpiskG8JxXT33Yu6Gct
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481228540
Hero Member
*
Offline Offline

Posts: 1481228540

View Profile Personal Message (Offline)

Ignore
1481228540
Reply with quote  #2

1481228540
Report to moderator
1481228540
Hero Member
*
Offline Offline

Posts: 1481228540

View Profile Personal Message (Offline)

Ignore
1481228540
Reply with quote  #2

1481228540
Report to moderator
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
May 19, 2012, 10:20:39 PM
 #702

I have one Problem with my setup. Everything runs fine for some hours but the 2 or 3 FPGAs (of 10) get kicked out of BTCminer for "overheating" or "some other reason i can't identify".

The boards are cooled by stock Xilence  or Titan heat sink.

If i restart BTCminer everything works perfect again

Its random and affects all units in the same way.

Does anyone have similar issues?



Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
May 19, 2012, 11:41:02 PM
 #703

I have one Problem with my setup. Everything runs fine for some hours but the 2 or 3 FPGAs (of 10) get kicked out of BTCminer for "overheating" or "some other reason i can't identify".

The boards are cooled by stock Xilence  or Titan heat sink.

If i restart BTCminer everything works perfect again

Its random and affects all units in the same way.

Does anyone have similar issues?

Quad or single boards ? Does this happen after connection issues ? I do have one sick chip that is down 90% of the time. But this seems to be more like a defective FPGA or a board problem than an actual overheating issue. I decided to use the quad as trio. Somehow I got used to the sexy yellow light Cheesy

Edit: You can try to set -oh to 0.5 or so to see how low the boards frequency will fall down. This way you are able to still use the chip in case something is wrong + it won't hurt because the auto downclock still works. That's why I like this boards so much.

Code:
bus-0-0: ztex_ufm1_15d4-0001-02-05-1: f=208.00MHz,  errorRate=0.66%,  maxErrorRa
te=2.21%,  hashRate=206.6MH/s,  submitted 20 new nonces,  luckFactor=1.16
bus-0-0: ztex_ufm1_15d4-0001-02-06-1: f=208.00MHz,  errorRate=0.37%,  maxErrorRa
te=0.95%,  hashRate=207.2MH/s,  submitted 18 new nonces,  luckFactor=1.05
bus-0-0: ztex_ufm1_15y1-0001-02-07-1: f=212.00MHz,  errorRate=0.39%,  maxErrorRa
te=1.26%,  hashRate=211.2MH/s,  submitted 16 new nonces,  luckFactor=1.12
bus-0-0: ztex_ufm1_15y1-0001-02-07-2: f=208.00MHz,  errorRate=0.19%,  maxErrorRa
te=1.72%,  hashRate=207.6MH/s,  submitted 20 new nonces,  luckFactor=1.18
bus-0-0: ztex_ufm1_15y1-0001-02-07-3: f=120.00MHz,  errorRate=0.00%,  maxErrorRa
te=2.99%,  hashRate=120.0MH/s,  submitted 6 new nonces,  luckFactor=0.87
bus-0-0: ztex_ufm1_15y1-0001-02-07-4: f=200.00MHz,  errorRate=0.37%,  maxErrorRa
te=0.51%,  hashRate=199.3MH/s,  submitted 9 new nonces,  luckFactor=0.94
bus-0-0: poll loop time: 88ms (USB: 5ms network: 84ms)   getwork time: 366ms  su
bmit time: 373ms
Total hash rate: 1151.9 MH/s
Total submitted hash rate: 1226.0 MH/s




CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 306


View Profile
May 20, 2012, 01:57:51 PM
 #704

I have one Problem with my setup. Everything runs fine for some hours but the 2 or 3 FPGAs (of 10) get kicked out of BTCminer for "overheating" or "some other reason i can't identify".

The boards are cooled by stock Xilence  or Titan heat sink.

If i restart BTCminer everything works perfect again

Its random and affects all units in the same way.

Does anyone have similar issues?


Something like this with the quads?
Code:
2012-05-03T15:59:57: 002-2: ztex_ufm1_15y1-2012-L4-A3-1: Error: Hash rate drop of 7.3% detect. This may be caused by overheating. FPGA is shut down to prevent damage.  55.0: Device disabled since 2012-05-01T19:22:53
2012-05-03T15:59:57: 002-2: ztex_ufm1_15y1-2012-L4-A3-2: Error: Hash rate drop of 7.8% detect. This may be caused by overheating. FPGA is shut down to prevent damage.  50.98564515706362: Device disabled since 2012-05-02T07:51:01
2012-05-03T15:59:57: 002-2: ztex_ufm1_15y1-2012-L4-A3-3: f=212.00MHz,  errorRate=0.00%,  maxErrorRate=4.10%,  hashRate=212.0MH/s,  submitted 19 new nonces,  luckFactor=1.00
2012-05-03T15:59:57: 002-2: ztex_ufm1_15y1-2012-L4-A3-4: f=200.00MHz,  errorRate=0.00%,  maxErrorRate=3.45%,  hashRate=200.0MH/s,  submitted 21 new nonces,  luckFactor=0.99
2012-05-03T15:59:57: 002-2: ztex_ufm1_15y1-2012-L4-B3-1: Error: Hash rate drop of 7.7% detect. This may be caused by overheating. FPGA is shut down to prevent damage.  52.0: Device disabled since 2012-05-03T05:35:39
CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 306


View Profile
May 20, 2012, 02:02:37 PM
 #705


Quad or single boards ? Does this happen after connection issues ? I do have one sick chip that is down 90% of the time. But this seems to be more like a defective FPGA or a board problem than an actual overheating issue. I decided to use the quad as trio. Somehow I got used to the sexy yellow light Cheesy

Edit: You can try to set -oh to 0.5 or so to see how low the boards frequency will fall down. This way you are able to still use the chip in case something is wrong + it won't hurt because the auto downclock still works. That's why I like this boards so much.

Code:
bus-0-0: ztex_ufm1_15d4-0001-02-05-1: f=208.00MHz,  errorRate=0.66%,  maxErrorRa
te=2.21%,  hashRate=206.6MH/s,  submitted 20 new nonces,  luckFactor=1.16
bus-0-0: ztex_ufm1_15d4-0001-02-06-1: f=208.00MHz,  errorRate=0.37%,  maxErrorRa
te=0.95%,  hashRate=207.2MH/s,  submitted 18 new nonces,  luckFactor=1.05
bus-0-0: ztex_ufm1_15y1-0001-02-07-1: f=212.00MHz,  errorRate=0.39%,  maxErrorRa
te=1.26%,  hashRate=211.2MH/s,  submitted 16 new nonces,  luckFactor=1.12
bus-0-0: ztex_ufm1_15y1-0001-02-07-2: f=208.00MHz,  errorRate=0.19%,  maxErrorRa
te=1.72%,  hashRate=207.6MH/s,  submitted 20 new nonces,  luckFactor=1.18
bus-0-0: ztex_ufm1_15y1-0001-02-07-3: f=120.00MHz,  errorRate=0.00%,  maxErrorRa
te=2.99%,  hashRate=120.0MH/s,  submitted 6 new nonces,  luckFactor=0.87
bus-0-0: ztex_ufm1_15y1-0001-02-07-4: f=200.00MHz,  errorRate=0.37%,  maxErrorRa
te=0.51%,  hashRate=199.3MH/s,  submitted 9 new nonces,  luckFactor=0.94
bus-0-0: poll loop time: 88ms (USB: 5ms network: 84ms)   getwork time: 366ms  su
bmit time: 373ms
Total hash rate: 1151.9 MH/s
Total submitted hash rate: 1226.0 MH/s



Whoa, 120MH/s?  Are you thinking about sending it to Stefan for repair?
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
May 20, 2012, 03:38:37 PM
 #706

Hm now it ran for a night without any problem....
Kind of random ...

i think its my hub ..... Or my mac .... Smiley

One of my singles only gets about 199 MH/s. And its getting errors with that speed. But its not the one that gets kicked out of BTCMiner.


Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
May 20, 2012, 04:10:10 PM
 #707

Whoa, 120MH/s?  Are you thinking about sending it to Stefan for repair?

I got the offer but as long as the other chips work fine I keep it this way. It's not worth the hassle.

ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
May 21, 2012, 07:10:05 AM
 #708

Hm now it ran for a night without any problem....
Kind of random ...

i think its my hub ..... Or my mac .... Smiley

USB errors look different. That are probably power supply instabilities. (PSU cant handle the load/gets to hot, power cables are to thin / to long, ...)

BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
May 21, 2012, 08:48:54 AM
 #709

i use the standard puss from your shop. The quad has its own psu, 5 singles are on the splitter (with an standard psu)and one single has its own psu.

I'll have to change that in the near future.

gr0bi42
Full Member
***
Offline Offline

Activity: 158


View Profile WWW
May 21, 2012, 10:45:51 AM
 #710

I have one Problem with my setup. Everything runs fine for some hours but the 2 or 3 FPGAs (of 10) get kicked out of BTCminer for "overheating" or "some other reason i can't identify".

The boards are cooled by stock Xilence  or Titan heat sink.

If i restart BTCminer everything works perfect again

Its random and affects all units in the same way.

Does anyone have similar issues?


Something like this with the quads?
Code:
2012-05-03T15:59:57: 002-2: ztex_ufm1_15y1-2012-L4-A3-1: Error: Hash rate drop of 7.3% detect. This may be caused by overheating. FPGA is shut down to prevent damage.  55.0: Device disabled since 2012-05-01T19:22:53
2012-05-03T15:59:57: 002-2: ztex_ufm1_15y1-2012-L4-A3-2: Error: Hash rate drop of 7.8% detect. This may be caused by overheating. FPGA is shut down to prevent damage.  50.98564515706362: Device disabled since 2012-05-02T07:51:01
2012-05-03T15:59:57: 002-2: ztex_ufm1_15y1-2012-L4-A3-3: f=212.00MHz,  errorRate=0.00%,  maxErrorRate=4.10%,  hashRate=212.0MH/s,  submitted 19 new nonces,  luckFactor=1.00
2012-05-03T15:59:57: 002-2: ztex_ufm1_15y1-2012-L4-A3-4: f=200.00MHz,  errorRate=0.00%,  maxErrorRate=3.45%,  hashRate=200.0MH/s,  submitted 21 new nonces,  luckFactor=0.99
2012-05-03T15:59:57: 002-2: ztex_ufm1_15y1-2012-L4-B3-1: Error: Hash rate drop of 7.7% detect. This may be caused by overheating. FPGA is shut down to prevent damage.  52.0: Device disabled since 2012-05-03T05:35:39

I also experience these "hashrate drop errors", but only with BTCMiner. With cgminer 2.4.1 I've never got such an error. The hashrate drop code is present in cgminer. So what does it mean? The hashrate drop errors are present, but cgminer fails to detect them. Or, something is wrong within BTCMiner. One observation I've made... I get the hashrate drop errors in BTCMiner always around "new block" announcments.

Donations are welcome: 1Btf3BqUegfe5iFdWsgfBf1Ew3YsAvsrLT
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
May 21, 2012, 12:18:40 PM
 #711

Its not only hash rate drops also libusb errors occur. i try to find some logs for this.

CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 306


View Profile
May 21, 2012, 08:35:50 PM
 #712

Its not only hash rate drops also libusb errors occur. i try to find some logs for this.
I assume you're only seeing the errors on the quads (I had only seen them on the quads). Are you driving them (1 or 2) on 1 psu? How are you wiring your +12V and GND wires? I had these errors initially where over half of my quads eventually were disabled over the course of a week. I rewired the power cables and haven't seen them for 2 weeks now.
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
May 21, 2012, 09:26:07 PM
 #713

Quote
I assume you're only seeing the errors on the quads (I had only seen them on the quads). Are you driving them (1 or 2) on 1 psu? How are you wiring your +12V and GND wires? I had these errors initially where over half of my quads eventually were disabled over the course of a week. I rewired the power cables and haven't seen them for 2 weeks now.

One quad with its own PSU. Five singles on the splitter thingie and one Single on its separate wall plug.

No its not only the quad. Today for example i came home, three of the five on the splitter and the one on the separate wall plug singles had an LED on (indication that they weren't programmed or stopped working). This kinda happened when emc pool did go offline today (i assume!)


since then its working great....


It cold be my somewhat complicated setup Smiley (Mac OSX --> Parallels --> Win7 + Cheap powered "Trust" 7Port USB HUB). But theres no miner for OSX .... I'm Trying out cgminer (with help from a user here) or btcminer (with that java file that has to be copied into the java/extensions folder to work!).

Would love to see default support for mac from Ztex (i might even pay a little for it like for faster bitstreams) Smiley


Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
May 21, 2012, 09:43:47 PM
 #714

Are you using the -oh option?  This should prevent you from unwanted kick-outs. Make sure you set the value high enough. Try 0.2 or so. I'm using 0.7 at the moment. If you don't set it, the boards get kicked out after 3 to 4 frequency drops.

BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
May 21, 2012, 09:46:31 PM
 #715

I have that option enabled  with "-oh 0"  Thats the default value i think.

Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
May 21, 2012, 09:59:11 PM
 #716

Set it to 0.2 or 0.1 if you are afraid Tongue. A lower hashrate is better than a dead board.

rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
May 22, 2012, 03:45:10 PM
 #717

ztex can we please, with sugar on top, get a -f XXX commandline flag that hardcodes the frequency so that we can underclock the chips this summer?

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
May 22, 2012, 09:32:40 PM
 #718

that would be good Smiley

CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 306


View Profile
May 23, 2012, 02:10:49 AM
 #719

ztex can we please, with sugar on top, get a -f XXX commandline flag that hardcodes the frequency so that we can underclock the chips this summer?

And hopefully negate the need for AC Grin
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
May 23, 2012, 07:46:41 AM
 #720

I also experience these "hashrate drop errors", but only with BTCMiner. With cgminer 2.4.1 I've never got such an error. The hashrate drop code is present in cgminer. So what does it mean? The hashrate drop errors are present, but cgminer fails to detect them. Or, something is wrong within BTCMiner. One observation I've made... I get the hashrate drop errors in BTCMiner always around "new block" announcments.

These "hashrate drop errors" occur if the frequency is reduced too much because the error rate increases. If cgminer uses an other error rate detecting algorithm (e.g. slower sampling rate) it may oversee this errors.

I some cases (e.g. if ambient temperature increases by more then 10°C) the default setting may be a little bit to sensitive, try out "-oh 0.06" or "-oh 0.08", but not higher because that would break the overheat detection mechanism. If the frequency drops by more than 8% there are problems on the hardware side (cooling, power supply stability)



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 51 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!