Cairnsmore1 - Quad XC6SLX150 Board

[zefir]

Update: initial statistical evaluation

Having an almost statistically significant amount of units at hand and fought almost two weeks to get the most out of them, I have collected some numbers that might be interesting for you.

Setup details:

• 50 boards, serial numbers 55-100 and 126-129
• all boards SPI programmed to twin_test.bit
• all DIP switches set as documented for twin test mode, plus SW6-1 off for 115kBaud
• powered 7-port USB2.0 hubs
• 1 x Enermax Revo 1.5kW + 2 x CoolerMaster 1.2kW gold PSUs
• programming with xc3sprog natively under Linux
• mining with native cgminer-2.4.4 for Icarus under Linux

What made testing hard for me was the non deterministic failure patterns, i.e. one unit might fail today and work tomorrow or vice versa. After successively narrowing the problematic units out, I classified my batch like follows:

1. OK
Around 23 boards work almost stable, meaning after 24h there are only 2-5 FPGAs that stopped operation, while the other ~40 settle down to a utility of ~2.5/min. This corresponds to ~360MHps / unit, pool is reporting around 8GH for the whole array. Having to power-cycle the whole setup every 24h is far from being maintenance-free, but I get already 20% of the potential total hashing power when the Quads operated as proposed.

2. UNSTABLE
Unstable units are those that

• start to mine at full speed but stop after some hours
• mine with a significantly lower hashing rate: U < 1/min
• start to mine with only one FPGA
• or an arbitrary combination of the named issues

Those devices are the most problematic ones, since you need several rounds to identify an unstable unit. From my batch 15 belong to this category.

3. FAILING
I classify failing units those that are detected but do not mine, including

• those that fail the Icarus detection (i.e. fail to find the golden nonce)
• those that are detected as Icarus but do not generate any valid shares

My batch has 9 of those units, which are easy to identify, since the failure is reproducible, i.e. no matter if you reprogram them before you start or not, they always fail to generate valid shares.

4. BROKEN
Those are the units that either

• are not detected as ttyUSB serial ports
• get disconnected immediately after detection (Linux reports bus errors)
• fail to initialize communication (Linux reports errors setting com parameters or flow control)
• just freeze the system until you pull the plug

I have 3 of those boards that I assume need to be sent back to Enterpoint for repair, since the problem seems to be located at the FTDI side.


Bottom line: your chances to setup your Cairnsmore1 as Icarus and mine continuously are less than 45%. Your odds to have some unstable device are 30% and that device will trick and cheat you until you start to disbelieve in your skills. 18% will find their board not generating valid hashes in Icarus mode (maybe only working in shipping-test mode, not tested). And finally 6% might be the unlucky ones that buy new USB hubs and/or switch between Linux and Windows to just see that the board is not detected and/or makes the system hang.

This is a rough estimate based on my batch, YMMV. The only advice I can give: do not kick the board too hard and don't get frustrated about your skills - chances are 50%+ that yours is not the OK one.


Yohan, your team did a great job, the HW is really top-notch (Swiss made fans, do I need say more? ). But now, priority 1 is to unfold the potential of this piece of HW as soon as possible. While I am glad to see the PDB, stacking kits and up/down links and realize how they will significantly improve the mess I currently have in my setup - more important than that is to see the Quads operating continuously somewhere around 800MHps. I therefore hope that your own bitstream is progressing well and you also consider to support EldenTyrell developing a CM1 TriCore bitstream.


Thanks and good night.

[1714079820]

1714079820

[ebereon]

Well done, thanks for sharing that information zefir.

I can not believe that the differences are so great with 50 boards. Enterpoint stated that the problem is the controller firmware but why these differences?

[Keninishna]

Update: initial statistical evaluation

Having an almost statistically significant amount of units at hand and fought almost two weeks to get the most out of them, I have collected some numbers that might be interesting for you.

....
Thanks and good night.

Crap I hope my 23 boards work when they arrive. On the other hand I'm sure enterpoint will take back the non working boards and send you new ones.

[zefir]

I can not believe that the differences are so great with 50 boards. Enterpoint stated that the problem is the controller firmware but why these differences?

Most probably it is a controller issue, or it could even be on SW side and solvable with cgminer updates.

Since boards were tested in shipping-test mode at Enterpoint before delivery, I should re-program my batch and repeat the test. But since this will eat up one additional weekend, I prefer to wait for a better bitstream (hoping for the next week).

Crap I hope my 23 boards work when they arrive. On the other hand I'm sure enterpoint will take back the non working boards and send you new ones.

I guess only those 3 boards that fail to get detected might need to be RMAd, while all the other should be fixable with new FW. No doubt defunct units will get replaced, like already happened in this thread.

[yohan]

I can not believe that the differences are so great with 50 boards. Enterpoint stated that the problem is the controller firmware but why these differences?

Most probably it is a controller issue, or it could even be on SW side and solvable with cgminer updates.

Since boards were tested in shipping-test mode at Enterpoint before delivery, I should re-program my batch and repeat the test. But since this will eat up one additional weekend, I prefer to wait for a better bitstream (hoping for the next week).

Crap I hope my 23 boards work when they arrive. On the other hand I'm sure enterpoint will take back the non working boards and send you new ones.

I guess only those 3 boards that fail to get detected might need to be RMAd, while all the other should be fixable with new FW. No doubt defunct units will get replaced, like already happened in this thread.

Can you send as much information into the bitcoin support email so that everyone relevant gets to see the problem. Outside what's already been mentioned on the forum, and thanks to all that have already forwarded into our support, we have not had any reports like this come in. So as yet we don't have a big statistical base to work on. We also haven't had a faulty unit arrive back to us yet to analyse. One I think is on it's way. So bear with us for a few days whilst we get enough information to give us a clue where to look. Probably the first thing to do is to try and create a model setup as similar to Zefir's as we can. We do think there is more than one aspect here and elements of software and firmware are probably the main place to look. However we can't rule out a hardware failure so that also needs to be part of the analysis. From what we have seen here on the line USB failures are very low and all down real identifable things like solder shorts.

[Isokivi]

Are you running the correct version of CGminer?

When you flashed the units dip you have the dip switches in the correct position for flashing and then afterwards set them to running position for the twin bitstream?

I tought I was, somewhere along the line I had for some reason started the wrong one... Im running the correct one now, I'll report in when I have enough data, I think around 1000shares per core should be definite ?

And yes I have been playing with the dipswitches in accordance to your pictures.

Ok after 14 hours (a bit less tbh, but it's like 10min) of running 3 boards in the correct cgminer, at a regular pool, with the twin_test bitstream:

The pool side shows my current hashing speed to be: 1146Mhs (This is supposedly a 10 or so minute average), I have accumulated 13151 valid shares and 3 invalids.
Cgminer shows: all cores running and hashing at roughly equal speeds (the slow core was caused by the incorrect miner version) 13300 shares 3 rejected shares.

Could someone smarter than me do the math on 13154 shares in 14 hours: whats the average hashing speed ?

[kano]

shares are 2^32 hashes

13154 shares in 14 hrs is 1121MH/s

However, 14 hours is not long enough to ensure the number of shares is exactly the same as the hash rate.
Maybe give it a few days at least if you want to use the number to be close to correct.
(also you need to measure the time accurately as I'm sure it wasn't exactly 14hrs, and even 1 minute is 0.12%)

[Isokivi]

shares are 2^32 hashes

13154 shares in 14 hrs is 1121MH/s

However, 14 hours is not long enough to ensure the number of shares is exactly the same as the hash rate.
Maybe give it a few days at least if you want to use the number to be close to correct.
(also you need to measure the time accurately as I'm sure it wasn't exactly 14hrs, and even 1 minute is 0.12%)

My intention was to have a look at rough numbers at this point, thank you for the math. Im not that interested at getting an accurate performance figure, while the boards are at best crippled to less than half they should eventually be able to provide.

[yohan]

On a totally different point how are you guys finding the cooling system performance? We are interested in feedback on that as well.

[Isokivi]

I am now testing the bitminter beta java client with all 3 of my boards, with the twin_test bitstream. I made a separate worker for it. Hopefully I'll hav something nice to report later on.

[Isokivi]

I am now testing the bitminter beta java client with all 3 of my boards, with the twin_test bitstream. I made a separate worker for it. Hopefully I'll hav something nice to report later on.

Tons of errors and the test ending in one board dissapearing and requiring a reflash, i dumped the log to drharibo, but I doubt it will be usefull to him before enterpoint rolls out a reliable bitstream.

[ShadesOfMarble]

On a totally different point how are you guys finding the cooling system performance? We are interested in feedback on that as well.

That's hard to tell unless the board is operating at full (or at least high) speed, isn't it?

[Isokivi]

Code:

xc3sprog –c cm1 –p 0 –Ixc6lx150.bit twin_test.bit

does not work, but this time it's complaning about a filename issue to me. My initial hunch is that since the board im punishing is #108 the firmware filename on it has changed along the way. I'll re-read up on this , of how I wsh the search function on this forum worked better .. but for now Im going with the temporary flash.

Strange...
When you type a "ls -l" do you see the files in the directory? And make sure you use the correct filename, the filename in UPPERCASE is XC6LX150.bit, I did a typo the first times, so I used xc61 (number one here! but it is a small "L")...

Here is my directory (ls -l) after copy the files from usb stick:


If you have the same, the commandline should work.

good luck!

[Edit]
Recieved clarification on this, thank you Slipbye ...flashing in progress now
I decided to get back to permanently flashing my boards, my problem appears to be that the file xc6lx150.bit is not there, am I correct in assuming that copying it in there with the usb stick will result in success ?
...and does this mean that the virtual machine requires the bitstream that will be removed as a "reference point" so it can permanentley flash in a new one ?

[Isokivi]

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.

[Doff]

I can not believe that the differences are so great with 50 boards. Enterpoint stated that the problem is the controller firmware but why these differences?

Most probably it is a controller issue, or it could even be on SW side and solvable with cgminer updates.

Since boards were tested in shipping-test mode at Enterpoint before delivery, I should re-program my batch and repeat the test. But since this will eat up one additional weekend, I prefer to wait for a better bitstream (hoping for the next week).

Crap I hope my 23 boards work when they arrive. On the other hand I'm sure enterpoint will take back the non working boards and send you new ones.

I guess only those 3 boards that fail to get detected might need to be RMAd, while all the other should be fixable with new FW. No doubt defunct units will get replaced, like already happened in this thread.

Can you send as much information into the bitcoin support email so that everyone relevant gets to see the problem. Outside what's already been mentioned on the forum, and thanks to all that have already forwarded into our support, we have not had any reports like this come in. So as yet we don't have a big statistical base to work on. We also haven't had a faulty unit arrive back to us yet to analyse. One I think is on it's way. So bear with us for a few days whilst we get enough information to give us a clue where to look. Probably the first thing to do is to try and create a model setup as similar to Zefir's as we can. We do think there is more than one aspect here and elements of software and firmware are probably the main place to look. However we can't rule out a hardware failure so that also needs to be part of the analysis. From what we have seen here on the line USB failures are very low and all down real identifable things like solder shorts.

I'm sending mine back as soon as I can, I just got the email today with the information to get that going. Id love to know what was wrong with it as well, since it will find 1-2 shares then stop hashing altogether. Ive tried everything and reprogrammed it a good 50 times with no luck.

The new one you sent me has been working at 370mhash for the last 3 nights without any problems. Thats running on the latest cgminer in Linux.

Doff

[Isokivi]

After a permanent flas of the twin_test bitstream and plugging all 3 of my boards in to separate usb 3 ports my. Last core on cgminer is slow problem still persists.

[yohan]

One thing we have found is that a small percentage of the USB cables we supply have been faulty and may explain a few of the coms failures. We are changing our testing to include the cable that ships with the unit rather than assuming the externally supplied cable is ok. Some of you may have faulty USB cables and if possible you should try problem units with a different cable.

On USB hubs we just got a few USB hubs for our test setup and also so that we can start to put together a recommended list. Some of the cheaper ones do have an inadequate power supply e.g. 1A for 10 ports. However one that we do have http://www.ebuyer.com/123772-d-link-dub-h7-usb2-0-7-port-hub-dub-h7-b looks very good on paper and I will update you on real use of this particular hub when we do some testing.

[Isokivi]

One thing we have found is that a small percentage of the USB cables we supply have been faulty and may explain a few of the coms failures. We are changing our testing to include the cable that ships with the unit rather than assuming the externally supplied cable is ok. Some of you may have faulty USB cables and if possible you should try problem units with a different cable.

On USB hubs we just got a few USB hubs for our test setup and also so that we can start to put together a recommended list. Some of the cheaper ones do have an inadequate power supply e.g. 1A for 10 ports. However one that we do have http://www.ebuyer.com/123772-d-link-dub-h7-usb2-0-7-port-hub-dub-h7-b looks very good on paper and I will update you on real use of this particular hub when we do some testing.

Thank you on this bit, I will go trough any available cables I have and see if this could be the case for me and my slow-core issue.
[edit]
First results are inconsistent, I dubbed the cables 1,2&3.
1,2&3 plugged has a slow core.
1,2 plugged has a slow core.
1,3 plugged works fine.
2,3 plugged has a slow core.
Adding a random similiar usb cable to the mix (4)
1,3,4 has a slow core.

[Isokivi]

When trying everything I can think of to resolve the slow core issue I've been having it has become almost obvious that Im dealing with a defective unit. Board 62-0158 the second core works over 10x slower that the other one, not reported speed, but shares and rejects.

Things I have done to reach this conclusion are:
Reflashing the bitstream multiple times
Powering off the pc and/or unit
Running the board in a usb2 port, usb3 port and in both ports with an unpowered usb hub.
Setting up a different system for testing (win 7 x64 and windows 95 were used)
Run the boards in separate cgminer instances.

It would appear the problematic core gets more shares when more boards are plugged in, so this might suggest that the cgminer build is reporting shares to incorrect  cores at times.. and if that is the case then I suppose a single core can function alone, like someone asked a few pages back.

[tf101]

Heya,

Just got my board up and running (using the twin_test.bit), on MPBM...

All seems to be working well... on com22 and com23 I have it running at 378/377 MH's respectively.  The blockchain the total avg running at 755 MH's. (running for two and a half hours now).

My pool is only registering about 425HM's... no errors are showing up in the log however... no rejects.. and only 1.16% canceled.

Is this in line with best current performance?

Thanks in advance.