Cairnsmore1 - Quad XC6SLX150 Board

[daemonic]

twin_test.bit (DIP's setup as per twin_test.pdf)
 Temporary Flash

Code:

  CM1: Running at 182.715256 MH/s
  CM1: Job interval: 17.805074 seconds
  CM2: Running at 181.279004 MH/s
  CM2: Job interval: 17.954064 seconds

 Notes
   CM2 (FPGA3) gets 50-70% less shares than CM1 (FPGA0) (Average Utility of 1.4-1.5 & 0.8-0.9)
   Also quite a few of the following errors on both FPGA's

Code:

    Watchdog triggered: 27276.511018 MHashes without share

Permanent Flash;

Code:

  CM1: Running at 185.160183 MH/s
  CM1: Job interval: 17.556764 seconds
  CM2: Running at 185.160183 MH/s
  CM2: Job interval: 17.556764 seconds

 Notes
   CM2 (FPGA3) gets 50-70% less shares than CM1 (FPGA0) (Average Utility of 1.4-1.5 & 0.8-0.9)
   Also quite a few of the following errors on both FPGA's
    Watchdog triggered: 27276.511018 MHashes without share

The detected Mh/s is completly different each start of the worker, but after some seconds it will show you the correct Mh/s in the website of mpbm.
The Watchdog message come from my changes in the timings, the original timings wait ~3 times longer until it restarts the worker. It could be realy normal to get that message from time to time. But if you can watch the LED's and if you get the message when the orange LED is turned on, you will notice that then it turn off. this is the behavor I had on my board#0015. And my shorten timings make sure the board don't have the orange LED (no work/job) to long.

Im not 100% confident in this board at all;
http://www.unstable.org.uk/images/temp/twin_test.bit.png
If others are getting a U of ~5, you can see im getting about ~2 (cgminer reports similar figures)

190M_V3.bit (DIP's setup as per twin_test.pdf)
 Temporary Flash

Code:

  CM2: Running at 180.333944 MH/s
  CM2: Job interval: 18.053395 seconds
  CM1: Running at 180.333944 MH/s
  CM1: Job interval: 18.053395 seconds

 Notes
   First few shares ok, then;

Code:

   CM1: Got K-not-zero share eed4cb24
   CM1: Got K-not-zero share c1842661
   CM2: Got K-not-zero share 8c318943
   CM2: Got K-not-zero share 2fc4854e

Permanent Flash
  Not even detected

Please take a look at the mpbm webconfiguration, the interessting part are the invalid shares, they must be realy high on your board or the Watchdog messages come really often (orange LED turn on very often).

As you can see, its quite bad;
http://www.unstable.org.uk/images/temp/190M_V3.bit.png

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

[norulezapply]

-snip-

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?

[yohan]

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?

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.

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.

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.

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.

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.

[yohan]

twin_test.bit (DIP's setup as per twin_test.pdf)
 Temporary Flash

Code:

  CM1: Running at 182.715256 MH/s
  CM1: Job interval: 17.805074 seconds
  CM2: Running at 181.279004 MH/s
  CM2: Job interval: 17.954064 seconds

 Notes
   CM2 (FPGA3) gets 50-70% less shares than CM1 (FPGA0) (Average Utility of 1.4-1.5 & 0.8-0.9)
   Also quite a few of the following errors on both FPGA's

Code:

    Watchdog triggered: 27276.511018 MHashes without share

Permanent Flash;

Code:

  CM1: Running at 185.160183 MH/s
  CM1: Job interval: 17.556764 seconds
  CM2: Running at 185.160183 MH/s
  CM2: Job interval: 17.556764 seconds

 Notes
   CM2 (FPGA3) gets 50-70% less shares than CM1 (FPGA0) (Average Utility of 1.4-1.5 & 0.8-0.9)
   Also quite a few of the following errors on both FPGA's
    Watchdog triggered: 27276.511018 MHashes without share

The detected Mh/s is completly different each start of the worker, but after some seconds it will show you the correct Mh/s in the website of mpbm.
The Watchdog message come from my changes in the timings, the original timings wait ~3 times longer until it restarts the worker. It could be realy normal to get that message from time to time. But if you can watch the LED's and if you get the message when the orange LED is turned on, you will notice that then it turn off. this is the behavor I had on my board#0015. And my shorten timings make sure the board don't have the orange LED (no work/job) to long.

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)

190M_V3.bit (DIP's setup as per twin_test.pdf)
 Temporary Flash

Code:

  CM2: Running at 180.333944 MH/s
  CM2: Job interval: 18.053395 seconds
  CM1: Running at 180.333944 MH/s
  CM1: Job interval: 18.053395 seconds

 Notes
   First few shares ok, then;

Code:

   CM1: Got K-not-zero share eed4cb24
   CM1: Got K-not-zero share c1842661
   CM2: Got K-not-zero share 8c318943
   CM2: Got K-not-zero share 2fc4854e

Permanent Flash
  Not even detected

Please take a look at the mpbm webconfiguration, the interessting part are the invalid shares, they must be realy high on your board or the Watchdog messages come really often (orange LED turn on very often).

As you can see, its quite bad;


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

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

[Lethos]

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.

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:

Code:

cgminer_twintest --disable-gpu -S noauto -S \\.\COM25 -S \\.\COM26 -S \\.\COM22 -S \\.\COM27

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.

Code:

cgminer_twintest --disable-gpu -S noauto -S \\.\COM25 -S \\.\COM26
cgminer_twintest --disable-gpu -S noauto -S \\.\COM22 -S \\.\COM27

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.

Code:

{
"pools" : [
	{
		"url" : "xxx",
		"user" : "yyy",
		"pass" : "zzz"
	},
	{
		"url" : "xxx",
		"user" : "yyy",
		"pass" : "zzz"
	}
],

"api-port" : "4028",
"disable-gpu" : true,
"expiry" : "120",
"log" : "5",
"queue" : "2",
"retry-pause" : "5",
"scan-time" : "60",
"kernel-path" : "/usr/local/bin"
}

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

[spiccioli]

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.

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://bitcointalk.org/index.php?topic=78239.msg968533#msg968533

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

[LazyOtto]

Better yet, how about switching the priority to MPBM?

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

[spiccioli]

Better yet, how about switching the priority to MPBM?

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

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

[norulezapply]

Better yet, how about switching the priority to MPBM?

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

Bizarrely, when I switched to MPBM I got approximately half the hashrate of that I was getting in cgminer.

That said, both of them are severely underperforming with the twin_test.bit.

(I get nowhere near 380Mh/sec/board)

[Doff]

Will there be any plan to work with the Con, or Kano to get the Cairnsmore supported in Cgminer instead of it showing as an icarus unit? I'm a bit against the Modular miner mainly because it seems like its not being worked on as much anymore. It would be nice if it showed up as a Cairnsmore in Cgminer and was specifically supported for the new bitstream.

[LazyOtto]

spiccioli, I can't argue with hands-on experience.

I'm so lazy I don't even have hardware to play with yet.

Merely waiting as fast as I can and reading about what I can't actually be doing.

[Doff]

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.

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://bitcointalk.org/index.php?topic=78239.msg968533#msg968533

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

Ive been using Cgminer 2.5.0 for the last 3 days and have had a consistent 2.6 U on each fpga for the last 3 days without interruption. I was having a problem with 2.4.3 where my Actual Icarus unit would shut off after about 12 hours, 2.5.0 seemed to fix that as well.

[LazyOtto]

Ive been using Cgminer 2.5.0 for the last 3 days and have had a consistent 2.6 U on each fpga for the last 3 days without interruption. ...

Uh, what does that statement actually mean, please?

There are four FPGAs on the board. Are you getting 10.4 U (cgminer U) per board? Or are you getting 2.6 U per board? Or some other permutation?

[Doff]

Ive been using Cgminer 2.5.0 for the last 3 days and have had a consistent 2.6 U on each fpga for the last 3 days without interruption. ...

Uh, what does that statement actually mean, please?

There are four FPGAs on the board. Are you getting 10.4 U (cgminer U) per board? Or are you getting 2.6 U per board? Or some other permutation?

Im getting 5.2 U combined on ave for the Twin_test Bitstream which is about = to 1 Icarus board. In Cgminer it would look like 2 Icarus units running at 2.6 U. Thats about the best you get currently for 1 Cairnsmore until they get their Bitstream out to us.

[LazyOtto]

Thank you, Doff.

And congratulations. I think you are getting far better than most have reported in this thread.

I am sincerely happy to hear your successful numbers.

--

Hmmm, ok, I've gone back and rethought and it looks like you're reporting about 370 MH/s. Which is in line with what others have reported. Guess I was just confused by the "per FPGA" statement.

Thank you for the clarification.

[misternoodle]

I've been getting the same results as Doff.  Running with no issues lately, just eagerly awaiting the final bitstream.

[Lethos]

According to my pool I use, one of my boards is averaging (over 1 hour) 375 Mh/s and the other is 400 Mh/s.
Impressed so far.

[norulezapply]

Gonna have to get a support email submitted.

Everyone's success stories are depressing me and my two under-performing boards

[Lethos]

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.

Out of curiosity I switched from using the cgminer source provided on the support page, to the cgminer that I usually use (3.43), which is more up to date, and it happily works with more than 1 board at once. Will try 3.50 soon, but will trial run this one first, see if it runs it any more stable.

[yohan]

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.

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://bitcointalk.org/index.php?topic=78239.msg968533#msg968533

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

Ive been using Cgminer 2.5.0 for the last 3 days and have had a consistent 2.6 U on each fpga for the last 3 days without interruption. I was having a problem with 2.4.3 where my Actual Icarus unit would shut off after about 12 hours, 2.5.0 seemed to fix that as well.

It is our plan to get Cairnsmore1 adopted into the official CGminer but we want to be in something of stable position. I think we are pretty much there now. I think we should look at 2.5.0 to seeif that is better and get that looked at in the next few days. What we are trying to avoid is unnecessarily changing when other things are changing as well. The reason for that is to minimise the risks of a support nightmare of changing several things together and something going badly wrong. That's a fairly normal approach on a project like this.

The problem, or bug, we saw was by sheer luck. If you have a rock solid internet connection you would not see it the same way we did. It just happens that our local area is getting internet improvements and we have been getting short interuptions on our service. These interruptions then lead to the drop of hashing rates. We have seen this happen under the same circunstances a number of times so we are pretty sure of the association.