Cairnsmore1 - Quad XC6SLX150 Board

[yohan]

Gonna have to get a support email submitted.

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

Do send us the info and we will do our best to sort it out.

[yohan]

Better yet, how about switching the priority to MPBM?

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

We will look at other options but we don't really want to do that in a hurry unless we can't solve the CGminer? issues. To do so could open up a pile more of support issues to deal with and that would slow progress on all the new things we are working on and want to bring for you all to use. I think we will try CGminer 32.5.0 first and see where that takes us.

[Lethos]

haha, I most definitely don't know what a rock solid internet connection is, I've just moved house and currently mining via my laptop which is tethering via my blackberry. I have a feeling my phone provider is rather unhappy with me right now. Cable broadband just 24 hours away, yay!

[Doff]

Better yet, how about switching the priority to MPBM?

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

We will look at other options but we don't really want to do that in a hurry unless we can't solve the CGminer? issues. To do so could open up a pile more of support issues to deal with and that would slow progress on all the new things we are working on and want to bring for you all to use. I think we will try CGminer 3.5.0 first and see where that takes us.

I think he meant 2.4.3, and 2.5.0 the current release on the cgminer thread is 2.5.0.

[Lethos]

2.5 seems more stable right now, than the others, we shall see if it remains that way in the morning.

[daemonic]

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

Essay sent as requested

[norulezapply]

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

Essay sent as requested

Writing my essay now too

EDIT: essay sent. Eagerly awaiting your reply yohan...

[kano]

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.

Firstly: to state the obvious - if ANY miner cannot talk to the pool, yeah there is a good chance there will be problems ...

Secondly: seriously? ... cgminer has problems in an old version when your internet connection is shit ...
Is this supposed to be some revelation or something? Seriously? A 20pt font bitching about a bug in an old version? Seriously?

Anyway ...
What you guys did with cgminer was ONLY:
1) Take a now OLD version of it and change the Icarus Serial I/O speed to half it's value.
2) change the names it shows everywhere
(Then break the license by releasing it without source code until we complained about that)

What CGMINER does support is a proper working Icarus bitstream, which I guess I must have misread here somewhere that this was supposed to work on your hardware ...

Cgminer also includes code to support an Icarus bitstream that runs slower or faster that may or may not be perfect but I can certainly say that I have no high certainty since I've never seen any hardware from you guys (that isn't a REV3 Icarus) and don't ever expect to either
The only support I've had with that code is a few people (thanks to them) who have your board and came to the #cgminer IRC channel and I helped them configure it and got some feedback about it.

Reporting an OLD unrelated bug in your thread as an excuse to bitch about cgminer support ... that you have not bothered to do anything about ... seriously?

What's that well known comment with cgminer?    RTFM!
Or in this case the NEWS file.
There have been numerous changes to cgminer since Version 2.3.4 - April 25, 2012 (the NEWS file is now 413 lines longer since then)
... and quite a few are network/pool related ...

... and if the bug does still exist ... then report it with the current version in the right place like you know you should
I can explain the normal steps to deal with reporting bugs that I'm sure most people understand if that's something you need to learn about .............

[wildemagic]

Kano, Yohan is just grasping at straws trying to string along potential customers.

His inability to admit his hardware is flawed has lead him to instead try and blame everything else.

He has even gone as far as saying that all hardware is fully tested before shipping, even tho NONE of the hardware works as planned.
They dont even have a bitstream that works, so clearly they cant be sure the hardware is working properly.

The fact that his outbursts have increased under further scrutiny leads me to believe that he knows his hardware has issues.
I hope for CM1 customer's sake this is not the case, but its increasingly apparent that it may be.

I was going to suggest he RTFM, but its doubtful that he would read the manual to help solve a problem that he knows isnt related to CGMiner software.

Heck, how many FPGA/pc system and OS combinations work fine with CGMiner?

How many FPGA hardware vendors try to get their customers to cut up their USB cables on a whim?

Its a pity he has resorted FUD instead of admitting the issues are in the underlying hardware.

Then he jacks up the price based on another untruth about Elden's tricone bitstream working.

kind regards

[rjk]

To stop Kano's bitching, it might be a good idea to provide remote access to a device so that he can fix the cgminer bugs that the hardware seems to be tickling.

wildemagic, geez, I don't even know what to say. It appears that you have no idea what a monumental task it is to provide a complete hardware and software package. Perhaps you should be over at the Lancelot thread, moaning about how it hasn't even been delivered yet?

[wildemagic]

wildemagic, geez, I don't even know what to say.

I do, I simply asked questions to begin with, as a customer I might add, then yohan proceeded to attack and ridicule.
So I withdrew my order and purchased alternate hardware.  Im now here merely to shine a light on the bullshit being peddled.

There are still plenty of people being enticed by the $640 price tag that likely dont know of the hardware faults.
There are plenty of fanbois in here that are only hoping their cheap hardware will work, their faith in Yohan is based completely on the price, not on the delivered promises.

kind regards

[Keninishna]

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.

Firstly: to state the obvious - if ANY miner cannot talk to the pool, yeah there is a good chance there will be problems ...

Secondly: seriously? ... cgminer has problems in an old version when your internet connection is shit ...
Is this supposed to be some revelation or something? Seriously? A 20pt font bitching about a bug in an old version? Seriously?

Anyway ...
What you guys did with cgminer was ONLY:
1) Take a now OLD version of it and change the Icarus Serial I/O speed to half it's value.
2) change the names it shows everywhere
(Then break the license by releasing it without source code until we complained about that)

What CGMINER does support is a proper working Icarus bitstream, which I guess I must have misread here somewhere that this was supposed to work on your hardware ...

Cgminer also includes code to support an Icarus bitstream that runs slower or faster that may or may not be perfect but I can certainly say that I have no high certainty since I've never seen any hardware from you guys (that isn't a REV3 Icarus) and don't ever expect to either
The only support I've had with that code is a few people (thanks to them) who have your board and came to the #cgminer IRC channel and I helped them configure it and got some feedback about it.

Reporting an OLD unrelated bug in your thread as an excuse to bitch about cgminer support ... that you have not bothered to do anything about ... seriously?

What's that well known comment with cgminer?    RTFM!
Or in this case the NEWS file.
There have been numerous changes to cgminer since Version 2.3.4 - April 25, 2012 (the NEWS file is now 413 lines longer since then)
... and quite a few are network/pool related ...

... and if the bug does still exist ... then report it with the current version in the right place like you know you should
I can explain the normal steps to deal with reporting bugs that I'm sure most people understand if that's something you need to learn about .............

I don't understand why yohan is afraid of a support nightmare? All they are responsible for so far is just the hardware and the bitstream for the controller. The mining bitstream isn't even theirs. In fact if enterpoint opened as much documentation to the public as possible I'm sure people would be happy to work with the hardware and they would have less support issues as the community itself is pretty supportive. Even if there is issues with the OS, drivers and cgminer, those can all be fixed. Only thing that can cause a support nightmare is if the hardware is fundamentally flawed and everyone has to return their unit. Even if this is the case, there is no avoiding it. Might as well get it over with instead of putting it off.
One thing I don't udnerstand as well is why enterpoint or anyone has not been able to load all 4 fpgas with icarus bitstream? I understand the tx/rx pins were switched on one or two? fpgas and that could be fixed, but shoulden't that be easy to change in the icarus miner code or even on the controller? Just my 2 bitcents.

[P_Shep]

I'm a little confused.

How can cgminer have a bug with hardware that it doesn't even support?

[kano]

To stop Kano's bitching, it might be a good idea to provide remote access to a device so that he can fix the cgminer bugs that the hardware seems to be tickling.
...

What cgminer bugs?
If there is one - yeah I'm happy to see what it is and fix it.
But there is also a thread for that and a way to report bugs so that they can be fixed.
I guess you need lessons about that too?

I don't see one reported other than crap about an old version having an issue when the internet connection is shit.
I'm sure everyone here using these boards and having problems has crap internet issues ... yeah good excuse that one ...

So far all that Yohan has been posting for the last while are fixes for problems with his hardware and the only posts I see here recently about using cgminer is that it works ... except this stupid comment about a hash rate issue with an old version when the internet is shit.

...
wildemagic, geez, I don't even know what to say. It appears that you have no idea what a monumental task it is to provide a complete hardware and software package. Perhaps you should be over at the Lancelot thread, moaning about how it hasn't even been delivered yet?

This hasn't been delivered yet either.
Working and reliable bitstreams happen be be rather important to FPGA mining - bookends and doorstops don't really cut it.
I wouldn't start bringing up some other hardware that ISN'T accepting money yet and complain about them not delivering ...

[Lethos]

Any tips or advice on getting the hardware stable for more than 2 hours plus. It tells me that both of the units have failed.
I'll get an exact copy of the message next time it occurs. At first I figure maybe it was the usb slot was powering down or something.
But it's also happened in under 30minutes of me running it. I've also set all my usb slots to not turn them off to save power early on in testing these.

The com ports are often what disappears from the device manager, at which point I assume that is why they stop working.
Is their anything that that can help force them to stay... hmm maybe I'll go look.

I've solved all the software stability problems just by moving upto to Cgminer 2.5. That is far more stable than previous versions, good work on that Kano and the team (there is more than 1 of you right?)

[Isokivi]

Any tips or advice on getting the hardware stable for more than 2 hours plus. It tells me that both of the units have failed.
I'll get an exact copy of the message next time it occurs. At first I figure maybe it was the usb slot was powering down or something.
But it's also happened in under 30minutes of me running it. I've also set all my usb slots to not turn them off to save power early on in testing these.

The com ports are often what disappears from the device manager, at which point I assume that is why they stop working.
Is their anything that that can help force them to stay... hmm maybe I'll go look.

I've solved all the software stability problems just by moving upto to Cgminer 2.5. That is far more stable than previous versions, good work on that Kano and the team (there is more than 1 of you right?)

No one appears to have a simple works for all solution for this. Basicly we just need to wait till enterpoint rolls out a stable controller. I fiddled with the usb-power saving settings also, but it made no difference. The problem is that the boards randomly dissapear from your device manager and you need to power them off and on (preferrably detatching the usb cable while doing it). You might want to try a different usb-port for the device dissapearing, make note of it the next time it happens. I've been able to get ~20hour sessions this way, but once you get there you might find an issue where one of the boards stops finding shares. Thusfar I have no workaround to that. If your leaving your boards hashing alone for a long time, you can minimize the mining time lost, by running them in separate cgminer instances. so that when one board dissapears, only the cgminer it's on crashes and the other one keeps hashing.

My findings are on 64bit win 7 using enterpoints cgminer, twin_test bitstream and controller version 1.2

[wildemagic]

A tip for stability, make sure you disable the fifo on the fpga com ports, go into your com ports under device manager and select advanced, then disable the 16550 uart.

kind regards

[Slipbye]

After reading some of the comments being bounced around on the last couple pages I thought I had better give a rundown on my own experience. I'm assuming by the number of boards shipped and the number of people posting in the thread that I'm one of many customers who have a batch of boards hashing away with no problems.

When I placed pre-orders for the boards I was under no illusion that they would be anything more than development boards. ie I would have to get them working off my own back, get a bitstream from a 3rd party or pay to have one developed in the short term. As far as I was concerned the boards would be no different than if I sent schematic's over to a pcb manufacturer and asked them to fabricate me the boards.

Have Enterpoint delivered on what they promised when I placed the pre-orders? Absolutely. In fact the boards I have are better than expected and the option that their is a channel for support even though I haven't used it is more than I was expecting at this current point in time.

I currently own 25 boards with that number increasing to a lot more as and when batches of pre-orders get shipped. Every board I currently have are working 100% which for a development board being sold at probably what is around cost price I can't complain at all.

All my boards just work. I've tried various pc's to get a feel for compatibility issues and besides a small issue with x58 boards (was expecting it tbh) I've got no problems.

Cable wise i'm using pre-tested right angle usb cables along with dlink 7 port powered usb hubs.

My first batch of boards have been hashing for over 2 weeks rock solid on the twin test bitstream. They are all showing around u2.62 with confirmation from the pool over this time of around 385Mh/s per board.

I've yet to have a single lockup/crash or any issue. I'm running the original controller software and I haven't updated it yet. I know the new versions fix a few bugs and provide a few new features but I'm a firm believer that if it's not broken don't fk with it so i'll leave my boards hashing at 385 until a 4 core bitstream is released as then the juice will be worth the squeeze as they say.

I'll make another post in the next couple day's when my next batch of boards hopefully arrive and I start fitting them to a rack solution. I'll give a little more of a rundown from unpacking boards to ending up with hashing boards and a few more details on the setup I use.

[Lethos]

So it's mostly luck right now, until a new control can improve stability? However I will try a few different usb settings just in case it helps.
I'm sure others have no problems at all, I seem to have the performance, but not the stability.

Later I will try my Linux rig, in case their is any difference there, it doesn't do much most of the time, so it will be far more dedicated to mining than this windows laptop is.

[Lethos]

A tip for stability, make sure you disable the fifo on the fpga com ports, go into your com ports under device manager and select advanced, then disable the 16550 uart.

kind regards

None of them have this, so not sure why you are advising that.
I know I'm looking in the right place, since my blackberry has it's own com port (tethering it) and it has that option in the advance tab.

These FPGA's have not, instead a whole array of other things. None of which relate to Fifo, or buffers.

I will however try tinkering with the time min read/write timeout function, since it could be triggering too early.