Cairnsmore1 - Quad XC6SLX150 Board

[yohan]

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.

[yohan]

Stacking Time

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

[spiccioli]

Stacking Time

gorgeous!

spiccioli

[ebereon]

Stacking Time

Very nice! I hope it's mine  

[Isokivi]

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.

[Hpman]

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

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]

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]

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]

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

Hpman

Thank you, proceeding to that.. the issue had nothing to do with the pool, same problems persist on P2pool. So I guess it could have something to do with getwork protocols.

[Isokivi]

This is the weirdest thing: When starting a cgminer copy with only two boards Im having the same issue, again it's the last core thats slacking off and the core that has been troublesome so far is not in there.
[edit]
I'd like to hear from user(s) running multiple boards on windows 7, do you have the same issue in cgminer, the last core is signifigantly slower that the others ?

[yohan]

[/quote]

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 ?

[/quote]

What ia your board serial number and what environment that you are working in?

[Isokivi]

62-0108, 62-0158 and 62-0159. Windows 7. But I believe I have hardware issues ruled out, because plugging in the 2 boards that function only yields the same problem.

[yohan]

62-0108, 62-0158 and 62-0159. Windows 7. But I believe I have hardware issues ruled out, because plugging in the 2 boards that function only yields the same problem.

Are you running the correct version of CGminer?

When you flashed the units dip you have the dip switches in the correct position for flashing and then afterwards set them to running position for the twin bitstream?

[Isokivi]

Are you running the correct version of CGminer?

When you flashed the units dip you have the dip switches in the correct position for flashing and then afterwards set them to running position for the twin bitstream?

I tought I was, somewhere along the line I had for some reason started the wrong one... Im running the correct one now, I'll report in when I have enough data, I think around 1000shares per core should be definite ?

And yes I have been playing with the dipswitches in accordance to your pictures.

[misternoodle]

I've got my board working for the most, the weird issue I'm having is that once each core has hashed about 1000-1100 shares, they will both display "OFF" in CGMiner 2.4.1 standard build.  Windows doesn't see the Cairnsmore device anymore and I usually have to power cycle the unit and then restart the computer for it to redetect.  Any idea what might be wrong?

Windows 7 x64

[yohan]

I've got my board working for the most, the weird issue I'm having is that once each core has hashed about 1000-1100 shares, they will both display "OFF" in CGMiner 2.4.1 standard build.  Windows doesn't see the Cairnsmore device anymore and I usually have to power cycle the unit and then restart the computer for it to redetect.  Any idea what might be wrong?

Windows 7 x64

There are a few reports like that and we will try and investigate them. We have a couple of theories to look at but we will have to pull personnel off the new stuff to do that so it's a compromise of when we do that looking. We think there is a good chance a lot of this type of problem will simple dissappear with the next major releases of bitstreams and associated items.

I think there was a post earlier in the thread that mentioned a CGminer issue a bit like this but I am struggling to find that again.

[punin]

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.

Thank you! Amazingly enough, I couldn't find that mail in either my inbox or junk box. I might have deleted it by accident.

[yohan]

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.

Thank you! Amazingly enough, I couldn't find that mail in either my inbox or junk box. I might have deleted it by accident.

Email isn't a perfect system.

[Isokivi]

I've got my board working for the most, the weird issue I'm having is that once each core has hashed about 1000-1100 shares, they will both display "OFF" in CGMiner 2.4.1 standard build.  Windows doesn't see the Cairnsmore device anymore and I usually have to power cycle the unit and then restart the computer for it to redetect.  Any idea what might be wrong?

Windows 7 x64

I've had this happen once, with 1/3 boards. Got no leads as in to what it's related.

[misternoodle]

I've got my board working for the most, the weird issue I'm having is that once each core has hashed about 1000-1100 shares, they will both display "OFF" in CGMiner 2.4.1 standard build.  Windows doesn't see the Cairnsmore device anymore and I usually have to power cycle the unit and then restart the computer for it to redetect.  Any idea what might be wrong?

Windows 7 x64

There are a few reports like that and we will try and investigate them. We have a couple of theories to look at but we will have to pull personnel off the new stuff to do that so it's a compromise of when we do that looking. We think there is a good chance a lot of this type of problem will simple dissappear with the next major releases of bitstreams and associated items.

I think there was a post earlier in the thread that mentioned a CGminer issue a bit like this but I am struggling to find that again.

Thanks Yohan, I'll just continue to power cycle it when it happens in the meantime.