[ANN] Bitfury ASIC sales in EU and Europe

[spiccioli]

Half of the chips, 7-16, are dead and go to zero with auto-tuning while not hashing with manual tuning.

Since the SPI signals form a long chain from chip to chip, there's probably a problem at chip 6 or 7. Check those extra carefully on the board. Note: the chips are numbered in white ink in the same order as in the software.

If the chips are mounted correctly, and one is broken, it could be that it prevents communication with next one in the chain. In that case, the chip could be removed, and the solder jumpers shorted. Beware: don't attempt to fix unless you've done stuff like this before.

Ok, I'll look at them more in depth.

I've never used a solder iron in my life, so I won't try to break it more than it already is

spiccioli

I've made a couple more photos, to my untrained eye the only strange thing is SJ51

http://imgur.com/c8hCggO,A4ImRve

Chips 6,7,8,9 seem to have their IO pins OK.

spiccioli

[1713857273]

1713857273

[-Redacted-]

Good eye, Spicciolli!  That looks like a problem, for certain...  Fix that (or get it fixed), and you've probably repaired the card.

[cscape]

I agree, the solder jumper will surely cause problems.

[achimsmile]

Sorry to interrupt you spiccioli.

My kit is showing me a Noncerate of 43.1GH/s (yayy! a gigahash more compared to autotuning)

But on BTCGuild I'm only at 33.3GH/s (99.32% valid shares)

I know the guild only shows an estimate, but the rate has always been considerably lower than what the raspbi tells me over the last 30 hours of uninterrupted mining.

Is that regular behaviour?

[darkfriend77]

I had a similar issue ... somehow if I use load balanced mining .... with 40-42GH on 3 pools im getting 13GH at BTCGuild ... 13GH .... at eligius ... and 12 GH at Bitminter ...

if I change to mine 100% on BTCGuild it shows me 20-30 GH only .... i tryed with 16,32 & 64 diff

[Sitarow]

I had a similar issue ... somehow if I use load balanced mining .... with 40-42GH on 3 pools im getting 13GH at BTCGuild ... 13GH .... at eligius ... and 12 GH at Bitminter ...

if I change to mine 100% on BTCGuild it shows me 20-30 GH only .... i tryed with 16,32 & 64 diff

Have you tried the reported accepted shares from BTCGuild to the accepted shares the client reports?

This way you can compare with accuracy.

[juhakall]

I had a similar issue ... somehow if I use load balanced mining .... with 40-42GH on 3 pools im getting 13GH at BTCGuild ... 13GH .... at eligius ... and 12 GH at Bitminter ...

if I change to mine 100% on BTCGuild it shows me 20-30 GH only .... i tryed with 16,32 & 64 diff

You could be having a different issue, but I noticed the stratum proxy is behaving strangely with BTC Guild. If my minimum worker difficulty is set to 1, the proxy correctly picks up when the difficulty quickly increases, and doesn't try to send shares which don't meet the requirement. However, if I set the minimum difficulty so high that it never has to be increased by the pool, the proxy keeps on thinking that the target is diff 1, and sends every share to the pool. Obviously most of them get rejected, and this might even overload a router.

I didn't have any actual problems with this, though. BTC Guild always reported my full hashrate, even when I was flooding it with tons of rejected shares. Of course flooding the server isn't exactly nice for the pool OP

[rammy2k2]

Tomorrow ill receive my starter kit   Soon ill order a board with Oct delivery
I hope i wont have any major issues with the kit, will keep u guys updated

[ssi]

I had a similar issue ... somehow if I use load balanced mining .... with 40-42GH on 3 pools im getting 13GH at BTCGuild ... 13GH .... at eligius ... and 12 GH at Bitminter ...

if I change to mine 100% on BTCGuild it shows me 20-30 GH only .... i tryed with 16,32 & 64 diff

You could be having a different issue, but I noticed the stratum proxy is behaving strangely with BTC Guild. If my minimum worker difficulty is set to 1, the proxy correctly picks up when the difficulty quickly increases, and doesn't try to send shares which don't meet the requirement. However, if I set the minimum difficulty so high that it never has to be increased, the proxy keeps on thinking that the target is diff 1, and sends every share to the pool. Obviously most of them get rejected, and this might even overload a router.

I had this issue as well... I had my difficulty set at 8 in btcguild, I only have 18GH.  Stratum proxy would send everything back at diff 1, and none of them were accepted.  I set my min difficulty to 1 in btcguild, and now it negotiates its way up to 8.

[MXRider]

I had a similar issue ... somehow if I use load balanced mining .... with 40-42GH on 3 pools im getting 13GH at BTCGuild ... 13GH .... at eligius ... and 12 GH at Bitminter ...

if I change to mine 100% on BTCGuild it shows me 20-30 GH only .... i tryed with 16,32 & 64 diff

What shows? BTCGuild or the miner's web GUI? Check /run/shm/.putstat.log file. First number on each row is the amount of queued work. It should be zero. I had problems with BTCGuild. EMC works perfectly.

[eleuthria]

There's a protocol implementation error in the official Stratum proxy.  The original spec always stated the first message a pool should be receiving is a mining.subscribe method.  However, if you try to make the Stratum Proxy do the authorization (-cu -cp args), it sends those *before* the subscribe method.  As a result, you're getting your difficulty set to 2/4/8/etc before the "default subscribe response" is sent.  A workaround is being added to the BTC Guild stratum code today to hopefully prevent this mixup.

[ssi]

There's a protocol implementation error in the official Stratum proxy.  The original spec always stated the first message a pool should be receiving is a mining.subscribe method.  However, if you try to make the Stratum Proxy do the authorization (-cu -cp args), it sends those *before* the subscribe method.  As a result, you're getting your difficulty set to 2/4/8/etc before the "default subscribe response" is sent.  A workaround is being added to the BTC Guild stratum code today to hopefully prevent this mixup.

Would it be potentially easier just to fix the error in the proxy?

[CryptoCluster]

Hmmm. Another issue. I have disabled Autotune for all chips. I run miner with console output. And suddenly, after processing 800-1000 jobs, miner prints "SPI update chip xxx", and my Noncerate starts dropping drastically... If I check /run/shm/.stat.log chips have aIFDSo parameters.
How is it possible?

[spiccioli]

I had a similar issue ... somehow if I use load balanced mining .... with 40-42GH on 3 pools im getting 13GH at BTCGuild ... 13GH .... at eligius ... and 12 GH at Bitminter ...

if I change to mine 100% on BTCGuild it shows me 20-30 GH only .... i tryed with 16,32 & 64 diff

You could be having a different issue, but I noticed the stratum proxy is behaving strangely with BTC Guild. If my minimum worker difficulty is set to 1, the proxy correctly picks up when the difficulty quickly increases, and doesn't try to send shares which don't meet the requirement. However, if I set the minimum difficulty so high that it never has to be increased, the proxy keeps on thinking that the target is diff 1, and sends every share to the pool. Obviously most of them get rejected, and this might even overload a router.

I had this issue as well... I had my difficulty set at 8 in btcguild, I only have 18GH.  Stratum proxy would send everything back at diff 1, and none of them were accepted.  I set my min difficulty to 1 in btcguild, and now it negotiates its way up to 8.

Hashing comrades!

HHTT works flawlessly and needs your hashing power a lot more than BTCGuild which is already the largest pool on Earth!

 

spiccioli

[-Redacted-]

Hey spiccioli - go get your hashing card fixed and stop giving away secrets like that....  

Word will get around that people make lots of coins on HHTT and it will get too big...

[vulgartrendkill]

Hey spiccioli - go get your hashing card fixed and stop giving away secrets like that....  

Word will get around that people make lots of coins on HHTT and it will get too big...

uhuh nice *switches pools*

[eleuthria]

There's a protocol implementation error in the official Stratum proxy.  The original spec always stated the first message a pool should be receiving is a mining.subscribe method.  However, if you try to make the Stratum Proxy do the authorization (-cu -cp args), it sends those *before* the subscribe method.  As a result, you're getting your difficulty set to 2/4/8/etc before the "default subscribe response" is sent.  A workaround is being added to the BTC Guild stratum code today to hopefully prevent this mixup.

Would it be potentially easier just to fix the error in the proxy?

The problem is, fixing the error in the proxy would require slush to actually still care about mining.  He hasn't been seen on bitcointalk in months.  Additionally, it'd require every user to upgrade to a forked proxy that fixes the problem.  It's much easier to just make the pool workaround the broken proxy rather than hope everybody else upgrades.

The error is only related to minimum difficulty though.  If you have your minimum difficulty set to 1, it will work just fine, and vardiff will adjust your difficulty as needed.

[-Redacted-]

How can you say Slush doesn't still care?   I prepaid for a Trezor months ago.  Oh, well,  I mean, when I mine on his pool we only get a couple of invalids or bad block reward calculations per day....   Usually...  When the servers aren't down...   Maybe he just lost his BitcoinTalk password ??

Errrrrrmm.   Never mind...

[eleuthria]

BTC Guild has now deployed a workaround for the reverse auth/subscribe order in slush's Stratum Mining Proxy to prevent it from spamming low difficulty shares when a worker has a pre-set starting difficulty.

[pbigmoon]

punin

When an order is placed and paid via bitpay does it go to processing automatically after so many confirmations?

Only asking as it took a few hours for the first confirmation (usually only takes 10 or so mins) and the order is still on hold.