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

LazyOtto,

being as lazy as you  I did test mpbm a couple of times, but in the end I swiched back to cgminer which I know better and which works flawlessly, at least for me, using either 2.4.1 or 2.4.3.

spiccioli

Better yet, how about switching the priority to MPBM?

Which was intended from the beginning to be FPGA rather than GPU oriented.

Yohan,

you're using an "old" version of cgminer, please build one of the lastest 2.4.x or even 2.5.0 (I'm not sure 2.5.0 is as stable as 2.4.x) but 2.4.3 as a minimum version.

See also https://bitcointalksearch.org/topic/m.968533

I'm using 2.4.3 (though on linux and with not so many boards) and I've never had the problem you're reporting.

spiccioli

Understandable, I am happy documentation is starting to catch up, it will help many who do want to contribute to it's development.
I've got both boards mining now and humming away at as fast as I expect 2 cores can do.

I look forward to every update, especially if your close to the bitstream for all 4 cores to be working. 

Had no luck getting both boards to mine in the same instance of CGminer so far, had to run one for each board.
Not that is a problem, since at the end of the day, it allows me to keep and eye on them, in case one decides to crash.
I use a pretty simple command line, since the rest is in a cgminer.conf file:

Let me know if I'm doing it wrong. 25 and 26 are for board 1, 22 and 27 are for board 2.
How they managed to auto-configure themselves that way I don't know, not going to change it now

However the below is the only way I get them to work, running them separately.

The cgminer.conf file is nearly identical except for the pool data, which I'm purposefully blanked out and is slightly different for each one, separate worker, at first allows me to alert me if one stops.

Hey, it works, can't complain just giving you my feedback and loving my new hardware.

Can you send us this as a support case with as much detail of your setup as possible.

The port numbers may change so you need to keep an eye on what is used.

We are going to try and shortcut some of this stuff so bear with us whilst get those materials get produced. It's been impossible to keep documentation up with the development progress and changes but that should be improving now as it settles down. What we should have today is a contstraints file for the array FPGA. That will tell you where dip switches and leds are. It's not going to be very complicated as there is a very small set of I/O.

The LEDs depend a lot on what is on the board has as configuration bitstreams and these do vary with them. Recently the back two are being shipped without a configuration bitstream. That will change with the next major release of bitstream when we bring all 4 FPGAs into operation.

The FPGAs notionally operate as 2 pairs at least in this iniial phase.

Unfortunately i'm in the same boat as you and getting frustrated now trying to find out what is causing my boards to run so slow. Currently 450Mh/s from 2 boards both running twin_test...

Please let me know if you find anything?

Im not 100% confident in this board at all;

If others are getting a U of ~5, you can see im getting about ~2 (cgminer reports similar figures)

As you can see, its quite bad;


Perhaps its time to contact enterpoint to return this board for testing/replacement?

Thanks for explaining that Yohan. Lets just make sure I understood it correctly.

I'm sorry if I sounded newbish. I'm just trying to discover in my own way how this all works. Yeah, I know it's not always a good idea.
SW 2-5 were not setup for the Twin bitstream, looked more like the initial shipping build, it was no bother, I got things working either way.

SW 2-5 are bitstream specific and your saying most settings most end users will tweak would be SW 1 and 6?
However when new bitsteams are made, those will be more important to make sure they are in the right place, or ignored entirely, depending on the bitsteam. I already expressed to you I would like a chance to make my own, once I learn how. So I'm going to go read up on what info their is on SW 2-5 to see if that will have any effect on how do a bitstream.

So the com ports are suppose to be sharing 2 of these spartan chips per port, but at the moment only 1 is being used per port.
The other 2 ports related to the JTAG and SPI (I first assumed it was for each chip).
So for me, that would be port 23 and 24 for JTAG and SPI, I can quiet happily remove those from the list of ports to be trying.

I notice how when first turned on all 4 leds of different colors come on next to the dip switches 2-5. I gathered this relates to a response by the chips themselves, slowly the front 2, one by one turn like a orange color, almost like it's "ready". But the back two don't. Thus they look like they are completely idle.

Interesting Stuff, but apparently I do need to go do abit more reading, since I have forgotten what was posted earlier in this now very long thread.

Just out of curiosity, have you tested or had a look at MPBM (Modular Python Bitcoin Miner) yet? It was actually designed for FPGA devices, whereas cgminer had FPGA support bolted on to a CPU/GPU mining core.

Possible CGminer Bug


We have got an intermittant internet today and we are having short periods when basically data isn't pass and we get timeouts. We have seen that in our big mining test reg, running on the same internet connection, that after such an outage that CGminer (V2.3.4) appears to stop scheduling work correctly to some or all of the stack of boards. It does continue to intermittantly schedule work and is not a total stoppage but hash rates appear to fall to less that half that expected. This does appear to be a  problem that a number of rig, and in particularly the bigger ones, are reporting. Once this happens there doen't seen to be any way to recover CGminer other than a complete restart.

You should have received the boards with DIP switches set for the loaded twin bitstream which does only run 2 FPGAs so expect hasing about 380MH/s. We are getting U here between 5 and 6 which what to expect at the moment. DIP switches SW2-5 usage is entirely dependent on the bitstream used. When we release our native bitstream they won't be used at all but settings for the "twin" are on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. We are now shipping all boards now with the "twin" bitstream running on positions 0 and 3. For the twin only the first 2 bits of each switch are actually used. One bit is a reset the other is the hash start point.

There are 4 com ports of which only 2 are used for coms. the other 2 are used for JTAG and SPI programming functions. If running windows the easy way to check what ones correspond to coms is to look in the Device Manager. It's usually fairly obvious in there. We do have a small utility coming that will do some port scanning that's mainly aimed at testing but might have some general application in helping setup.

There is also more info here:

http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html

My apologies for the testiness of my post.

I do believe if you scan back you'll find answers.

Look for posts from yohan with large graphics for quick scanning.

In fact, you might look at his profile and just look for his posts to make searching even faster.

I know what SW1 and 6 do. It's the other 4 I don't. If he did say what they did, I missed it. No need to assume I wanted to be spoon feed answers, I was asking a question I believe hadn't been answered yet. Page 66, has a nice little graph, but it only describes SW1 and 6. If the other switches are described elsewhere I will go look, I didn't know.

To be a bit more precise:

To an accurate number 95% of the time.

You have 68 pages to read to 100% catch up on this topic.
I suggest you start doing it in reverse chronological order looking for your answer.

By your tone, my impression is that you are asking to be spoon fed answers without trying to find them on your own.

If doing that research is too much work, then yeah, I suggest you start randomly flipping switches and see where that gets you.

BTW, it takes a full day, or two, for the cgminer U metric to be fully settled down to a solid number. Actually, longer than that, but a couple of days will get you to about a 95% accurate number.

Did some tinkering, I noticed the default for queue was still at 1, same as my little laptop uses on it's GPU's.
I figured something 5-10x more powerful would need to have a bit of room as it eats through it's queue of work.

It did increase the U rate, it appears to now hover over 7, has done for a while now. It's still rising a little as I type this.
Takes a little while before it does, but it did not get to 7 the first hour I had it at a queue of 1, it barely got to 6.

However I have no idea what this is? E: 220% + (it's often this high)

It's only recognising 2 of the 4 ports.
This one is using ports 23, 24, 25 and 26. However complains about ports 23 and 24 at start up of CGminer.

"Cairnsmore Detect: Test failed at \\.\COM23: get 00000000, should: 000187a2"
"Cairnsmore Detect: Test failed at \\.\COM24: get 00000000, should: 000187a2"

So Yohan, there is a lot of other switches on this board, what do the rest do, or do I start play guessing games with seeing what they do?

Thats pretty close.  A native icarus @ 380Mh/s does U:5.2

kind regards

Right now it's hovering between 5 and 6. That U rate is the shares per minute as I understand it.
Which in comparison to my laptops 80 Mhash/s U rate of nearer to 1, would make it feasible it's doing 400Mhash/s.

Lets go back to tinkering, lets see why the other chips don't want to play with the others