Cairnsmore1 - Quad XC6SLX150 Board

[gingernuts]

Does anyone know what would cause all my hashers to drift down to 50% throughput in bfgminer and cgminer after about 10mins? I'm not running a dynamic-clock bit stream, but my boards start off at 380ish per side (virtual Icarus) and pretty quickly move to 200 each, with lots of amber LED time showing they're not doing anything...

If you're running the bitstream that Enterpoint put on the unit at delivery, I'd suggest just use cgminer.
That works fine for me. Since 9 months. Right now I'm using 2.11.3.

I have been running for months too, abd before I added my new boards, it was running flat out - now its as though the pool or the s/w just doesn't know how fast the array is. Is there a parameter I need to tweak somewhere?

[1714016866]

1714016866

[1714016866]

1714016866

[1714016866]

1714016866

[1714016866]

1714016866

[1714016866]

1714016866

[1714016866]

1714016866

[Keninishna]

Does anyone know what would cause all my hashers to drift down to 50% throughput in bfgminer and cgminer after about 10mins? I'm not running a dynamic-clock bit stream, but my boards start off at 380ish per side (virtual Icarus) and pretty quickly move to 200 each, with lots of amber LED time showing they're not doing anything...

If you're running the bitstream that Enterpoint put on the unit at delivery, I'd suggest just use cgminer.
That works fine for me. Since 9 months. Right now I'm using 2.11.3.

I have been running for months too, abd before I added my new boards, it was running flat out - now its as though the pool or the s/w just doesn't know how fast the array is. Is there a parameter I need to tweak somewhere?

If you're connected via getwork and not stratum with a high enough difficulty you're gonna get amber lights and idle fpgas. I use MPBM and set the getwork connections to 10 or more to keep my miners busy although I have 24 boards running.

[kano]

...

I offered! You didn't reply!

A few people offered (though I don't remember yours) and I'm pretty sure I replied to each about waiting for the 1st person to get me info.
It has to be Linux.
gingernuts has now supplied the missing info he thought he couldn't so that answers one question clearly.
Getting there ...

However, if your CMR is FT232H product=0x6014 (gingernuts is product=0x8350) it would be good to provide 2 things:
usbmon (or direct access to it via /sys or /proc or /dev or wherever your Linux OS puts it - yes it must be Linux)
output of plugging it in and also running the usbtest.py that comes with cgminer current git like:
./usbtest.py /dev/ttyUSB? icarus (whatever the USB? is)
and make sure it gave the right answers (or rerun it)
and lsusb -v of the device
If it actually creates multiple /dev/ttyUSB? you'll need to run that whole process on each of them (from plug in to usbtest.py)

Put that somewhere I can download it (PM or posting is too big)

... and I guess this sort of thing points out why I need the hardware ... coz if it doesn't work once I update it to matching the settings people give me, I'll give up
A big part of the motivation for me to get cgminer to work is having the hardware and then of course anyone else can use it too.
I currently have one of each of: Icarus, BFL FPGA Single, ModMinerQuad, Jalapeno, (Black Arrow) Lancelot, Block Erupter USB ... and a 6950 GPU I bought back when I started in bitcoin - I bought 2x6950, the other is on my kids computer playing minecraft
(I also bought a second Icarus that I sold recently)
Looks cool them all running on 1 cgminer

[Luke-Jr]

So to summarize things a bit ... if anyone were to donate a device, there's two people interested:

• a guy who refuses to do anything for the device until it's been given to him, and threatens to remove support at all unless people help him because he's rewriting the code using an inferior interface for no reason (Kano)
• a guy who's actually put effort and hours of time into providing full support for a device he doesn't have, and uses standard interfaces to ensure maximum compatibility (myself)

[kano]

So to summarize things a bit ... if anyone were to donate a device, there's two people interested:

• a guy who refuses to do anything for the device until it's been given to him, and threatens to remove support at all unless people help him because he's rewriting the code using an inferior interface for no reason (Kano)
• a guy who's actually put effort and hours of time into providing full support for a device he doesn't have, and uses standard interfaces to ensure maximum compatibility (myself)

You left out the part where you also intimidate and coerce people into paying you BTC in IRC ...
Or that more than half the Icarus code was written by me and you copied it and claimed it was yours.

Edit: though I should also point out the TYPICAL Luke-Jr lie there.
I wrote the code for the first support for Cairnsmore1 ... yet I still don't have one.
(Yohan had a version of cgminer before me where they only changed the baud but nothing else)

[lostmach]

If it makes you two feel better, I run both cgminer and bfgminer! Thanks for your work... whoever wrote whichever parts. 

cgminer was ok running a 6800 gpu next to a 7900 series
bfgminer out of the box runs the stock cairnsmore

If I had to vote on forum profile pictures alone, the sword is pretty cool.

[lenny_]

kano, can you please tell us  

I offered you Cairnsmore1 access, I can give you ssh or something to debug - you refuse
I gave you 3 patches:

Code:

0003-driver-icarus-add-re-open-device-after-com-errors.patch
0002-api-for-icarus-return-com-port-as-device-ID.patch
0001-driver-icarus-display-com-port-in-statusline.patch

You said not possible to add them, because they not compatible or something - so why they are working for me with cgminer for months?
And finally you didn't even bother to reply to my last two messages  

[kano]

kano, can you please tell us  

I offered you Cairnsmore1 access, I can give you ssh or something to debug - you refuse
I gave you 3 patches:

Code:

0003-driver-icarus-add-re-open-device-after-com-errors.patch
0002-api-for-icarus-return-com-port-as-device-ID.patch
0001-driver-icarus-display-com-port-in-statusline.patch

You said not possible to add them, because they not compatible or something - so why they are working for me with cgminer for months?
And finally you didn't even bother to reply to my last two messages  

I did reply to message 1, message 2 and message 4 of your 4 messages.
Would you like me to post them here? - I don't mind doing that.
I have answered this to you already - your patches are for code that has been removed from cgminer.
(and the ID patch is a bug)

[lenny_]

Thanks for explanation, in your last message you just reply "Those patches are for the serial-USB code that has been removed.".

I am not a developer, I asked you about it, I had to post here to have more info from you, that's really sad. I don't know which patch is not working as it should, but please explain me:
What is stopping us to add re-open device support after error and to show device path next to ICA number?

Question for Cairnsmore1 users:

Code:

 ICA 13: cm1-631-00      |209.8M/210.4Mh/s | A:556 R:1 HW: 1 U: 1.49/m
 ICA 14: cm1-631-01      |209.5M/210.7Mh/s | A:536 R:0 HW: 3 U: 1.44/m
 ICA 15: cm1-631-02      |205.1M/206.1Mh/s | A:537 R:1 HW: 6 U: 1.44/m
 ICA 16: cm1-631-03      |214.9M/215.4Mh/s | A:585 R:0 HW: 1 U: 1.57/m

Tell me guys, would you like to have something like this? Each ICA instantly identified by it's serial number? Well, you can't have it (read above).
Also when you unplug or turn off and on your Cairnsmore1 device, would it be nice if cgminer restart it and keep mining on all Cairnsmore1 boards? Well, it's not compatible!
So why It's working for me? 

[Luke-Jr]

So to summarize things a bit ... if anyone were to donate a device, there's two people interested:

• a guy who refuses to do anything for the device until it's been given to him, and threatens to remove support at all unless people help him because he's rewriting the code using an inferior interface for no reason (Kano)
• a guy who's actually put effort and hours of time into providing full support for a device he doesn't have, and uses standard interfaces to ensure maximum compatibility (myself)

You left out the part where you also intimidate and coerce people into paying you BTC in IRC ...
Or that more than half the Icarus code was written by me and you copied it and claimed it was yours.

Edit: though I should also point out the TYPICAL Luke-Jr lie there.
I wrote the code for the first support for Cairnsmore1 ... yet I still don't have one.
(Yohan had a version of cgminer before me where they only changed the baud but nothing else)

Yeah, you can go ahead and keep on making up lies...

sigh

I offered you Cairnsmore1 access, I can give you ssh or something to debug - you refuse
I gave you 3 patches:

Code:

0003-driver-icarus-add-re-open-device-after-com-errors.patch
0002-api-for-icarus-return-com-port-as-device-ID.patch
0001-driver-icarus-display-com-port-in-statusline.patch

You said not possible to add them, because they not compatible or something - so why they are working for me with cgminer for months?
And finally you didn't even bother to reply to my last two messages 

If you'd like to submit them to BFGMiner (preferrably via a pull request on github), I'd be glad to take a look.

[kano]

So to summarize things a bit ... if anyone were to donate a device, there's two people interested:

• a guy who refuses to do anything for the device until it's been given to him, and threatens to remove support at all unless people help him because he's rewriting the code using an inferior interface for no reason (Kano)
• a guy who's actually put effort and hours of time into providing full support for a device he doesn't have, and uses standard interfaces to ensure maximum compatibility (myself)

You left out the part where you also intimidate and coerce people into paying you BTC in IRC ...
Or that more than half the Icarus code was written by me and you copied it and claimed it was yours.

Edit: though I should also point out the TYPICAL Luke-Jr lie there.
I wrote the code for the first support for Cairnsmore1 ... yet I still don't have one.
(Yohan had a version of cgminer before me where they only changed the baud but nothing else)

Yeah, you can go ahead and keep on making up lies...

sigh

Lying piece of shit

Here's my first commits (in both gits) of code to support Cairnsmore1: 1-Aug-2012
https://github.com/ckolivas/cgminer/commit/e067be421aa43558504c1b6198f4134d6bcb9e09
https://github.com/luke-jr/bfgminer/commit/e067be421aa43558504c1b6198f4134d6bcb9e09

Show me your Cairnsmore1 commits before that first code I wrote to support it.

[kano]

Thanks for explanation, in your last message you just reply "Those patches are for the serial-USB code that has been removed.".

Yes correct I answered your last message with that.
If you didn't understand it - then ask again.

I am not a developer, I asked you about it, I had to post here to have more info from you, that's really sad.

Or you could have asked me to explain it.
Now you are just being annoying.

I don't know which patch is not working as it should, but please explain me:

The programmer has named 2 fields with the same name "ID" ... that's a bug.
As for adding an extra field for every device that exists into the main report of the API devs - that wont happen.
There is a secondary place that could be added correctly called devdetails
The guy who wrote it clearly did not understand the distinction between the two.

What is stopping us to add re-open device support after error and to show device path next to ICA number?

Because the new cgminer code doesn't even have an "fd" to close or open.
The new cgminer code will automatically see the device when you switch it back on - that's called hotplug.
However, the chances of a Cairnsmore1 being supported in the new version are falling dramatically with this crap I'm getting here from the two of you.
It is already delaying the release of the new automatic and hotplug support of Icarus, Lancelot and Asicminer Block Erupter USB.

Question for Cairnsmore1 users:

Code:

 ICA 13: cm1-631-00      |209.8M/210.4Mh/s | A:556 R:1 HW: 1 U: 1.49/m
 ICA 14: cm1-631-01      |209.5M/210.7Mh/s | A:536 R:0 HW: 3 U: 1.44/m
 ICA 15: cm1-631-02      |205.1M/206.1Mh/s | A:537 R:1 HW: 6 U: 1.44/m
 ICA 16: cm1-631-03      |214.9M/215.4Mh/s | A:585 R:0 HW: 1 U: 1.57/m

Tell me guys, would you like to have something like this? Each ICA instantly identified by it's serial number? Well, you can't have it (read above).
Also when you unplug or turn off and on your Cairnsmore1 device, would it be nice if cgminer restart it and keep mining on all Cairnsmore1 boards? Well, it's not compatible!
So why It's working for me? 

Now you see why I would prefer to ignore you than the hour or so of time I've wasted now with you, given that reply.
Yes it's not compatible coz it's not even needed.

As for your screen display, if I did do the frequency change coz I got a Cairnsmore1, where would that be displayed?

There is already a need for unique identifying information to be stored in cgminer once I sort out a tidy way of reviving ZOMBIE devices rather than just adding them on as a new device.
It is only a display issue though so it doesn't have much priority.
The unique information will be displayed in devdetails as I have planned for it to be since I first wrote hotplug.

[lenny_]

Thanks for detailed reply.

As for your screen display, if I did do the frequency change coz I got a Cairnsmore1, where would that be displayed? Tongue

Try something like this:

Code:

ECM-631-03   | 215MHz    |214.9M/215.4Mh/s | A:585 R:0 HW: 1 U: 1.57/m

Makes sense?

[zefir]

The programmer has named 2 fields with the same name "ID" ... that's a bug.
As for adding an extra field for every device that exists into the main report of the API devs - that wont happen.
There is a secondary place that could be added correctly called devdetails
The guy who wrote it clearly did not understand the distinction between the two.
[...]

Kano,

I don't mind if you disclose me as the author of those patches at hand. I want to provide the relevant background information to resolve the case.

The most relevant factors to consider are a) the modification are very specific for a very specific setup, and b) were never developed to get integrated upstream.

cgminer supports CM1 out of the box and those having one or two boards are very happy mining with it. Especially the early boards have the habit to pass out (i.e. are not accessible from host any more) and need to perform a power-cycle to make it accessible again. With two boards it is easy: you turn off-on the PSU and restart cgminer. If you start operating more of them (say 20+ FPGAs), you face two main problems: a) you want to identify the problematic board, and b) you don't want to restart all your boards because one of them hangs.

Identification of boards goes over a separate udev module (that is not included in the patches) with rules to create symbolic links to the FPGAs named after the serial number Enterpoint gave them (and visible on the board). This requires the operator to first write a lookup table between FTDI serial and board serial, so it is limited to Linux and meant for developers and hackers. On success, each CM1 is opened over a ttyUSB symlink named after board-serial and port to give you an immediate feedback which boards perform well and which not. I am pretty sure that with using the libusb the lookup table could be integrated in cgminer directly, but at that times this was the easiest approach.

If in such setup over night one board passed out, you know it directly (aargh, 055 again), in standard cgminer it is marked as defect and power cycling this single board won't bring it back to operation. My one patch handles this by remaining in the function where serial-read failed, trying to re-open the device continuously. I know, polling is soo outdated, but it does a very good job in this case.

Same goes for the displaying tweaks: I do not write "ID" twice, I overwrite it with the serial-number (that's according to JSON). I know and fully understand that the ID is meant as enumerator and might break other applications using the API. But since miner.php in my setup is the only one that will ever use the API and "ID" there is only used to be displayed, my approach is minimal-invasive and working.

Since their limited usability for typical miners and a potential high effort to prepare them for upstreaming (if ever possible), I instead provided those patches to the folks I know having lots of boards. Though not sure if the were ever tried (lenny_ did, because he bought my boards with fully operational SW setup).

tl;dr: those patches discussed are not meant to go upstream.


Kano, one personal and OT thing: I followed cgminer development from the beginning and even made it to add some code cleanup upstream. I planned to remain contributing, but when you and Luke started your fight, it went all downhill. It was fun to follow the first battles, but after a while it became just annoying. There is no beauty contest out there and noone needs to prove he is the greatest and has the biggest one. Those who care can check the commit log and get evidence on who did what.


Cheers,
zefir

[kano]

...
Kano, one personal and OT thing: I followed cgminer development from the beginning and even made it to add some code cleanup upstream. I planned to remain contributing, but when you and Luke started your fight, it went all downhill. It was fun to follow the first battles, but after a while it became just annoying. There is no beauty contest out there and noone needs to prove he is the greatest and has the biggest one. Those who care can check the commit log and get evidence on who did what.


Cheers,
zefir

Firstly I didn't even remember who wrote the code
It's simply that for the serial stuff, not relevant any more.
The "ID" belongs in devdetails.

Yes I piss people off - and I'm not concerned to avoid it.
I don't believe the adage "The customer is always right"
More so, my version of "Don't burn your bridges before you've crossed them" is "Nuke them before you even get there"
(I'd imagine the Avalon melodrama should have made that clear)

However, when Luke-Jr posts a lie about me in this thread in an attempt to gain a Cairnsmore1 board and discount me with that lie, I can see no reason why responding to that is problematic.
Most people wouldn't even know that commit that I wrote to start the Cairnsmore1 support.
I'm not in a beauty contest.
You will find that I don't lie in my posts or if something is incorrect then that will be by mistake and I will admit the mistake if it is.
Few people on this board do that.

I have however made a very rare couple of outrageous claims about Luke-Jr after he has posted a lie about me or cgminer - in an attempt to get back at him.
The main issue is how regularly he does post lies about me and cgminer - if you searched the forum you would find literally many dozens of them.

[glowkeeper]

However, when Luke-Jr posts a lie about me in this thread in an attempt to gain a Cairnsmore1 board and discount me with that lie, I can see no reason why responding to that is problematic.
Most people wouldn't even know that commit that I wrote to start the Cairnsmore1 support.
I'm not in a beauty contest.
You will find that I don't lie in my posts or if something is incorrect then that will be by mistake and I will admit the mistake if it is.
Few people on this board do that.

I have however made a very rare couple of outrageous claims about Luke-Jr after he has posted a lie about me or cgminer - in an attempt to get back at him.
The main issue is how regularly he does post lies about me and cgminer - if you searched the forum you would find literally many dozens of them.

To save the rest of us the details; which are really getting quite boring, would it help you and Luke vent your frustrations if we organised 3 x 3 minute rounds of Muay Thai? 'cause it's really getting very very tiresome....

[kano]

However, when Luke-Jr posts a lie about me in this thread in an attempt to gain a Cairnsmore1 board and discount me with that lie, I can see no reason why responding to that is problematic.
Most people wouldn't even know that commit that I wrote to start the Cairnsmore1 support.
I'm not in a beauty contest.
You will find that I don't lie in my posts or if something is incorrect then that will be by mistake and I will admit the mistake if it is.
Few people on this board do that.

I have however made a very rare couple of outrageous claims about Luke-Jr after he has posted a lie about me or cgminer - in an attempt to get back at him.
The main issue is how regularly he does post lies about me and cgminer - if you searched the forum you would find literally many dozens of them.

To save the rest of us the details; which are really getting quite boring, would it help you and Luke vent your frustrations if we organised 3 x 3 minute rounds of Muay Thai? 'cause it's really getting very very tiresome....

Had he not posted that lie:
https://bitcointalk.org/index.php?topic=78239.msg2262390#msg2262390
This would not have happened.
Sorry I don't take kindly to people lying about me on the forum and I'll post proof (as I have done) that it is a lie.

The post replies to lenny_ are replies to his questions - so ... I presume you're not expecting me to not reply?

Aside
Before I went to BFL, Josh suggested he get Luke-Jr there at the same time as me and have a pay-per-view DeathMatch.
Sounded cool

[glowkeeper]

... I presume you're not expecting me to not reply?

Urghhh. Double negatives; it's way beyond my little mind to understand the meaning of that sentence. I hope your code's clearer!

[silverston]

Greetings to all.
 just bought a pair of boards, working with BFGMiner fine, but a I have lot of HW errors. It is normal or something to be done?

Can you post the stat line? Does it report adjusting the clock speed down?

to Luke-Jr

[Luke-Jr]

Greetings to all.
 just bought a pair of boards, working with BFGMiner fine, but a I have lot of HW errors. It is normal or something to be done?

Can you post the stat line? Does it report adjusting the clock speed down?

to Luke-Jr

Hw error rate here doesn't look too bad - if it's with a dynamic clocking firmware, I'd expect it would have downclocked a bit.