Pages:
Author

Topic: [ANN] Spondoolies-Tech - carrier grade, data center ready mining rigs - page 75. (Read 1260223 times)

legendary
Activity: 1708
Merit: 1080
Hah ! Just my luck. A second SP20 I have has started to give me grief. Will troubleshoot tomorrow.

I need some new mining gear. Badly Sad



This is exactly how one of my SP20's is now. Sad

I am still able to get about 1th from the unit without too much trouble though.
legendary
Activity: 1652
Merit: 1067
Christian Antkow
Hah ! Just my luck. A second SP20 I have has started to give me grief. Will troubleshoot tomorrow.

I need some new mining gear. Badly Sad

legendary
Activity: 4256
Merit: 8551
'The right to privacy matters'
did you check the pcie wires carefully?
Yep. Even swapped the PCIE cables for those loops Sad She's dead, Jim.

That's unfortunate. You can always look at it as 3/4 alive, rather than 1/4 dead. Should run cooler and use less power.  Smiley

I wonder if at this late in the SP20 life cycle, Spondoolies will accept just a blade, and not require shipment of the whole miner and the like.

Depending on what Spondoolies says, and how adventurous you are, you might pull the 1/2 broken blade and examine it for obviously blown components and the like.

yeah ¾ alive is a good way to think of it.  

@ xian01 let us know what sp-tech tells you

BTW on the bright side diff looks to drop just a bit which makes the 3 boards a little better come this sunday.


I have seen that happen with my seasonic 1200 plat

the fault could be in a loose pcie connection  thus arcing.

I have had cablez make up some seasonic cables and it never happened again.
legendary
Activity: 1652
Merit: 1067
Christian Antkow
Depending on what Spondoolies says, and how adventurous you are, you might pull the 1/2 broken blade and examine it for obviously blown components and the like.
Purchased a replacement board from quakefiend420 for a reasonable price. Will be sure to look at the bad board once I've swapped it out and see what's what.

Replacement board came in and works well. Thanks quakefiend.

Now as for why the board went kaput to begin with... well... not sure why this happened as it was underclocked to 1.3GH/s Sad Was using an AX1200 to power it.

No other obvious signs of damage on the board.





EDIT: After more tinkering, I'm starting to think it's the controller board. Was getting a "PLL A" on one of the loops after swapping in quakefiend's board, and troubleshooting with swapping the cables to each hashing unit. Managed to clean up the "burnt out" socket on the board I yanked, plugged it back in, and got the same "PLL A" issue on one of the loops.

The zany thing is if I power cycle it enough times, it'll eventually work with no "PLL A" on one of the loops (even with the "burnt out" board) and seems to be hashing fine ATM.

Anyone have an extra controller board they might be willing to sell me ? Would like to tinker around some more.

And just so I'm clear, is it safe to assume LOOP 0 and 1 is the board on the left, and LOOP 2 and LOOP 3 are the board on the right, when facing the ethernet and power jacks ?

legendary
Activity: 2338
Merit: 1124
BTW: Has anybody got a spare PSU for an SP10 for sale?
legendary
Activity: 1652
Merit: 1067
Christian Antkow
Depending on what Spondoolies says, and how adventurous you are, you might pull the 1/2 broken blade and examine it for obviously blown components and the like.
Purchased a replacement board from quakefiend420 for a reasonable price. Will be sure to look at the bad board once I've swapped it out and see what's what.
alh
legendary
Activity: 1846
Merit: 1052
did you check the pcie wires carefully?
Yep. Even swapped the PCIE cables for those loops Sad She's dead, Jim.

That's unfortunate. You can always look at it as 3/4 alive, rather than 1/4 dead. Should run cooler and use less power.  Smiley

I wonder if at this late in the SP20 life cycle, Spondoolies will accept just a blade, and not require shipment of the whole miner and the like.

Depending on what Spondoolies says, and how adventurous you are, you might pull the 1/2 broken blade and examine it for obviously blown components and the like.
legendary
Activity: 1022
Merit: 1003
Even with running very conservative numbers. Sorry to hear it!
legendary
Activity: 1652
Merit: 1067
Christian Antkow
did you check the pcie wires carefully?
Yep. Even swapped the PCIE cables for those loops Sad She's dead, Jim.
hero member
Activity: 770
Merit: 509
It's obviously a problem, so what the HELL is the big deal? They could easily raise it incrementally. This is an engineering problem, not a political one.

The main problem is that the change would require a hard fork. A hard fork requires a consensus (otherwise it's suicide) which isn't easy to reach for a coin with a $3 billion dollar market cap and thousands of users. With that said, I still think if the block size increase proposal is refined enough eventually everyone will be on board.

Quote
A great many alts have proven beyond a shadow of a doubt that fast block times decrease backlog and do NOT kill the system.

AFAIK that's not true. I don't know of any altcoin that comes close to the tps of bitcoin. I'm almost positive that if any of those 60 second block time coins gained the amount of users bitcoin had, we would be seeing coin breaking issues with network propagation.
legendary
Activity: 4256
Merit: 8551
'The right to privacy matters'
Well shit.



First SP20 that's given me issues. Just up and died on me after working faithfully for several months. Sent an email to SPTech via their website "Contact Us" link and hopefully I can get a new board or something...

did you check the pcie wires carefully?
legendary
Activity: 784
Merit: 1000
Well shit.



First SP20 that's given me issues. Just up and died on me after working faithfully for several months. Sent an email to SPTech via their website "Contact Us" link and hopefully I can get a new board or something...

If you're interested in a replacement hashing board I have a few from machines with controller issues.  SPTech wanted too much to replace the controllers, but the boards are fine.  The warranty on the SP20 is only 90 days, so I bet you'll be in the same boat that I was in...
legendary
Activity: 1652
Merit: 1067
Christian Antkow
Well shit.



First SP20 that's given me issues. Just up and died on me after working faithfully for several months. Sent an email to SPTech via their website "Contact Us" link and hopefully I can get a new board or something...
legendary
Activity: 1372
Merit: 1022
Anarchy is not chaos.
The Great Block Size debate is one of the reasons I'm more into alts. Bitcoin has too many egos and not enough desire to be mainstream. It's obviously a problem, so what the HELL is the big deal? They could easily raise it incrementally. This is an engineering problem, not a political one. Personally, I'd be in favor of keeping the size as it is and decreasing the block time. Every solution involves a hard fork, and the current confirmation times are (to put it nicely) suboptimal. A great many alts have proven beyond a shadow of a doubt that fast block times decrease backlog and do NOT kill the system.

If Bitcoin does not or cannot grow and evolve, then it deserves to be beat out in the marketplace.
copper member
Activity: 2898
Merit: 1465
Clueless!
...
I completely agree, but the "lets just sit on our hands and wait until it's too late" plan is just suicidal.
The right process: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
The wrong process: https://github.com/gavinandresen/bitcoinxt/commit/821e223ccc4c8ab967399371761718f1015c766b

I'm not saying Jeff's proposal is the best, there are better proposals.
Gavin / Mike ways are causing a real threat of unilateral fork which I find unacceptable.

Guy

Edit:
It seems that Gavin finally understands it: https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki

We are in agreement there. No proposal should be rolled out without a large majority consensus.

What's your opinion specifically on increasing the block size limit? The original link you posted seemed to be more against the idea of an increase rather than Gavin's less than optimal approach.
I've posted the original link because of my strong disagreement with the process Gavin and Mike tried to force, e.g. Bitcoin-XT
I think that such a drastic change should be made in consensus by the core developers and then agreed upon by the big mining pools before implementing.
There should be a block size increase, but it shouldn't be enforced "from above".

Guy

my issue was with the "process" if from what I gather they 'agreed' with the china position that with the 'great firewall of china' and poor internet that 20mb was TOO BIG
a jump..which seems to be the case now ..WHY WAS THIS NOT SETTLED IN PRIVATE information gathering on the process of dev and code improvement..no dev egos are
involved so as soon as someone thinks (ego wise) this shall be so...it hits twitter without enough sober research in the background ..public ...but working towards consensus

can you imagine the btc coin price now if this was discussed/and consensus was reach without all this FUD and press drama/twitter etc  for the last 6 weeks...and just announced here as a done..I mean debate open in all this is the norm...but I mean really ..this was so bush league....

The devs at least in the open source manner of public discourse I think at least get ALL THE INFO before saying "such shall be so" and  consensus is reached and then discuss it...a valid proof of working method towards problem solving...taking extreme positions in public seems dumb when it seems to me they never even had all the facts to even base this on
assuming the china info is correct and anything more then 8mb would be problematic

just not the way to state your position on code change..... very worrying imho...hopefully they have learned something about how to approach these dev questions as
a more adult process now in the more towards consensus less jumping on twitter and other things saying my way or the highway ALL OF THIS SHOULD BE PUBLIC but
hell would we have really paid all that attention to it ..if they at least had gathered all the facts first and then did it in a less inflamatory manner ...same result less drama imho

my 2c worth
donator
Activity: 1414
Merit: 1051
Spondoolies, Beam & DAGlabs
...
I completely agree, but the "lets just sit on our hands and wait until it's too late" plan is just suicidal.
The right process: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
The wrong process: https://github.com/gavinandresen/bitcoinxt/commit/821e223ccc4c8ab967399371761718f1015c766b

I'm not saying Jeff's proposal is the best, there are better proposals.
Gavin / Mike ways are causing a real threat of unilateral fork which I find unacceptable.

Guy

Edit:
It seems that Gavin finally understands it: https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki

We are in agreement there. No proposal should be rolled out without a large majority consensus.

What's your opinion specifically on increasing the block size limit? The original link you posted seemed to be more against the idea of an increase rather than Gavin's less than optimal approach.
I've posted the original link because of my strong disagreement with the process Gavin and Mike tried to force, e.g. Bitcoin-XT
I think that such a drastic change should be made in consensus by the core developers and then agreed upon by the big mining pools before implementing.
There should be a block size increase, but it shouldn't be enforced "from above".

Guy
hero member
Activity: 770
Merit: 509
...
I completely agree, but the "lets just sit on our hands and wait until it's too late" plan is just suicidal.
The right process: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
The wrong process: https://github.com/gavinandresen/bitcoinxt/commit/821e223ccc4c8ab967399371761718f1015c766b

I'm not saying Jeff's proposal is the best, there are better proposals.
Gavin / Mike ways are causing a real threat of unilateral fork which I find unacceptable.

Guy

Edit:
It seems that Gavin finally understands it: https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki

We are in agreement there. No proposal should be rolled out without a large majority consensus.

What's your opinion specifically on increasing the block size limit? The original link you posted seemed to be more against the idea of an increase rather than Gavin's less than optimal approach.
donator
Activity: 1414
Merit: 1051
Spondoolies, Beam & DAGlabs
...
I completely agree, but the "lets just sit on our hands and wait until it's too late" plan is just suicidal.
The right process: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
The wrong process: https://github.com/gavinandresen/bitcoinxt/commit/821e223ccc4c8ab967399371761718f1015c766b

I'm not saying Jeff's proposal is the best, there are better proposals.
Gavin / Mike ways are causing a real threat of unilateral fork which I find unacceptable.

Guy

Edit:
It seems that Gavin finally understands it: https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
hero member
Activity: 770
Merit: 509
Interesting read.  I only understand 1/2 of it though.  But I do understand economics and supply/demand.  The increase in block size will make no difference in the long run if fees are not addressed for both transactions and nodes.  In 12 years, a 20mb block with no transaction fees won't do anyone any good.  That said, in this early stage of adoption, fees will cause less adoption.

  Letting fees drift up a bit won't end the game, shifting  from 1mb to 20mb is drastic.

The problem with keeping it at 1 MB is that fees won't just "drift up a bit". If bitcoin really takes off, there will be so much competition that fees will be worse than Western Union. Imagine how much bitcoin would suck if transaction fees were $1 or $10. People would realize this major flaw just switch to a shitcoin like litecoin which allows 100 times the transactions per second.

In the long run, the 1 MB limit is actually harmful for miners, not only because it would decrease adoption, but because the artificially limited supply (transactions per block) would prevent them from always being able to reach the market equilibrium and maximizing profitability.

Quote
I rather do nothing and see if market corrects via people paying more to transact.

The longer we wait and bitcoin grows, the harder it will be to pull off a hard fork.

Quote
If becomes a real issue. I rather see people that run a node get paid.  nodes moving form 6000 to 15000 would help.

Bigger block size = more adoption

More adoption = more nodes

Quote
A 2mb size in 6 months is more conservative Alternative then a 20mb jump now.

I completely agree, but the "lets just sit on our hands and wait until it's too late" plan is just suicidal.
donator
Activity: 1414
Merit: 1051
Spondoolies, Beam & DAGlabs

The crux of his argument boils down to hard forks = bad, therefore increasing the blocksize = bad. I agree hard forks are risky, but if bitcoin really takes off we would be wishing we had done the hard fork when the market cap was only at $3 billion.

We need a solution that will allow the blocksize to constantly scale with increasing internet speeds and decreasing storage costs.

I think he is being pretty dishonest when says Gavin "isn’t even a Bitcoin developer any more" and he launched a "one-sided PR campaign" as if it's impossible for people to actually support the idea of increasing the block size. In practically every poll I've seen the majority are in favor of increasing it. The arguments in favor of keeping the 1mb limit are pretty weak IMO and seem contrived from those who have something to gain by keeping the blockchain too small to handle all transactions.

I'd also love to know what qualifies him to declare what the "ethos" of bitcoin is meant to be. Bitcoin is designed to eventually be powered by fees but it was never meant to be ASAP. The original idea was that miners would get to decide which transactions to include. The hard limit was only introduced to avoid spam not force artificially high transaction fees.

Quote
For things to be left alone and transaction fees left to be determined by market rate is directly in line with the distributed libertarian principles on which Bitcoin was founded.

Satoshi never intended for 1 mb block sizes to be the permanent limit and even suggested a simple solution for increasing the max block size. (https://bitcointalksearch.org/topic/m.15366)
https://bitcoin.org/en/posts/hard-fork-policy

https://medium.com/@allenpiscitello/why-decentralization-matters-fa016a90f595

http://www.mail-archive.com/[email protected]/msg08276.html

https://twitter.com/jonmatonis/status/611197721668648960
https://twitter.com/jonmatonis/status/611198669665271809
https://twitter.com/jonmatonis/status/611200470724558848
https://twitter.com/jonmatonis/status/611899668813910016
Pages:
Jump to: