Do u honestly belive in "build in time to fail counters"?
:d
Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards - page 15. (Read 182443 times)
May 23, 2012, 06:09:44 AM
May 23, 2012, 05:53:07 AM
I think you need to wakeup, every product in your home has been designed to break after a certain time after your warranty expires.
May 23, 2012, 05:26:53 AM
No it would be Bad(er) for business if the boards tend to break .... 
I only invest into things that are durable and covered by warranty.
I only invest into things that are durable and covered by warranty.
May 23, 2012, 05:19:52 AM
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?
Wee already discussed this: https://bitcointalksearch.org/topic/m.802603
Ok, could you add a zero error rate command... that lowers the frequency until error rate is = 0.00% forever?
I understand it's bad for business if the cards never break, because then we wont buy new ones, but we would like to be ABLE to control the heat. It should be easy no?
Basically can you try to add anything for the passive community to control longevity.
May 23, 2012, 04:05:53 AM
ztex, can you please upgrade the AOZ1025 buck regulator on your designs to another able to output more than 8A to each FPGA, and more efficient? Multiple groups (eldentyrell, bitfury, etc) are writing bitstreams pushing the LX150 beyond 8A... And the AOZ1025 is not super efficient.
Perhaps the IR3840MPbF (86% efficient at 12A output at 1.2V) ?
Perhaps the IR3840MPbF (86% efficient at 12A output at 1.2V) ?
May 23, 2012, 03:04:59 AM
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?
Wee already discussed this: https://bitcointalksearch.org/topic/m.802603
May 23, 2012, 02:57:30 AM
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!)
These PSU's become unstable (interruptions) if they get to hot. Try to connect four singles to one 60W PSU,
May 12, 2012, 03:32:18 AM
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
Yes, electrically conductive thermal grease should be avoided. It's something I have to add the the red warning slips.
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...
May 23, 2012, 02:46:41 AM
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)
May 22, 2012, 09:10:49 PM
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
May 22, 2012, 04:32:40 PM
that would be good
May 22, 2012, 10:45:10 AM
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?
May 21, 2012, 04:59:11 PM
Set it to 0.2 or 0.1 if you are afraid 
. A lower hashrate is better than a dead board.
. A lower hashrate is better than a dead board. May 21, 2012, 04:46:31 PM
I have that option enabled with "-oh 0" Thats the default value i think.
May 21, 2012, 04:43:47 PM
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.
May 21, 2012, 04:26:07 PM
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
(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)
May 21, 2012, 03:35:50 PM
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. May 21, 2012, 07:18:40 AM
Its not only hash rate drops also libusb errors occur. i try to find some logs for this.
May 21, 2012, 05:45:51 AM
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?
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.
May 21, 2012, 03:48:54 AM
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.
I'll have to change that in the near future.
Jump to: