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

I was telling about p2pool stats, not cgminer stats.

cgminer shows me 63-68% efficency when connected to p2pool. I let 5 instances of cgminer running on 2 netbooks.

eb

How did you get such high efficencies? I run 2 CM1 with Mok's 220 bitstream under a win7 OS and I am lucky to get cgminer efficencny upto 60%...can you advise please as you appear to have a VERY BIG BRAIN for this sort of thing...

Well, since I will have far fewer than 50, I won't have your problems.

ty, ebereon.

Not AFAIK. I have tested p2pool with 50 CM1 and i got 0.8-1.2% DOA and an average of 105% Efficiency @ ~40GH . The test time was 18 hours. I will switch to Linux soon, then I will test  p2pool for longer time frame.

My 2 Win7 netbooks can't run p2pool fast enougth with the 50 CM1 connected. Booth have used 30%-70% CPU alone with the interupt handling (COM's/USB). When I run p2pool on them too I have up to 30% DOA.

The test was done with a I7 Worksation (Win7) as p2pool host.

eb

It is known that the BFL Single units don't do well with p2pool.

Do the CM1's have any issues with it?

you said you use the latest makomk bitstream, is it dcmwd4e? With that one the FPGA's shouldn't stop at all, but if it is to fast it will produce invalids and that happens also after some time when the FPGA's getting hot.

My worst FPGA(pair) run the dcmwd4e 200Mh bitstream and have 2-3% invalids and U= 5.3.

eb

I never tried it, but zefir said in the IRC channel:

I don't know if you need a JTAG cable or just the USB. Zefir had a JTAG cable as you see he used the cable option -c pp. Try it with just the USB with option -c cm1. Don't forget the switches and connect only one board to the PC.

eb

If you are having stability and a lot of rejects, I have found hashvoodoo 175 to be really reliable. I am abit jealous of those who can get Mak's 220 to work.

My boards are in transit. So, I'm trying to get everything I can ready to go before they arrive.

Two questions:

1) What version of the controller is installed on the currently shipping boards? 1.5?

2) Is "spiprog", which is constrained to MS Windows, the only way to upgrade the controller?

In other words, am I going to have to dig up some Windows machine in order to upgrade the controller firmware?

You might want to try 1.5. I recently switched from the original controller (1.1 IIRC) to 1.5 and it seems to have solved my FPGA1 problems.
I didn't test 1.3 before 1.5.

Good luck.

To those with bigger brains than me....   

I have 2 *CM1s, in the 400 series range, that have been flashed with makoam's 220 bitstream. Overall the boards have performed very well with rejects being <1%. However....on both boards, FPGA 1, drops from U of ~6 to U ~3.5 and the orange data light becomes constant after a random time frame i.e. 10 minutes > 10hours. I have tried flashing these down to a makoam 210 and even a 200 MHs bitstream with the same results. So what I am asking from the group is, does anyone have further suggestions on how to get these last FPGAs stable at the same U rate as the other FPGAs?

My config is;
Win7
CM1 bitstreams; P0 = 220, P1 = 210, P2 = 220, P3 = 220 for both boards (mokoam latest bitstream)
CM1 controller: factory setting of 1.3
Power: 250W ATX using molar connections from 2 different lines
USB: 2 configurations tried. 1st: Gigabyte extra power USB ports (side by side). 2nd: Gigabyte extra power USB for 1 CM + standard front of case USB for other CM

With the high electricity costs in Australia, 22ckW/hr, I really need these babies going so I can shut down my 6770 arrays.

I shall chuck a sheckle or two of gratitude (0.5~1BTC) towards whom helps me achieve the desired stability.

Regards,

Cranky

thank you for the suggestions. I have now flashed d4e 190@0+1, 180@2+3 to 0017.
I had to restart the board about ten times until I got it running stable with less than 3% invalids. the other times, it had up to 99% invalids or did not pass the golden nonce test. board 0609 does not have these problems when using the same psu, usb cables and hub.

In case anyone was interested
My current cgminer git source has a bunch of changes in it waiting to go into ckolivas git, including a code change for handling HW: errors - which of course means that cgminer will report HW: errors for all devices now by default - including using the Icarus driver being used for CM1

It does still have the HW: error jump bug that I've seen (twice now) and spiccioli had before.
That bug doesn't negatively affect anything in any but a minor way when it happens, and I now have a full debug log showing it - just need to find the time to analyse it and work out the cause.

So other than that, you will now get proper HW: error counts with that version (which will hopefully will be in the next version of cgminer)

Feel free to try it (if you can compile from source) and report any other problems with it.
https://bitcointalksearch.org/topic/m.1158924

My git: https://github.com/kanoi/cgminer

The pull request: https://github.com/ckolivas/cgminer/pull/310
(that is just my master as a pull request to ckolivas)

What I would try to do is flash the 0017 board with the glasswalker 175 bitstream and controller it has a much lower error rate.

It is a false statement. I have zero tolerance for that.

Pleading 'technical difficulty' is insufficient excuse for falsehoods.

I did not order a BFL single until they were not only shipping product, but until the order to shipping lags had dropped to the low 50 days - the trend indicated they were finally catching up on backlog and would be able to meet their commitment on order date, with full payment taken, until ship date. Then they started slipping again on shipments and I eventually got a device in the BFL infamous 'four to six weeks'. (That is, long after their promised delivery by date.)

Enterpoint accepted my email indicating interest in x quantity of their product. They replied saying that I shouldn't expect anything until September, OK? In September I got an email from them stating sufficient quantity is available, time to pay if I still want the stuff. I paid them. They shipped the next day.

That is how to build a good reputation.

@Hm I would recomend on your board 0017 try the d4e bitstream at 190 on FPGA 0+1 and a 180 Bitstream on fpga 2+3, should hopefully knock your invalids down a bit. Worth a try

I don't see this as a credibility problem. I suspect their website makes it difficult to sell a product which is not in stock or available at a given date. To offer pre-orders they probably had to mark them "In Stock".

I changed the psu for #62-0017, but it didn't help.
Stats for #62-0017 and #62-0609 using mpbm and dcmwd4e 200MH/s with controller rev 1.3:



Seems I'll have to once again reflash #62-0017, this time I'll use the non-oc bitstream dcmwd4e 160.

And, again, with some fundamental credibility problems.

From their page:
"Availability:   In Stock"
"boards are projected to ship in November/December of 2012"

We are looking at a pile of technology things that have a chance of being a serious contender and if we really think they are really viable and there is a need for them it will get released as a product in due course. Personally I think if *** comes up with the promised performance then the market will suffer stability issues and I don't think what they are doing is even good for their own customers or Bicoin in general. However that is their choice and I have said before that we don't actually mind competition as long as it is fair and reasonable. We will wait to see what actually happens. What we don't want to do here is add or cause the same instability problems to Bitcoin unless that is strictly necessary. We want to see all our customers have a good experience if that is possible.

Part of what we are doing now is reviewing how the Cairnsmore1 project has done technically and I think we have learned things here doing that project. I don't think it was all technically perfect but given how aggressively we released it into manufacture I am generally pleased with the solution. We are now getting the performance thanks to all the people that have helped on the bitstream and software side to make that work. We did realise at the start this would be our weakest area and part of what we have done in the 4-5 months of the Cairnsmore1 project is strengthen our ability a little in these areas. It's still far from where we want to go but commercial sense limits what we can do in this tight margin market.

Ok I know you are all keen to know about what we might do but firstly the commercial side of this is so sensitive there isn't a chance of us talking about any possibilities in advance in detail. Secondly there is also a much higher technical risk that things don't work so we don't want to announce anything that might not happen. Cairnsmore1's design was kept very simple deliberately so that we could do the promised timescales and that was a very reduced technical risk. Some of what we are looking at now is much more complicated and it could go badly wrong. So whatever we do we won't release any details until literally a product is stockpiling for shipment next time.

I'm sorry i can't tell you all more. Everyone likes to know more to make decisions on but for now everyone just has guess on what might come, or not, from us.