CoinTerra announces its first ASIC - Hash-Rate greater than 500 GH/s

[aerobatic]

The cointerra driver has now been merged into the cgminer git master code, so the lucky few who already have hardware can try it out by running their devices directly with a PC via USB. While there are probably fixes generically in the code from the main cgminer code, it is entirely possible there are still bugs in the driver code that will only show up only with real world testing.

I should add the cointerra device+protocol+driver has the most advanced work model designed for p2pool or similar networking and bitcoin transaction propagation with virtually seamless work restarts for rapid frequent block changes such as those required by p2pool, along with flushing of any queued work on a work template update such as that which occurs regularly with stratum update so it will always be working on the most current work - meaning it is optimised for maximum transmission of transactions, provided the pool is updating its work template frequently with new transactions. Kudos to the cointerra team for adopting everything I recommended in their work transmission/protocol.

Any idea why the local hashrate cgminer reports for these units is so different than what pools see?  Is it really just optimized for p2pool?  Even when the local console is claiming 1.7Thash the pools are reporting back 1.4x and it doesn't really seem pool dependent.

testerx -

a few ideas worth trying...

try a few different pools and see if you're still seeing the same issue, eg. eligius, etc.  when i looked, the cgminer reported perf was pretty close to the mining pool reported performance on my systems.

also, check you've got the two ac power cables attached to two different circuits in your home.  not just two different sockets.. make sure each socket is on a different breaker, to ensure you're getting all the power to the box that it needs (its drawing 2,000 watts which is too much for one single breaker)

and also what happens if you try selecting a slower hashing speed?  does it still have a disparity between cgminer reported perf and pool reported perf?

-- Jez

[1713523000]

1713523000

[1713523000]

1713523000

[1713523000]

1713523000

[1713523000]

1713523000

[1713523000]

1713523000

[1713523000]

1713523000

[gmaxwell]

FWIW, My unit works fantastically on P2Pool. I appear to get somewhat above the web ui reported rate, and the device has the lowest stale rate I've seen on any hardware device (0.23x of the Avalon batch 1's stale rate,  about 0.78x the bitmain antminer S1 which was the prior best I'd seen).

[Powell]

The cointerra driver has now been merged into the cgminer git master code, so the lucky few who already have hardware can try it out by running their devices directly with a PC via USB. While there are probably fixes generically in the code from the main cgminer code, it is entirely possible there are still bugs in the driver code that will only show up only with real world testing.

I should add the cointerra device+protocol+driver has the most advanced work model designed for p2pool or similar networking and bitcoin transaction propagation with virtually seamless work restarts for rapid frequent block changes such as those required by p2pool, along with flushing of any queued work on a work template update such as that which occurs regularly with stratum update so it will always be working on the most current work - meaning it is optimised for maximum transmission of transactions, provided the pool is updating its work template frequently with new transactions. Kudos to the cointerra team for adopting everything I recommended in their work transmission/protocol.

Any idea why the local hashrate cgminer reports for these units is so different than what pools see?  Is it really just optimized for p2pool?  Even when the local console is claiming 1.7Thash the pools are reporting back 1.4x and it doesn't really seem pool dependent.

testerx -

a few ideas worth trying...

try a few different pools and see if you're still seeing the same issue, eg. eligius, etc.  when i looked, the cgminer reported perf was pretty close to the mining pool reported performance on my systems.

also, check you've got the two ac power cables attached to two different circuits in your home.  not just two different sockets.. make sure each socket is on a different breaker, to ensure you're getting all the power to the box that it needs (its drawing 2,000 watts which is too much for one single breaker)

and also what happens if you try selecting a slower hashing speed?  does it still have a disparity between cgminer reported perf and pool reported perf?

-- Jez

If you are on the same breaker you are using over 80% (83%) which is a HUGE no no, that is granted if you are in the US and on a 20amp breaker (15 amp breaker you'd be done).

[Anotheranonlol]

anyone outside of US received tracking number yet?

[miahallen]

I just got my tracking number for my two miners....should have them up and running tomorrow.

    Order #594
    Paid on AUG 23rd, 2013
    Received tracking on FEB 11th, 2014
    Received system on FEB 12th, 2014
    average hash rate 1st Miner - 1.6 TH/s
    average hash rate 2nd miner - 750 GH/s (only 1 chip operational ATM)
    power draw - approx 1900W each, based on readings from my "KILL A WATT"

I'm a bit disappointed that one of the chips in my 2nd box is not running.  But Peter responded to my text message immediately and we're troubleshooting the problem at this time.

[-ck]

The cointerra driver has now been merged into the cgminer git master code, so the lucky few who already have hardware can try it out by running their devices directly with a PC via USB. While there are probably fixes generically in the code from the main cgminer code, it is entirely possible there are still bugs in the driver code that will only show up only with real world testing.

I should add the cointerra device+protocol+driver has the most advanced work model designed for p2pool or similar networking and bitcoin transaction propagation with virtually seamless work restarts for rapid frequent block changes such as those required by p2pool, along with flushing of any queued work on a work template update such as that which occurs regularly with stratum update so it will always be working on the most current work - meaning it is optimised for maximum transmission of transactions, provided the pool is updating its work template frequently with new transactions. Kudos to the cointerra team for adopting everything I recommended in their work transmission/protocol.

Any idea why the local hashrate cgminer reports for these units is so different than what pools see?  Is it really just optimized for p2pool?  Even when the local console is claiming 1.7Thash the pools are reporting back 1.4x and it doesn't really seem pool dependent.

Working well on p2pool they should also work well on any pool whatsoever. Earlier versions of the driver reported hashrate back that wasn't necessarily translating into valid share generation but that should be fixed in the existing code unless you received hardware with a very early version of the driver. I had tested the devices remotely on most of the top pools and found no problem except for some pools that had extremely long share-to-response time lag which made for very high rejects. Turning on verbose mode will show that lag if it exists. If you can get the output from the API stats, there is a wealth of information in the current driver version about these devices operating in terms of raw hashrate, accepted hashrate, cores producing shares and so on.

[miahallen]

I just got my tracking number for my two miners....should have them up and running tomorrow.

    Order #594
    Paid on AUG 23rd, 2013
    Received tracking on FEB 11th, 2014
    Received system on FEB 12th, 2014
    average hash rate 1st Miner - 1.6 TH/s
    average hash rate 2nd miner - 750 GH/s (only 1 chip operational ATM)
    power draw - approx 1900W each, based on readings from my "KILL A WATT"

I'm a bit disappointed that one of the chips in my 2nd box is not running.  But Peter responded to my text message immediately and we're troubleshooting the problem at this time.

After two hours...as you can see, one of my miners is only running a single chip

http://i161.photobucket.com/albums/t228/miahallen/TerraMinerIV_01.png

http://i161.photobucket.com/albums/t228/miahallen/TerraMinerIV_02.png

BTW - I installed a 70A 120V circuit breaker in my main breaker box and ran two 20A dual-plug outlets.  Each miner has each of its PSUs plugged into either outlet so that both miners are sharing both ciruits.  Each circuit should be good for 20A * 120V = 2400W.

[miahallen]

I should also point out however, that Peter Kirby (CoinTerra) responded to my texts within a couple minutes and has been very communicative.  He has already escalated my case to support and they are addressing the problem in a VERY professional & high priority fashion (in my opinion).

[dropt]

BTW - I installed a 70A 120V circuit breaker in my main breaker box and ran two 20A dual-plug outlets.  Each miner has each of its PSUs plugged into either outlet so that both miners are sharing both ciruits.  Each circuit should be good for 20A * 120V = 2400W.

Pardon?  What guage wire did you run?  Are you implying that you ran both 'hots' to a single 70A breaker?

[miahallen]

Yes, I used 12 gauge...the breaker is double posted...but it says that its internally connected.  Did I f-up?

[dropt]

Yes, I used 12 gauge...the breaker is double posted...but it says that its internally connected.  Did I f-up?

Like so? 

[miahallen]

Yes, keep in mind that each "hot" should only be pulling a max of around 18A (2100W peak / 120V = 17.5A)

I figured this would be fine since most homes are run with 15A circuits and 14 gauge wire.

[VolanicEruptor]

anyone outside of US received tracking number yet?

I would like to know this too..

[Entropy-uc]

Yes, keep in mind that each "hot" should only be pulling a max of around 18A (2100W peak / 120V = 17.5A)

I figured this would be fine since most homes are run with 15A circuits and 14 gauge wire.

Each wire could draw 70 A which would overheat the wire, melt the insulation and possibly start a fire.

The proper way to do what you want is to run properly sized wires from the 70A breaker (6 ga, I think but look it up) and put in a sub panel with individual breakers for the plugs you want to connect.

IANAE (I am not an electrician), but I did work for one during college.

[JoseSan]

The waterblock+radiator setup appears to cool all the chips fairly evenly; though two waterblocks are attached to one radiator, the coolant flows through alternating radiator fins, so in effect they are cooled in parallel. For this reason I'm curious why my fourth unit is so much lower than the rest:



The second unit is approximately 5 GH/s slower, too.

[jjiimm_64]

Yes, keep in mind that each "hot" should only be pulling a max of around 18A (2100W peak / 120V = 17.5A)

I figured this would be fine since most homes are run with 15A circuits and 14 gauge wire.

Each wire could draw 70 A which would overheat the wire, melt the insulation and possibly start a fire.

The proper way to do what you want is to run properly sized wires from the 70A breaker (6 ga, I think but look it up) and put in a sub panel with individual breakers for the plugs you want to connect.

IANAE (I am not an electrician), but I did work for one during college.

imho.  should be running 220.  a 30 amp breaker with a server strip and c13 PSU plugs would do the trick for 2 easy

[miahallen]

There are differences in the individual chips, some will naturally run hotter than others...in addition, mounting the waterblocks is not going to be identical on all chips....so there are a lot of variables that could affect temps...as long as they are in a safe range you should not have anything to worry about.

@jjiimm_64...well, due to the outlet being limited to 20A...wouldn't it "go" before the wires (unless there is a short circuit in the wiring or something...), which should handle 20A just fine.

[Entropy-uc]

There are differences in the individual chips, some will naturally run hotter than others...in addition, mounting the waterblocks is not going to be identical on all chips....so there are a lot of variables that could affect temps...as long as they are in a safe range you should not have anything to worry about.

@jjiimm_64...well, due to the outlet being limited to 20A...wouldn't it "go" before the wires (unless there is a short circuit in the wiring or something...), which should handle 20A just fine.

'Going' may involve a fire.  You really should do it right.  If there is a tin whiskers problem in that power supply you could easily burn your house down.

[dprophet]

After two hours...as you can see, one of my miners is only running a single chip

I am about done with a cointerra-monitor that should detect this and reboot your system.  This doesnt fix the problem but it should keep your hash rate up.

[miahallen]

I've rebooted 3 times, but the second chip has never started

I want to open the box and troubleshoot, but the systems are sealed and I don't want to lose warranty support, so I'm waiting on "support".