Bitcoin Forum
November 13, 2018, 07:04:17 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
   Home   Help Search Login Register More  
Pages: « 1 ... 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 [92] 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »
  Print  
Author Topic: CoinTerra announces its first ASIC - Hash-Rate greater than 500 GH/s  (Read 229847 times)
testerx
Hero Member
*****
Offline Offline

Activity: 600
Merit: 500



View Profile
February 12, 2014, 01:32:01 PM
 #1821

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
roy7
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250


View Profile
February 12, 2014, 01:54:28 PM
 #1822

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.

gmaxwell mentioned this on irc last night as well, stating that Cointerra handled p2pool terrific.
aerobatic
Hero Member
*****
Offline Offline

Activity: 702
Merit: 500


View Profile
February 12, 2014, 06:19:29 PM
 #1823

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
gmaxwell
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1669



View Profile
February 12, 2014, 06:26:25 PM
 #1824

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).


Bitcoin will not be compromised
Powell
Sr. Member
****
Offline Offline

Activity: 428
Merit: 250


View Profile
February 12, 2014, 06:27:06 PM
 #1825

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
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500


View Profile
February 12, 2014, 06:49:15 PM
 #1826

anyone outside of US received tracking number yet?

miahallen
Newbie
*
Offline Offline

Activity: 48
Merit: 0


View Profile
February 12, 2014, 07:29:12 PM
 #1827

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
Moderator
Legendary
*
Offline Offline

Activity: 2702
Merit: 1145


Ruu \o/


View Profile WWW
February 12, 2014, 08:12:55 PM
 #1828

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.

Developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org, 1% Fee Solo mining at solo.ckpool.org
-ck
miahallen
Newbie
*
Offline Offline

Activity: 48
Merit: 0


View Profile
February 12, 2014, 09:00:44 PM
 #1829

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 Sad

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
Newbie
*
Offline Offline

Activity: 48
Merit: 0


View Profile
February 12, 2014, 09:08:47 PM
 #1830

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
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000



View Profile
February 12, 2014, 09:39:36 PM
 #1831


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
Newbie
*
Offline Offline

Activity: 48
Merit: 0


View Profile
February 12, 2014, 09:57:11 PM
 #1832

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

Activity: 1498
Merit: 1000



View Profile
February 12, 2014, 10:06:59 PM
 #1833

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

Like so? 
miahallen
Newbie
*
Offline Offline

Activity: 48
Merit: 0


View Profile
February 12, 2014, 11:03:54 PM
 #1834

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
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250



View Profile
February 12, 2014, 11:12:42 PM
 #1835

anyone outside of US received tracking number yet?

I would like to know this too..

Entropy-uc
Hero Member
*****
Offline Offline

Activity: 756
Merit: 501


View Profile
February 12, 2014, 11:14:24 PM
 #1836

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
Member
**
Offline Offline

Activity: 117
Merit: 10


View Profile
February 12, 2014, 11:14:37 PM
 #1837

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
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


View Profile
February 12, 2014, 11:30:11 PM
 #1838

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

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
miahallen
Newbie
*
Offline Offline

Activity: 48
Merit: 0


View Profile
February 12, 2014, 11:33:26 PM
 #1839

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
Hero Member
*****
Offline Offline

Activity: 756
Merit: 501


View Profile
February 12, 2014, 11:43:00 PM
 #1840

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.
Pages: « 1 ... 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 [92] 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!