Cairnsmore1 - Quad XC6SLX150 Board - page 72.

Hpman

full member

Activity: 176

Merit: 100

Quote from: Isokivi on July 05, 2012, 12:02:22 PM

Reflashing does not appear to of have worked, neither has moving the board to it's own usb3-port. Im starting to wonder if I have a defective one. it's pushing one tenth of the shares of the other cores atm. When tested individually at a regular pool after the re-flash it kept jammering about the pool not providing work fast enough (my gpu miners report nothing of such at the same time at the same pool). On p2pool it appeared to work for some reason, so Im guessing the rapid longpolls have something to do with this. The board reported in at 365MH/s on the 10 minute mark at p2pool.

I am now going to double check this by pointing all 3 boards to p2pool in the same worker... and if that reveals nothing then Im propably going to see how they behave in induvidual cgminer instances, does anyone have experience of running multiple cgminer copy's on the same system ?

Under Ubuntu im using different instances of cgminer, one for GPU and one for the cairnmore without problems.

Hpman

Isokivi

hero member

Activity: 910

Merit: 1000

Items flashing here available at btctrinkets.com

Quote from: Hpman on July 05, 2012, 11:48:26 AM

Quote from: Isokivi on July 05, 2012, 10:12:37 AM

That thing is so sexy, you could still consider adding leds to the support structures, blinking at shares found so it'll cause epileptic seizures.

Did reprogramming p 0 or p 3 target solve the issue with your cairnsmore which hashs on different speed on the two serial ports ?

If you can confirm this then it looks that the twin_test bitstreams doesn't need another core.

Reflashing does not appear to of have worked, neither has moving the board to it's own usb3-port. Im starting to wonder if I have a defective one. it's pushing one tenth of the shares of the other cores atm. When tested individually at a regular pool after the re-flash it kept jammering about the pool not providing work fast enough (my gpu miners report nothing of such at the same time at the same pool). On p2pool it appeared to work for some reason, so Im guessing the rapid longpolls have something to do with this. The board reported in at 365MH/s on the 10 minute mark at p2pool.

I am now going to double check this by pointing all 3 boards to p2pool in the same worker... and if that reveals nothing then Im propably going to see how they behave in induvidual cgminer instances, does anyone have experience of running multiple cgminer copy's on the same system ?

Hpman

full member

Activity: 176

Merit: 100

Quote from: Isokivi on July 05, 2012, 10:12:37 AM

That thing is so sexy, you could still consider adding leds to the support structures, blinking at shares found so it'll cause epileptic seizures.

Did reprogramming p 0 or p 3 target solve the issue with your cairnsmore which hashs on different speed on the two serial ports ?

If you can confirm this then it looks that the twin_test bitstreams doesn't need another core.

My hashing result over last 3 hours shows more than 355 Mh/s on 2 FPGA cores, if we could use 4 cores we are near the 800 Mh/s target. I understood why icarus fails with the wrong TX/RX connection (between P3 and P2?) but if twin_test works as standalone core there is only a stable clock and the rx/tx to the array controller / FDTI required??

Quote from: Keninishna on July 05, 2012, 03:00:58 AM

would someone with a jtag cable mind giving the new TML bitstream a whirl? it has unconfirmed support for cairnsmore1. http://www.tricone-mining.com/tml.html

The big question is if we really need a jtag? If we flash the bitstream with xc3sprog , it doesn't need to reprogram it via JTAG like the ztex board required on every power cycle? I guess after programming the tml bitstream uses the serial connection for transferring data.

Hpman

Isokivi

hero member

Activity: 910

Merit: 1000

Items flashing here available at btctrinkets.com

That thing is so sexy, you could still consider adding leds to the support structures, blinking at shares found so it'll cause epileptic seizures.

ebereon

sr. member

Activity: 397

Merit: 500

Quote from: yohan on July 05, 2012, 08:46:47 AM

Stacking Time

Very nice! I hope it's mine Wink

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Quote from: yohan on July 05, 2012, 08:46:47 AM

Stacking Time

gorgeous!

spiccioli

yohan

sr. member

Activity: 462

Merit: 251

Stacking Time

(Before anyone says PSU should be lifted up or turned on side to keep fan aperture clear)

yohan

sr. member

Activity: 462

Merit: 251

If I have made the correct association you should have had an email on the 23rd of June. I will forward it again to you.

punin

hero member

Activity: 560

Merit: 500

Quote from: yohan on July 05, 2012, 02:29:36 AM

Advance Warning

There are 1 or 2 people on our June delivery promise who have not responded to the notification that their unit is ready. We can only speculate why that might be but we do need to release reserved stock from our pending shelves in order to satisfy our general customer demand for more units and as fast as we can deliver. So some time later next week we be doing an order purge for anyone on a June delivery promise who has not responded, and that means orders will be cancelled from our side and you will lose your right to the offer price and your place in the queue.

We will do something similar in a few weeks time for July promise orders and so on until we eventually reach the point where Cairnsmore1 is a stock board with no pre-order structure.

Yohan

I've requested payment info several times, never got any. I got e-mail from you on 16th of june that my VAT had been verified.

Isokivi

hero member

Activity: 910

Merit: 1000

Items flashing here available at btctrinkets.com

I would start trying with the eldentyrell bitstream, but after 30 minutes of reading I still dont have a clue how to even start he's miner on a windows machine.
[edit]
After some more research it has become clear that the jtag cable is required.
And after messaging Yohan I now know that enterpoint wont bother looking at this bitstream for a couple of days. Also both Enterpoint and elldentyrell are saying they need information on oneandother and either is imo bothering to communicate with oneandother.

yohan

sr. member

Activity: 462

Merit: 251

Quote from: Hpman on July 05, 2012, 04:19:08 AM

Which FPGA pair is the right for the Icarus bitstream? P 0 and P 1?
What happens when I flash the wrong pair? Is there a risk for the FPGA IO Cells due the crossed TX/RX? Does the right DIP switch setting disconnect the net between the FPGA pairs?

Is there a block diagram which shows the position of FPGA correlating to p X

There is a new bitstream from ET, seems no connection between devices are required, every FPGA is handled as own hashing device.
When I flash the “"david”" bitstream (included in the jar file) via xc3sprog tool, am I able to use his java tool to mine? What would be the correct setting for the DIP switches?

Thx Hpman

P0 and P3 are the ones for the twin. If dip switches are set as recommended then P1, P2 are held in reset. That avoids any problems if you make sure on those dip switches. The positions go clockwise from the top left (cables to left side). No problems if flash the wrong parts you just won't get the expected peformance.

The ET bitstream we have not worked with as yet so no advice we can give there as yet. We can support individual FPGAs but that might need a Controller update.

Hpman

full member

Activity: 176

Merit: 100

Which FPGA pair is the right for the Icarus bitstream? P 0 and P 1?
What happens when I flash the wrong pair? Is there a risk for the FPGA IO Cells due the crossed TX/RX? Does the right DIP switch setting disconnect the net between the FPGA pairs?

Is there a block diagram which shows the position of FPGA correlating to p X

There is a new bitstream from ET, seems no connection between devices are required, every FPGA is handled as own hashing device.
When I flash the “"david”" bitstream (included in the jar file) via xc3sprog tool, am I able to use his java tool to mine? What would be the correct setting for the DIP switches?

Thx Hpman

Keninishna

hero member

Activity: 556

Merit: 500

would someone with a jtag cable mind giving the new TML bitstream a whirl? it has unconfirmed support for cairnsmore1. http://www.tricone-mining.com/tml.html

yohan

sr. member

Activity: 462

Merit: 251

Advance Warning

There are 1 or 2 people on our June delivery promise who have not responded to the notification that their unit is ready. We can only speculate why that might be but we do need to release reserved stock from our pending shelves in order to satisfy our general customer demand for more units and as fast as we can deliver. So some time later next week we be doing an order purge for anyone on a June delivery promise who has not responded, and that means orders will be cancelled from our side and you will lose your right to the offer price and your place in the queue.

We will do something similar in a few weeks time for July promise orders and so on until we eventually reach the point where Cairnsmore1 is a stock board with no pre-order structure.

Yohan

yohan

sr. member

Activity: 462

Merit: 251

Quote from: zefir on July 04, 2012, 11:31:24 AM

Quote from: Hpman on July 04, 2012, 08:52:41 AM

Just a guess, may you forgot to flash one FPGA with the twin_test bitstream and it is still the old shipping_test ? If im right perhaps you can detect the board when you check the LED activity when a share was found. Should be flash green when twin_test and red for shipping_test

xc3sprog –c cm1 –p 0 –Ixc6lx150.bit twin_test.bit
xc3sprog –c cm1 –p 1 –Ixc6lx150.bit twin_test.bit
xc3sprog –c cm1 –p 2 –Ixc6lx150.bit twin_test.bit
xc3sprog –c cm1 –p 3 –Ixc6lx150.bit twin_test.bit

My assumption is that every FPGA has its own flash and that needs to program. Unless there are any useful documentation about architecture etc. its all only a guess.

I assumed that for the twin-test it is enough to flash FPGAs 0 and 3, since the other two are not operational in that mode. Any indication that this might cause problems?

No problems just doing the 2.

testconpastas2

full member

Activity: 199

Merit: 100

with twintest only -p0 and -p3 are needed.

zefir

donator

Activity: 919

Merit: 1000

Quote from: Hpman on July 04, 2012, 08:52:41 AM

Just a guess, may you forgot to flash one FPGA with the twin_test bitstream and it is still the old shipping_test ? If im right perhaps you can detect the board when you check the LED activity when a share was found. Should be flash green when twin_test and red for shipping_test

xc3sprog –c cm1 –p 0 –Ixc6lx150.bit twin_test.bit
xc3sprog –c cm1 –p 1 –Ixc6lx150.bit twin_test.bit
xc3sprog –c cm1 –p 2 –Ixc6lx150.bit twin_test.bit
xc3sprog –c cm1 –p 3 –Ixc6lx150.bit twin_test.bit

My assumption is that every FPGA has its own flash and that needs to program. Unless there are any useful documentation about architecture etc. its all only a guess.

I assumed that for the twin-test it is enough to flash FPGAs 0 and 3, since the other two are not operational in that mode. Any indication that this might cause problems?

Hpman

full member

Activity: 176

Merit: 100

Quote from: Isokivi on July 04, 2012, 02:23:50 AM

What do you think my issue here is:

3 Cairnsmores plugged in at an unpowered usb hub, all running the twintest bitstream and enterpoints cgminer for it. Windows seven, quad core, plenty of ram (it's a gaming pc).
5 first cores are pushing shares as is to be expected (0-4) But CM5 is doing less than a third of the shares of the other cores, with 0 rejects showing up at cgminer, whereas the other cores have a normal invalid rate (6-16 invalids at aroud 3300 shares hashed per core).

Im starting cgminer with the command: cgminer_twintest -o mint.bitminter.com:8332 -u ME -p MAHPASS --disable-gpu -S noauto -S\\.\COM22 -S \\.\COM23 -S \\.\COM26 -S \\.\COM27 -S \\.\COM30 -S \\.\COM31

If some relevant info is missing please just ask me.

Just a guess, may you forgot to flash one FPGA with the twin_test bitstream and it is still the old shipping_test ? If im right perhaps you can detect the board when you check the LED activity when a share was found. Should be flash green when twin_test and red for shipping_test

xc3sprog –c cm1 –p 0 –Ixc6lx150.bit twin_test.bit
xc3sprog –c cm1 –p 1 –Ixc6lx150.bit twin_test.bit
xc3sprog –c cm1 –p 2 –Ixc6lx150.bit twin_test.bit
xc3sprog –c cm1 –p 3 –Ixc6lx150.bit twin_test.bit

My assumption is that every FPGA has its own flash and that needs to program. Unless there are any useful documentation about architecture etc. its all only a guess.

yohan

sr. member

Activity: 462

Merit: 251

Ok, I will try this a bit later, once I figure out which board it is, Would you care to comment on why the boards only work in usb3 ports for me ?
[/quote]

We have seen it the other way with USB3 being a problem in Linux systems and we think that is a driver issue. However I do need to check this but I think USB3 ports can have a much higher current specification. That might be the difference especially as you have an unpowered hub.

testconpastas2

full member

Activity: 199

Merit: 100

Quote from: Isokivi on July 04, 2012, 05:44:57 AM

Quote from: testconpastas2 on July 04, 2012, 04:04:15 AM

surely this core has frozen. if you quit cgminer and try to re-execute the same comand. You'll get a COM error in that port..

If any core gets frozen, accepts stop raising too (in that core) and average hasing speed decrease

please answer with your feedback

No, it's not frozen, it keeps on hashing, just at the very low rate. It's been like this since the beginning.

Isokivi please confirm me that accepts are growing . I sometimes have some boards hashing ( acording to cgminer) but not accepting shares at all

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