Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 5. (Read 286370 times)

The only red LED that flashes when you plug in the USB cable - i.e not powered. According to Yohan, the bitstream is Hashvoodoo. Unless he means the ones where the amber lights are, which then it wouldn't be hashvoodoo.

Which tells us what?

And, BTW, there are five red LED's on the board.

The red LED on my Cm1's flash continuously.

The easy way to tell generically which of the 2 main bitstream options are loaded is the LEDs next to each FPGA. If the red LED continually flashes you probably have Hashvoodoo and dynamic clocking. Otherwise you probably have Makomk and fixed clocking.

sudo lsusb will tell you.
as will cgminer --usb-list-all -n (note that the parameter order there does matter)
On linux the above two look like:
and

The ID numbers are what I'm referring to

The 0x6014 is what I don't have the full details for yet for Cairnsmore1 but I presume it will be the same as BFL but with a different baud rate.

Is it important for your tests to have product=0x6014 or product=0x8350? I don't know which one I have
but my Cairnsmores are early ones, from summer 2012.

You probably don't have dynamic clocking firmware. With it you would have one device per FPGA hashing around 200MH/s each. You have one per pair of FPGA hashing at ~400MH/s each.
Your hardware errors are a bit on the high side (4% for the worst case) but is not really worrying. Using a slower firmware is nearly always advisable when you have more than 5% hardware errors.
The best results are delivered with the dynamic clocking firmware as it can even adapt to changing conditions leading to less hardware errors (it can use faster clocks if the cooling improves and make some FPGAs more stable because a window was opened for example) but the difference might not be worth the downtime (IIRC you need quite some time flashing both the controller and each of your FPGAs).

To make it short: unless you see less than 400MH/s on average per pair of FPGA over long periods of time or something isn't stable there isn't much of a reason to change firmwares (unless you like to hack around).

I do not know what there the firmware. I bought it for second hand and I have no idea how and what to see

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.

to Luke-Jr

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

Had he not posted that lie:
https://bitcointalksearch.org/topic/m.2262390
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

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

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.

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

Thanks for detailed reply.

Try something like this:
Makes sense?

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

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

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.

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.

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.

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.

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

sigh


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

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