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

Final Warning for June Promise Customers

Anyone promised a June delivery should have received an email saying units are available by now. There are a very small number of people that have not responded. Any of these units that are not paid for this week will be removed from our list and new pricing structure will apply on any replacement orders. We are doing this so we can satisfy demand for these boards and allow us to either supply more units to other customers or simply to pull forward orders for other customers.

Anyone on an early to mid July promise should have had notification that units are available. If you have not received notification let us know and/or check your spam box.

Anyone experiencing this error whilst trying to run ebereon's changed MPBM?

I tought I propably should mention that the following usb-hubs havent proven to be a solution to boards dissapearing from the device-manager and thus crashing cgminer:

Unpowered:
Belkin usb 2.0 lighted travel hub, 4 port (F5U034erBLK)
Powered:
Fujitech 4-port active usb hub (ean code 6438148000158) This one wont ever even detect four boards properly and is too light to use for a paperweight.

But it does put me in a nice spot where my RoI is negative after nearly two weeks of mining. Anyone struggling with this issue might want to hold off on buying more accessories that propably will not resolve the issue anyways. I'd love to add something positive, constructing or supportive here, but sadly I dont have shit.

yep

Were those stats over the 11 hours?

I upgraded my board (0005) to the 1.3 controller and programmed the twin bitstream, and it seems to be hashing away stable for the last 11 hours (using the cgminer version found on the Cairnsmore1 support page).

One of the 2 FPGA's does seem to be slower:
CM 0: | 439.6/427.5Mh/s | A:1715 R:9 HW:0 U:2.56/m
CM 1: | 494.6/438.4Mh/s | A:1310 R:8 HW:0 U:1.96/m

I modified again my cairnmore worker for MPBM, please redownload if you use it. I corrected some timings that have to do with restarting worker etc. if a unit doesn't work as it should.

Also a new modification I have done to the Statistics Webpage, I have added a column for "Processed per minute" like you know from cgminer "U:" (Utility defined as the number of shares / minute). Please copy the modified file "statsgadget.js" to the directory "\mpbm\modules\theseven\webui\wwwroot\static\statsgadget\".

Download it here.

Nothing in that price range.

The main power supply is 12V which can be from a range of sources but the controller section can also power from USB.

Rev 1.3 Controller DIP SWitch Usage

Are their any models that are in teh $150-$200 range?

Also I'm confused about the power supplies? Does it require more then one supplies? Can it run on just USB power supply? How about regular power cords in USA?

The only way you could revert was if the SPI Flash had not been programmed and you had live loaded the FPGA directly. What is more likely is that they have gone into the lockup mode I have described elsewhere. Once FPGAs are in that lockup mode we think the only ways back are to either power cycle or do a live configuration. I am hoping to do some work on Rev 1.4 controller today that might partially solve the lockup issue but this unlikely to be a total answer. The proper place to fix this is in the array FPGA design and of course the twin isn't our original design and very hard to fix properly and rebuild. We do have something that is much more robust in our own design and cross fingers once that is available you won't have the issue. Meanwhile I will do my best to provide an improvement on the temporary solution in the Controller design.

On the USB hubs I would either try a switched type like I listed earlier today or go for one with an even higher port current capability i.e. more like 500mA. Also be careful of some hubs that have 1 or 2 permanently powered ports for charging Ipods etc.. These hubs generally are ok but I would avoid the ports on them that don't power down.

SW1/SW6 = yes
SW2/SW3/SW4/SW5 = shipping bitstream (I don't know why, but they came with that from enterpoint, I leaved it)

After one hour the ones I switched back had 5%-8% invalids. All others with <1% still have 200M_beta.bit.

Please take a look in the Icarus thread.  

Allways the latest, 1.3.

I hope you will get also nice results!  

eb

Cutting current draw from the USB when the 12V line is live would definitely be a good thing.  Right now, bad things happen when you exceed the current capacity of the the USB input hubs.  My best guess is that you need >150 mA per port to be safe.  I am supplying my system with 250 mA / port to be safe.

Presently I'm dealing with a very strange issue.  After adding a few boards several of the boards already on the chain seem to have reverted to the ship test bitstream.  In idle and in operation some boards have blue LEDs live 100% of the time, which I have only seen with ship_test.  All boards had the flash programmed to twin_test before being connected.  I have recovered some by reprogramming twin_test again.  But a few board won't take the programming and throw USB errors.

The programming is being done with an independent Win7 x64 system, and I have been able to program other boards without problems.

Hey "this time",

Please make sure you can type "python -h" as a command line. If yes you have to type "python run-mpbm.py" to start MPBM. If not you have to put the installation directory of python in the %PATH% variable and start a new command line window and try again.

I have installed:
- python 2.7.x
- pyserial win32 (additional package)
- pyusb win32 (additional package)
- latest git mpbm (not 0.1.0beta!)

If you need more help just PM me and I can help you also via skype in german

eb

To be honest we have not tried cutting the USB 5V power line yet. or going back to un-powered hubs. Un-powered hubs could still have an issue if the power sequence is done wrongly i.e. before 12V is up and supplying controller power. It would certainly be worth trying with the proviso of powering the 12V first. Yesterday we happened to fit the USB hubs that have a switch and didn't turn on hub is up and stable. 10 more of those hubs arrived this morning and we will build a bigger system as we get more boards off the line to test.

We really started to get some more ideas yesterday as we were starting to get our larger model system together and we did some more sytem level thinking and testing. We had build a 10 boards system about a week ago the boards from that then went to ebereon as tested working boards. his was an additional test over what we did previously but we are now adopting that as standard. That was the previously biggest system we had to play with to see some of these sorts of issues. We think that there are a number of the issues in larger setups that are mainly a mixture of USB and CGminer issues. Like the window size problem we saw yesterday. I wouldn't have thought of that one unless I seen it with my own eyes.

The fact that CGminer isn't capable of coping with losing one processing element is basically crap. We do want to look at that but it's a trade between making forward progress on bitstream and associated items and doing this support work. We only had 1 day in reality this week on the bitstream side so it hasn't gone far this week.We do now have have a rig test that may form a basis for something better and we will probably make that test available to you and other big rig owners for system diagnostics and on-site test.

We going to see if we can also make things better in the controller for power-up and overnight lockups. One of the major issues with the twin bitstream is that if gets any charactors sent to it down the com line it will react. if that is a non-real message or a message is corrupted that usually causes a lockup/non responder. We know this can be an issue if CGminer starts sending coms before the system is ready. Harder to sort is overnight issues and that depends on whether that is the actual problem. It could be a mains power dip upsetting the USB or a coms issue. If it is a coms issue then we almost need to check messages in the controller before passing on to the array and also the other way. One other unlikely possibility and a weakness in the Icarus setup is that the coms of the second chip can interfere with those of the first chip. We don't think that should happen if you have dip switches set right and second FPGA is in reset. Here there is a possibility of simply clearing the config SPI flash of the 2 non-working FPGAs so there is nothing to interfere. Actually that gives me a thought of whether we can remove power from these 2 devices. You do need power for JTAG to work but otherwise it might work. A line parking build might do the same. I'll look at that as an option as it can be done quiclkly.




Often in bus powered systems the drop on the cabling and hubs would make the 12V derived fed win. However a powered hub might make this different. It's good and bad. First because

Yohan, I asked bitcoin.support already about a related issue. Are you saying that cutting the 5V line in the USB cable connecting to the PC and using non-powered USB hubs should then work flawlessly? Currently my biggest problem is that one of the powered USB hubs disconnects in the middle of the night and stopps the whole array from mining, which from the Linux syslog seems to be caused by over-current prevention. You earlier said that as soon as the PSU is powered on, the FTDI is not fed by the USB bus power, AFAIR.

I'm trying to get mpbm working on windows using windows-runtime-v0.1.0beta.zip and I get an error when trying to run mpbm.exe from the command line. I've never used mpbm before so I'm probably making a basic error.

I want to share my experiences of the last two days with my new CM1 boards.

First of all they are working great @ 3900Mh/s. Not as my early board (SN# 15), witch was a pain!

TML Bitstream: Is not working at the moment. I get the same results as I already posted in Ellentyrell's thread.

I'm working unter Win7 32bit.
I started with cgminer, but after 5 hours one board disappeared and some where realy slow U 1.9 and 2.1 and so on. I tried ep cgminer and cgminer 2.4.3.
I see a problem using cgminer with the CM1 board at this stage. It's more incompatible or have an bug or somthing. Also you don't see Invalid Shares witch is bad, you don't know why your FPGA is slow etc.

So I started again with MPBM. Here I can see Invalid Shares, I can Flash the CM1 boards in VM and after I reconnect them to windows, MPBM start hashing on it rigth away without a restart or something.

Then I was trying to get the most out of my Boards. MPBM was running with under 1% Invalid Shares in one hour with the Twin_test.bit Bitstream. I started the VM and flashed ALL Boards to the 200M_beta.bit Icarus Bitstream. Realy nice, after each board was flashed, MPBM started hashing with them without anything to do.

I was waiting again 1 hour to check the Invalid Shares and flashed the FPGAs that had more then 1% back to twin_test.bit.

Here my results:


as you can see only 2 FPGAs with 200M_beta.bit (200Mh/s) have <1% Invalid Shares, the others have the twin_test.bit (190Mh/s).

From 20 FPGAs have 15 200M_beta.bit and only 5 twin_test.bit


I have made also some modifications the my cairnsmore worker for MPBM. I change some settings to meet the CM1 board at this stage. It restarts the worker earlyer when the FPGA have no share summitted in an spezified timeframe. Some wait times have been shorten to make sure an disconnected CM1 board get faster reconnected and so on.

You can download the modified cairnsmore worker here.


One more problem I had was, when I was "searching" the right Com ports for the FPGAs the boards become unresponsive. I think when I started the miner on a Com port related to the Jtag or SPI port, the FTDI chip scrwed up until complette power down. In windows this is a pain with 40 USB devices automaticly creates a Com port XX, so you don't know what it is and you need to test it if it's a FPGA or not. We need here something changed in the driver or what ever.

I hope this helps someone to get the most out of the CM1 board.

Happy mining!
eb


EDIT:
Set the Jobinterval as follows:
twin_test.bit (190Mh/s) = 11.33
200M_beta.bit (200Mh/s) = 10.6

The orange LED's should only "flash" <1 second betwen the jobs!

The board has a common "5V" rail which can be fed from either USB 5V or 5V generated from the 12V. The 2 alternative sources use in-line diodes to avoid back feeding to the other side. Which one supplies the current actually depends on which is the highest voltage. Notionally they are the same voltage but there will nearly always be a difference. Often the USB will often be lower because of cabling loss so the 12V will supply often or even share the load. However this is not guaranteed. If your hub power sits at a slightly higher voltage of course it will try to supply all or some of the current. Actually that might be an interesting thing to try. Running a hub from a bench supply at say 4.8V might allow the onboard 5V derived from 12V to always dominate.

Another way is to modify a USB cable so that 5V isn't supplied (cut the right wire maybe in a USB cable) or is regulated down to say 4.8V by an in line regulator or even a simple diode in-line to provide an extra voltage drop. Knobbling the hub supply voltage down to 4.8V might be somewhat simplier.

At the board level changing the USB side diode to one with a bigger drop would work as well.

There is another USB issue directly related to the Twin (Icarus) build. This design appears lock up if it receives a slightly corrupted message. You might get this if CGminer started sending messages before a FPGA was fully powered and one of the things we are going to try is to block messages in the Controller until we think the FPGA is fully powered and configured. This is why CGminer should not be started too early at the moment but might explain a range of things that people have observed. This won't be a problem in ur own bitstream where messages will be checked by the design before any operating action is taken.

Yohan,

given that  boards can be switched on without any usb cable attached is it possible to have the controller FPGA  not require/take power from usb cable?

spiccioli