Bitcoin Forum
December 04, 2016, 12:03:35 AM *
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 ... 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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 [68] 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 ... 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251125 times)
daemonic
Jr. Member
*
Offline Offline

Activity: 49


View Profile
July 16, 2012, 02:53:14 PM
 #1341

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?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480809815
Hero Member
*
Offline Offline

Posts: 1480809815

View Profile Personal Message (Offline)

Ignore
1480809815
Reply with quote  #2

1480809815
Report to moderator
1480809815
Hero Member
*
Offline Offline

Posts: 1480809815

View Profile Personal Message (Offline)

Ignore
1480809815
Reply with quote  #2

1480809815
Report to moderator
1480809815
Hero Member
*
Offline Offline

Posts: 1480809815

View Profile Personal Message (Offline)

Ignore
1480809815
Reply with quote  #2

1480809815
Report to moderator
norulezapply
Sr. Member
****
Offline Offline

Activity: 475


View Profile
July 16, 2012, 03:03:13 PM
 #1342

-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?

If my post helped, I'll happily accept a few bitmills!   15rGg6A1JFZV3b7TTbtpAaiYGdUD1e1oAm
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 16, 2012, 03:19:07 PM
 #1343

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
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 16, 2012, 03:24:46 PM
 #1344

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
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
July 16, 2012, 03:41:39 PM
 #1345

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 Tongue

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.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 16, 2012, 05:50:51 PM
 #1346

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
Sr. Member
****
Offline Offline

Activity: 476


View Profile
July 16, 2012, 05:53:14 PM
 #1347

Better yet, how about switching the priority to MPBM?

Which was intended from the beginning to be FPGA rather than GPU oriented.
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 16, 2012, 05:57:31 PM
 #1348

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  Smiley 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
Sr. Member
****
Offline Offline

Activity: 475


View Profile
July 16, 2012, 05:57:57 PM
 #1349

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)

If my post helped, I'll happily accept a few bitmills!   15rGg6A1JFZV3b7TTbtpAaiYGdUD1e1oAm
Doff
Sr. Member
****
Offline Offline

Activity: 327


View Profile
July 16, 2012, 06:00:35 PM
 #1350

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
Sr. Member
****
Offline Offline

Activity: 476


View Profile
July 16, 2012, 06:07:14 PM
 #1351

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

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

Merely waiting as fast as I can and reading about what I can't actually be doing.
Doff
Sr. Member
****
Offline Offline

Activity: 327


View Profile
July 16, 2012, 06:13:34 PM
 #1352

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
Sr. Member
****
Offline Offline

Activity: 476


View Profile
July 16, 2012, 06:22:55 PM
 #1353

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
Sr. Member
****
Offline Offline

Activity: 327


View Profile
July 16, 2012, 06:27:40 PM
 #1354

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
Sr. Member
****
Offline Offline

Activity: 476


View Profile
July 16, 2012, 06:40:42 PM
 #1355

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
Member
**
Offline Offline

Activity: 108



View Profile
July 16, 2012, 06:45:05 PM
 #1356

I've been getting the same results as Doff.  Running with no issues lately, just eagerly awaiting the final bitstream. Smiley
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
July 16, 2012, 07:00:43 PM
 #1357

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.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
norulezapply
Sr. Member
****
Offline Offline

Activity: 475


View Profile
July 16, 2012, 08:50:29 PM
 #1358

Gonna have to get a support email submitted.

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

If my post helped, I'll happily accept a few bitmills!   15rGg6A1JFZV3b7TTbtpAaiYGdUD1e1oAm
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
July 16, 2012, 09:08:13 PM
 #1359

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.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 16, 2012, 09:29:08 PM
 #1360

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.
Pages: « 1 ... 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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 [68] 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 ... 129 »
  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!