Cairnsmore1 - Quad XC6SLX150 Board

[spiccioli]

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.

Yes, each FPGA mines at 190MH/s when using twin_test.bit and you're using just two of the four FPGAs on your board.

Mpbm and cgminer report twice the real speed when used with default parameters.

You can use --icarus-timing parameter on cgminer and/or ebereon cairnsmore worker for Mpbm to have a more precise reported speed, see messages in this thread starting from a couple of weeks ago.

spiccioli.

[1714218179]

1714218179

[1714218179]

1714218179

[1714218179]

1714218179

[1714218179]

1714218179

[1714218179]

1714218179

[yohan]

An update (Rev 1.2) to the controller is available on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. I would not update your board to this unless you have a unit that is underperforming with the twin bitstream. As with all controller updates please be careful that you understand the instructions (Rev 1.1 update) fully before starting and ensure that your power is unlikely to be interrupted. If a controller update goes wrong it is likely that a programming cable will be necessary to perform a unit recovery but do take note of the first line recovery method if first attempt goes wrong another go is possible if unit remains powered.

We will do some more testing and work on the controller this week and there may be further updates.

Whatever revision 1.2+ we reach in the next few days will remain available to support 3rd party bitstream providers longterm but is then likely to be frozen when our own original bitstream becomes available. At this point the controller get a major update to Rev 2.0 signifying the major changes in functionality and all development will be on this branch.

[Chefnet]

your vm show me only 3 units not 4 when I do: xc3sprog –c cm1 –j

[zefir]

An update (Rev 1.2) to the controller is available on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. I would not update your board to this unless you have a unit that is underperforming with the twin bitstream. As with all controller updates please be careful that you understand the instructions (Rev 1.1 update) fully before starting and ensure that your power is unlikely to be interrupted. If a controller update goes wrong it is likely that a programming cable will be necessary to perform a unit recovery but do take note of the first line recovery method if first attempt goes wrong another go is possible if unit remains powered.

We will do some more testing and work on the controller this week and there may be further updates.

Whatever revision 1.2+ we reach in the next few days will remain available to support 3rd party bitstream providers longterm but is then likely to be frozen when our own original bitstream becomes available. At this point the controller get a major update to Rev 2.0 signifying the major changes in functionality and all development will be on this branch.

Yohan,

could you maybe provide some information about the changes this controller update contains? When you say it is for the underperforming devices, does this include those that do not generate valid shares at all and/or those failing the golden nonce test?

I'd need to setup a Windows machine (VM is too unstable for that) for programming the controller and I'd at least need to know that it has some potential improvement for the failures I see most.


Thanks, Zefir

[daemonic]

Ive flashed the 1.2 controller update and things seem a bit better for me so far, previously i was seeing the second pga only producing 50% accepted shares compared the first pga, tested over multiple 12/24/48 hour runs, i.e.;

Code:

 ICA 0:                | 351.2/360.4Mh/s | A:1311 R:1 HW:0 U:1.49/m
 ICA 1:                | 352.0/359.3Mh/s | A: 635 R:0 HW:0 U:0.72/m

so far (after only 10 mins or so) both pga seem to give the same number of accepted shares;

Code:

 ICA 0:                | 321.0/355.5Mh/s | A:20 R:0 HW:0 U: 1.62/m
 ICA 1:                | 316.0/359.7Mh/s | A:22 R:0 HW:0 U: 1.80/m

ill report more when its been running longer.

after 13 hours, not a massive difference from before;

Code:

 ICA 0:                | 379.7/372.4Mh/s | A:1476 R:3 HW:0 U: 1.89/m
 ICA 1:                | 379.6/372.8Mh/s | A: 967 R:2 HW:0 U: 1.24/m

[Doff]

An update (Rev 1.2) to the controller is available on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. I would not update your board to this unless you have a unit that is underperforming with the twin bitstream. As with all controller updates please be careful that you understand the instructions (Rev 1.1 update) fully before starting and ensure that your power is unlikely to be interrupted. If a controller update goes wrong it is likely that a programming cable will be necessary to perform a unit recovery but do take note of the first line recovery method if first attempt goes wrong another go is possible if unit remains powered.

We will do some more testing and work on the controller this week and there may be further updates.

Whatever revision 1.2+ we reach in the next few days will remain available to support 3rd party bitstream providers longterm but is then likely to be frozen when our own original bitstream becomes available. At this point the controller get a major update to Rev 2.0 signifying the major changes in functionality and all development will be on this branch.

Can you clarify the directions on the loader.pdf for the controller switch positions when programming the controller?  I can clearly see SW1, and SW6 Directions however, I just assumed that SW 2, 3, 4, and 5 were all off., is that correct?

I tried the update on the broken board but same results with it not being able to mine.

[yohan]

Yohan,

could you maybe provide some information about the changes this controller update contains? When you say it is for the underperforming devices, does this include those that do not generate valid shares at all and/or those failing the golden nonce test?

I'd need to setup a Windows machine (VM is too unstable for that) for programming the controller and I'd at least need to know that it has some potential improvement for the failures I see most.


Thanks, Zefir

Ok we don't know if this will fully fixes all problems because as yet we don't setups here that show the same problems some of you have and that is why we need work on each problem individually. We do need each board that you have a problem with to be reported to the bitcoin support email with the full circumstances. Not everyone on the team has the time to wade through the forum and they don't unless they stop work on new features or support work so that means problems can be missed. I will try to patch the gaps but I also have a limit in what I can find time to do. It's much better if the information arrives at the correct place and several people get to see it. It also acts as a log we can go back through then also.

Ok what we do know is that this build appears to improve the clocking at 100MHz i.e. that used for the Twin build. We do have some more tests to check this out and that is why it is beta. What we don't know is whether the clocking is the problem failure of the golden nonce test. I wasn't aware of that issue and that is much more likely to be a setup, software or firmware issue. We think that the FPGA DCMs lose lock sometimes and we already have fixes for this also in the working FPGA end which will be available in our own bitstream design that we can't do to the Twin which basically isn't our design.

We also think a few rigs may be suffering from power surge issues particularly at start up. This a problem in several parts including the host power supply quality, wiring quality, and even the Cairnsmore1 itself. This might explain some of the USBs not enumerating but there are also other possibilities for that including faulty USB cables that we did have a few problem ones of. Rev 1.2 has power startup sequencing so that we power each of the 4 power sections in a sequence over 4 seconds and that switch on sequence will be very obvious when you power the boards. This softens the surge on the board and we will extend this rig wide when the up/down becomes functional. One the things that is different with Cairnsmore1 is that there are several large rigs using Cairnsmore1 the size of which have not been seen before in Bitcoin mining. These bring new design challenges in things like power and cooling and we have designed Cairnsmore1 to cope with these extra challenges. Cairnsmore2 when we do that will take the concept to a much bigger level again.

We have also phased on board clocks in the new controller build to reduce "beat" cycles on the power supply. Every FPGA doing exactly the same thing at the same time is a very good way to cause beat surges on the PSU so if we can move those slightly apart then that is good thing to do and make life easier for the power supply.

Can you clarify the directions on the loader.pdf for the controller switch positions when programming the controller?  I can clearly see SW1, and SW6 Directions however, I just assumed that SW 2, 3, 4, and 5 were all off., is that correct?

I tried the update on the broken board but same results with it not being able to mine.

Wrong For the Controller I don't thing you need to change dip switches from normal settings but I will check that.

Look in document xc3s50an_loader_v1.1.bit that is in the zip for the 1.1 update for the dip switch settings.

[yohan]

USB Problem

We have found a bug in the FTDI drivers/CGminer used with/for the Twin bitstream. At the moment we know this is an issue in Windows7 64bit but may extend to other OS versions or even Linux. Basically we are seeing some COM ports "lost" when the host plugs and plays a new device. That can be any device e.g. memory stick. We are looking at this to determine the cause and potential fixes.

[DiabloD3]

USB Problem

We have found a bug in the FTDI drivers/CGminer used with/for the Twin bitstream. At the moment we know this is an issue in Windows7 64bit but may extend to other OS versions or even Linux. Basically we are seeing some COM ports "lost" when the host plugs and plays a new device. That can be any device e.g. memory stick. We are looking at this to determine the cause and potential fixes.

That WOULD explain a lot of problems.

[Isokivi]

If anything (and it's propably too early to say) the update made my slow-cored unit worse. As I am typing this in CM0 has 44 shares and CM1 has 2, neither shows rejects. The core used to be able to push out roughly one tenth of the first cores shares. But like I said it's too early to say, I will fill in more credible numbers in some hours.
[edit]
453/16 shares 1/0 rejects, no hardware errors.
1000/35 shares 2/0 rejects, no harware errors.
So in my case this made no difference whatsoever.
[edit2]
2485/77 shares 4/0 rejects, no harware errors.
... and now on to the interesting part, I will now chuck all the boards to work in the same Cgminer instance, to demonstrate how the slow core will start producing more shares, or as I believe it to be CGminer reporting shares to wrong cores.

[Doff]

Yohan,

could you maybe provide some information about the changes this controller update contains? When you say it is for the underperforming devices, does this include those that do not generate valid shares at all and/or those failing the golden nonce test?

I'd need to setup a Windows machine (VM is too unstable for that) for programming the controller and I'd at least need to know that it has some potential improvement for the failures I see most.


Thanks, Zefir

Ok we don't know if this will fully fixes all problems because as yet we don't setups here that show the same problems some of you have and that is why we need work on each problem individually. We do need each board that you have a problem with to be reported to the bitcoin support email with the full circumstances. Not everyone on the team has the time to wade through the forum and they don't unless they stop work on new features or support work so that means problems can be missed. I will try to patch the gaps but I also have a limit in what I can find time to do. It's much better if the information arrives at the correct place and several people get to see it. It also acts as a log we can go back through then also.

Ok what we do know is that this build appears to improve the clocking at 100MHz i.e. that used for the Twin build. We do have some more tests to check this out and that is why it is beta. What we don't know is whether the clocking is the problem failure of the golden nonce test. I wasn't aware of that issue and that is much more likely to be a setup, software or firmware issue. We think that the FPGA DCMs lose lock sometimes and we already have fixes for this also in the working FPGA end which will be available in our own bitstream design that we can't do to the Twin which basically isn't our design.

We also think a few rigs may be suffering from power surge issues particularly at start up. This a problem in several parts including the host power supply quality, wiring quality, and even the Cairnsmore1 itself. This might explain some of the USBs not enumerating but there are also other possibilities for that including faulty USB cables that we did have a few problem ones of. Rev 1.2 has power startup sequencing so that we power each of the 4 power sections in a sequence over 4 seconds and that switch on sequence will be very obvious when you power the boards. This softens the surge on the board and we will extend this rig wide when the up/down becomes functional. One the things that is different with Cairnsmore1 is that there are several large rigs using Cairnsmore1 the size of which have not been seen before in Bitcoin mining. These bring new design challenges in things like power and cooling and we have designed Cairnsmore1 to cope with these extra challenges. Cairnsmore2 when we do that will take the concept to a much bigger level again.

We have also phased on board clocks in the new controller build to reduce "beat" cycles on the power supply. Every FPGA doing exactly the same thing at the same time is a very good way to cause beat surges on the PSU so if we can move those slightly apart then that is good thing to do and make life easier for the power supply.

Can you clarify the directions on the loader.pdf for the controller switch positions when programming the controller?  I can clearly see SW1, and SW6 Directions however, I just assumed that SW 2, 3, 4, and 5 were all off., is that correct?

I tried the update on the broken board but same results with it not being able to mine.

Wrong For the Controller I don't thing you need to change dip switches from normal settings but I will check that.

Look in document xc3s50an_loader_v1.1.bit that is in the zip for the 1.1 update for the dip switch settings.

Ok, now I'm even more confused, that's exactly where I got the info from. The problem with the loader PDF document in that zip is it doesn't show you what SW  2, 3, 4, and 5 are supposed to be set to, so I assumed they should all be off. Maybe that's why I never got the last one working.

Can you look at that document and make give me the exact switch settings for the controller update? Id like to try one more time on the broken board. I'm going to drop it off for shipment back to you guys tomorrow as well.

Also I'm using Linux currently and the new board you sent seems to be working great with the FTDI drivers and Cgminer 2.4.3 without any modifications.

Thanks,

Doff

[yohan]

[/quote]

Ok, now I'm even more confused, that's exactly where I got the info from. The problem with the loader PDF document in that zip is it doesn't show you what SW  2, 3, 4, and 5 are supposed to be set to, so I assumed they should all be off. Maybe that's why I never got the last one working.

Can you look at that document and make give me the exact switch settings for the controller update? Id like to try one more time on the broken board. I'm going to drop it off for shipment back to you guys tomorrow as well.

Also I'm using Linux currently and the new board you sent seems to be working great with the FTDI drivers and Cgminer 2.4.3 without any modifications.

Thanks,

Doff
[/quote]

Ok I will try and rework the document to make this clearer. Meanwhile have a look at the pictures on http://www.enterpoint.co.uk/cairnsmore/cairnsmore1_support_materials.html. The dip switch numbers have been made bigger and clearer on these.

[Isokivi]

Ok, now I'm even more confused, that's exactly where I got the info from. The problem with the loader PDF document in that zip is it doesn't show you what SW  2, 3, 4, and 5 are supposed to be set to, so I assumed they should all be off. Maybe that's why I never got the last one working.

Can you look at that document and make give me the exact switch settings for the controller update? Id like to try one more time on the broken board. I'm going to drop it off for shipment back to you guys tomorrow as well.

Also I'm using Linux currently and the new board you sent seems to be working great with the FTDI drivers and Cgminer 2.4.3 without any modifications.

Thanks,

Doff

I programmed mine using the dipswich setting for twin_test stream operating mode, with the exception of turning the dipswiches in the picture, like they are in the picture. Everything appeared to go well, the programming finished without errors and the board is no worse than it was before.

[misternoodle]

I made a change to my USB port in Windows and disabled any power savings.  Each core is still up and running and has not powered off yet, they have submitted about 4500 shares each.  It used to crap out around 1100 shares each core. 

[yohan]

Round up for today was that we day excellent results with the Rev 1.2 Controller at several different levels including the best utility factor we have see with the twin bitstream. Absolutely no adverse effects have been seen with the new controller either and we will start using this on the line from tomorrow for boards going through the final assembly/test line.

We will continue to look at the other driver/CGminer issues and updates on those as we find out more.

[wildemagic]

Whats the progress on the bitstream yohan ?

kind regards

[Keninishna]

Also yohan can you please fill out the TML BDK? http://www.tricone-mining.com/bdk.html as ET will not implement native usb support without one filled out.

[Isokivi]

Also yohan can you please fill out the TML BDK? http://www.tricone-mining.com/bdk.html as ET will not implement native usb support without one filled out.

+3!
This should of have been done forever ago. No matter how much enterpoint considers it a distraction from their own bitstream which has been "a few days away" since god knows when, may 27th ?

[wildemagic]

"a few days away"

Indeed, its becoming a bit suspicious now ...  even a low speed quad stream would be good ...

[yohan]

"a few days away"

Indeed, its becoming a bit suspicious now ...  even a low speed quad stream would be good ...

I DON'T THINK YOU ARE NOT EVEN A CUSTOMER SO WHY ARE YOU COMPLAINING. YOU WERE ONE OF THE TINY FEW THAT JUMPED SHIP ON ***S ANNOUNCEMENT.

To put matters straight we did not say we would start our own bitstream development at the beginning of this process and indeed people we talked to privately we told them we would have very little resources for this in May and only a little in June. I think I said quite a lot of this in this forum as well. We have more or less kept to that schedule and we have only really had a reasonable resourcing on this for 2-3 weeks now. Ok we made a small mistake on the wiring to the second chip and the original plan of dropping in an Icarus bitstream initially into all positions didn't quite work and that was our mistake. However it was a reasonable engineering decision to fix this with our own bitstream as the fastest way to sort the issue. The Icarus bitstream was only ever a temporary solution and I think that was made clear.

I have also said that for bitstream development it isn't easy to put a precise time on and yes I might have said a few days and maybe I should have said a few weeks. This isn't a process we can do a percentage complete number on with any accuracy. Unlike a lot of FPGA things we do this function with either work or it won't there is no partial working stage to give a measure on and it will simply be working one morning when I get in the office. Do remember too it is only 10 weeks and 4 days since we announced the concept and we probably have the best FPGA hardware platform designed but have manufactured and delivered hundreds of them to customers in that timeframe. I don't want to hark on about that but most professional engineers in the electronics business would either say that was either impossible or very unlikely that it could be done.

As to ET's bitstream that has barely been working for more than a handful of days on one of Ztex's boards and has had a pile of problems on there over those days. We are watching how this develops and I am sure he will sort out the issues. We could sink our entire resource into supporting that now but it's no guarantee that it will work any quicker and if it did his server might well collapse under the weight of Cairnsmore1s trying to use the server services. That would also bring our own develop to a complete halt which would not be good and we have a pile of customers that simply don't want to be forced down that route. So this is something we have to balance our time on. When the ET solution is slightly more stable will be the time to some work.

Also as far as I understand ETs solution can't support multiple units working together as yet. We don't have any problems with customers using this bitstream as such and we will do our best to support it. We do believe we have the best chance of any of the FPGA boards of being able to support that bitstream given our power and cooling systems but right now it looks like a pile of development work and server hardware to install before it is actually a viable solution. I will have a look at what he needs once I find a utility to open a jar file and see if we can do anything quickly. If it is days of work then it won't happen this week for an unstable solution the time is better spent stabilising our own product and we have made good progress this week already with the new controller update.