Cairnsmore1 - Quad XC6SLX150 Board

[yohan]

BTW, yohan, it is really not my intent to bust your balls about this.

IMO, you / Enterpoint have been vastly more upfront in communications than 'that other company'.

I'm merely trying to keep the story straight.

That's fair enough.

I also don't want to get too distracted on all of this and actually keep moving our product forward and I think we are doing that. I know that is not always visible to the forum but it is happening. Also I can't make a specific promise (or I will get balled out that) but 800 MH/s switchover might be academic anyhow in not so distant future.

What I might do if I find a little time is a quick pass though pin adapting design for the first FPGA in the pairs and show the back FPGAs working as half Icarus. That will shown that tha back half is at least as good the front and maybe if we need to do a little more work on the controller for that. I think we are ok already on the latter but a further check does not do any harm. Ok it's not a total answer but it might calm any uncertainty about what we have as a hardware platform.

[1714212296]

1714212296

[1714212296]

1714212296

[1714212296]

1714212296

[1714212296]

1714212296

[LazyOtto]

A fair reply, thank you.
And thank you for your continued contributions / presence in this forum.

I do suggest that, as you have already indicated you're switching over to, a de-emphasis needs to be placed on support - to a near level of nothing - and the admittedly finite resources prioritized to internal/primary product development and tuning. Of course, you have to make a judgement call as to how much this 'support' effort provides value to knowing what changes/revisions are required in the core hardware/firmware.

Everyone who has one of these in hand now purchased it under the statement that 'you are on your own', you are expected to be able to break your own trail or be patient until better firmware comes out. It was sold as 'beta' / 'developer's toy' with no commitments to any level of performance.

IOWs, current owners can make it better via their own resources or hold their horses until improvements are ready for general availability.

Also, IOWs, I approve of how Enterpoint has been doing business. I know it is hard to ignore the cries for assistance from current, pre-release, customers, but priorities must be set and followed.

--

However, I really do appreciate the much improved graphics and documentation about DIP switch settings / behavior and the other incremental releases of 'stuff'.

Whatever can be done in parallel without jeopardizing mainline progress is a good thing.

[ice_chill]

Meanwhile my Single from America is happily hashing away at 815MH/s

[LazyOtto]

I also suggest you don't try to discount / disregard the until '800 MH/s is reached' price statement.

Enterpoint needs to either honor that, or you need to confess that you spoke out of school and Enterpoint is not bound by your statements. (As distasteful as that might be.)

This audience has been hyper-sensitized to stated commitments which are not subsequently honored. Perhaps not fair to Enterpoint, but it is what it is.

Enterpoint's biggest advantage at this point is the reputation you have established in this forum. It might be a bitter pill, but that reputation needs to be upheld or take a hit.

[yohan]

A fair reply, thank you.
And thank you for your continued contributions / presence in this forum.

I do suggest that, as you have already indicated you're switching over to, a de-emphasis needs to be placed on support - to a near level of nothing - and the admittedly finite resources prioritized to internal/primary product development and tuning. Of course, you have to make a judgement call as to how much this 'support' effort provides value to knowing what changes/revisions are required in the core hardware/firmware.

Everyone who has one of these in hand now purchased it under the statement that 'you are on your own', you are expected to be able to break your own trail or be patient until better firmware comes out. It was sold as 'beta' / 'developer's toy' with no commitments to any level of performance.

IOWs, current owners can make it better via their own resources or hold their horses until improvements are ready for general availability.

Also, IOWs, I approve of how Enterpoint has been doing business. I know it is hard to ignore the cries for assistance from current, pre-release, customers, but priorities must be set and followed.

--

However, I really do appreciate the much improved graphics and documentation about DIP switch settings / behavior and the other incremental releases of 'stuff'.

Whatever can be done in parallel without jeopardizing mainline progress is a good thing.

It's definately not the case that "customers are on their own" or will be but there are finite resources right now. I would put it that it will be more a slow down in support response time this week but it's for the greater good towards the goal of better performance and reliablity. Anyone who does have a Cairnsmore1 problem should still send us as much information about their issue as they can to our "bitcoin.support" email. That way we have a track record of it and hopefully don't miss it. Unless you have done developments like this yourself before it's not easy to imagine what goes on here as a development task as complex as Cairnsmore1 or even the support issues of dealing with hundreds or even thousands of possible rig hardware/software combinations used with the product.

[wildemagic]

... the support issues of dealing with hundreds or even thousands of possible rig hardware/software combinations used with the product.

Should be a non event, every other mining fpga plugs into a usb port, hardware issues aside, if it works on one pc it should work on another.
I dont think its appropriate to blame your end users.  You have even gone as far as to tell people to cut usb cables and modify them blaming vague power issues.

I think you need be honest with your end users instead of hiding behind hyperbole.

Others in this thread think you have a fab reputation based on your communication here minute to minute, but I think they were just drawn in by the chance to get a quad lx150 for $650.
The reality is going to set in soon that they have been taken for a ride unless you get the hardware performing.  You need to get a working bitstream out.

The whole 'we dont have the time' excuse for not yet having a working bitstream is starting to sound a bit 'broken record'

Are you actively working with Elden to get the tricone bitstream working? Or did you give him just enough information to get him started?
You made comments that alluded to it being a done thing, why then are other users unable to get it working?

kind regards

[Lethos]

The problem with me having one core working much slower that the other ones is back.
I am running 3 boards with an unpowered usb-hub at an usb3 port (the boards do not even detect correctly in regular usb ports). Running the twin_test bitstream, with the correct dipswich positions used while flashing and operating, as indicated in your pdf. The miner I am using is yor cgminer_twintest.exe I am starting it with the command cgminer_twintest -o mint.bitminter.com:8332 -u USR -p PASS --disable-gpu -S noauto -S\\.\COM22 -S \\.\COM23 -S \\.\COM26 -S \\.\COM27 -S \\.\COM30 -S \\.\COM31

Any other relevant information that would help identifying this, just ask.

Just quoting this, since the command line stuff was useful for me to start getting these working for me.
Needed to modify mine for the right com ports. Will provide feedback and results later today.

Just got my 2 boards. Doing one at a time, I'm sure the other works fine.
Got one working and flashed to latest bitstream. CGminer tells me it's hashing away at 825Mhash/s, so I'll wait for my pool to confirm this.

[wildemagic]

CGminer tells me it's hashing away at 825Mhash/s, so I'll wait for my pool to confirm this.

If your U:rate is 10-11 then its doing 800Mh/s, but more likely its doing alot less than that.
Most users are reporting between U:1-4 per board.

kind regards

[Lethos]

CGminer tells me it's hashing away at 825Mhash/s, so I'll wait for my pool to confirm this.

If your U:rate is 10-11 then its doing 800Mh/s, but more likely its doing alot less than that.
Most users are reporting between U:1-4 per board.

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

[wildemagic]

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.

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

kind regards

[Lethos]

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?

[LazyOtto]

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.

[LazyOtto]

To be a bit more precise:

To an accurate number 95% of the time.

[Lethos]

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.

[LazyOtto]

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.

[LazyOtto]

There is also more info here:

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

[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.

[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.

[rjk]

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.

[Lethos]

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.