Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 17. (Read 286370 times)

yohan, unless invalid (i.e. difficulty < 1) shares are below a certain level (5%?) using high-performance bitstreams should not be an issue. Do you disagree on that?

Bull, 220 is certainly not any real issue for spartan (mine is runing runing 250-270mhash). And I know for a fact it can go to 300 and above.

We have seen what appear to be one or two total internal FPGA failures in the field which we are still gathering data and information on. It may be coincidence but 220 bitstreams were running on these boards. From some of the work we have done here we can see there is usual a big increase in power used when 210 and 220 bitstreams are in used and that is what we are worried about. Tied to that there is very little real performance to be gained particluarly on a 220 bitstream on most boards and often boards will actually give better return on a 200 bitstream. So for now our official recommendation is 200 or less bitstreams. 210 is probably ok but we need more data to confirm that.

behind all of this there is an effect called thermal runaway that is likely to be happening where the presence of heat allows higher currents to flow and hence more heat generated again i.e. runaway. We think all of the higher end bitstreams above 180 have an noticable element of this it is really down to how bad. Plotting performance against current isn't linear as it should be if clock rate was the only effect so we are pretty sure that is what is happening. There will be variations of this effect with silicon and to some small degree an enviromental effect. The cooling solution we have on CM1 is good but fundamentially the FPGA package is the main limitation to extracting heat given the performance of what we have in cooling. If room temperature is cold that will help a little and conversely if the room is hot.

We think the real problem comes when the devices go unstable often manifesting as high invalids and it is possible in this senario the currents go even higher than when we have measured on "stable" boards. Eberon has made some comments on this previously in one of the threads somewhere. The "damaging effect" may be one of a couple of things. First is the die just getting to hot. It's also possible that internal bond wires fail with too high a current and something basically melts. It is going to take us a while to get anything more solid than we know now so that is about as much as I can tell you all now.  

Pretty sure the CM1 uses a bigger fan and better heatsinks though...

Assuming you are pointing at the right usbports...

First do a power cycle, and then reconnect stuff and use the modprobe command, try again, did that help?
If not then try reflashing the board. Try again after doing the above.

Well, the FGG484 package that Enterpoint are using is apparently much worse at dissapating heat compared to the CSG484 package that Ztex's boards use, but...

@Luke-Jr @Lethos

Finally, after install some dependencies libraries I make bfgminer working on one of my rig (although still need to figure out how to enable GPU mining with bfgminer).

However, on the other rig with bfgminer I got:

@kano
Thanks! Will try that.

Yohan, can you comment on this?

Yeah, that didn't add up to me either. I was always under the impression bitstreams can't effect it's "power" or "voltage", nor would it change automatically even if you pushed it hard via overclocking. The worst that happens is invalids or errors in the output.

Interesting:

Try this (old script I got from Xiangfu that I enhanced) on each of the linux USB ports that you expect to work like Icarus:

https://raw.github.com/kanoi/cgminer/ztex/usbtest.py

 ./usbtest.py /dev/ttyUSB0 icarus

It has a habit of clearing any USB problems if that is the cause.
If that's not the cause, well then it wont help
Also it's not very 'tidy' coz I don't like python

I've needed it sometimes when I've moved an Icarus from windows to linux
( and I still don't know exactly how python fixes that - even after I wrote copious amounts of termios debug ... as you will see commented out in fpgautils.c ... the problem I get is actually when the port is opened ... and python somehow clears that problem)

... again ... if that's not the cause, well then it wont help.

First version of Cairnsmore1 user manual is now available on http://www.enterpoint.co.uk/cairnsmore/CAIRNSMORE1_MANUAL_ISSUE1.pdf. I doubt it is perfect and we will try and improve this again in a few weeks time.

I've never used any " " to reference the usbports, so I assume that would be the problem.
So it's more like:
Also it depends on which bitstream you are using to what ports to reference.

Make sure you have issued the modprobe command as well before hand.

Mak's only uses 2, hashvoodoo uses all 4.
If you need a simple guide on flashing new bitstreams;
https://bitcointalksearch.org/topic/m.1110647

If you search through this thread, there is a ton of information, just a matter of searching for it.

@salty @makomk
Already tried this but didn't work. Even when the list seems properly:


update: I'll try on my another rig later.

That's almost surely a result of some error in the previous steps. Can you pastebin the output from those?

@tnkflx
Strange..

BOINC / F@H use for CM1s?

https://bitcointalksearch.org/topic/boinc-fh-fpgas-110778

One way to find out would be to get cgminer to scan them all, then check the log for a message like 'found Icarus on /dev/ttyUSB5' ie:-


In fact, if your com ports change between reboots, you could just let it check every time you start the miner.

That's almost certainly the wrong COM port. Try /dev/ttyUSB2 and /dev/ttyUSB3.