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

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.

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.



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.

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.

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.;
so far (after only 10 mins or so) both pga seem to give the same number of accepted shares;
ill report more when its been running longer.

after 13 hours, not a massive difference from before;

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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

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.

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.

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