Bitcoin Forum
December 06, 2016, 06:07:19 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 [6]  All
  Print  
Author Topic: Handle much larger MH/s rigs : simply increase the nonce size  (Read 9094 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
October 10, 2012, 03:43:56 PM
 #101

My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average.

... so transfer 1,000 headers with different extranonces in one handshake.  Or don't handshake every time. Or modify the firmware that speaks whatever mining protocol you're sending at it to do the increment-extranonce-and-recompute-the-merkle-root-thing itself.

All of this discussion is useless; even if you could convince us core developers that we need A HARD FORK RIGHT THIS VERY MINUTE! there is absolutely zero chance we could make that happen before the ASICS start shipping.

So: plan accordingly.

How often do you get the chance to work on a potentially world-changing project?
1481047639
Hero Member
*
Offline Offline

Posts: 1481047639

View Profile Personal Message (Offline)

Ignore
1481047639
Reply with quote  #2

1481047639
Report to moderator
1481047639
Hero Member
*
Offline Offline

Posts: 1481047639

View Profile Personal Message (Offline)

Ignore
1481047639
Reply with quote  #2

1481047639
Report to moderator
1481047639
Hero Member
*
Offline Offline

Posts: 1481047639

View Profile Personal Message (Offline)

Ignore
1481047639
Reply with quote  #2

1481047639
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481047639
Hero Member
*
Offline Offline

Posts: 1481047639

View Profile Personal Message (Offline)

Ignore
1481047639
Reply with quote  #2

1481047639
Report to moderator
1481047639
Hero Member
*
Offline Offline

Posts: 1481047639

View Profile Personal Message (Offline)

Ignore
1481047639
Reply with quote  #2

1481047639
Report to moderator
1481047639
Hero Member
*
Offline Offline

Posts: 1481047639

View Profile Personal Message (Offline)

Ignore
1481047639
Reply with quote  #2

1481047639
Report to moderator
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
October 10, 2012, 03:48:11 PM
 #102

Its not misdesign, its trade-off. The 32 bit nonce is old design, probably it looked great when only CPUs where doing mining, but right now it looks like a bottleneck.
It doesn't not look like a bottleneck. It provides a factor of four billion in reduction in whatever serial task exists outside of that. I have yet to see any evidence that it's a bottleneck.

My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average.

You are getting 140+ Ghash/sec on a single device?  Today?  In reality?

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
btharper
Sr. Member
****
Offline Offline

Activity: 389



View Profile
October 10, 2012, 04:16:01 PM
 #103

Its not misdesign, its trade-off. The 32 bit nonce is old design, probably it looked great when only CPUs where doing mining, but right now it looks like a bottleneck.
It doesn't not look like a bottleneck. It provides a factor of four billion in reduction in whatever serial task exists outside of that. I have yet to see any evidence that it's a bottleneck.

My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average.

You are getting 140+ Ghash/sec on a single device?  Today?  In reality?
+1

Most devices don't process one hash from 0 to 4 billion in (total hashrate/4 billion), they run several processes in parallel across several chips. So each of your 20 onboard chips are each (relatively) slowly chewing through work and needs a new piece of work every several hundred milliseconds.

Also as Gavin said, send more than one piece of work for each handshake. Between longpoll and everything else that's setup, I don't see any reason not to have several pieces of work queued up and ready to go on the device side of the USB cord.
beekeeper
Sr. Member
****
Offline Offline

Activity: 406


LTC


View Profile WWW
October 10, 2012, 04:37:52 PM
 #104

My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average.

... so transfer 1,000 headers with different extranonces in one handshake.  Or don't handshake every time. Or modify the firmware that speaks whatever mining protocol you're sending at it to do the increment-extranonce-and-recompute-the-merkle-root-thing itself.

All of this discussion is useless; even if you could convince us core developers that we need A HARD FORK RIGHT THIS VERY MINUTE! there is absolutely zero chance we could make that happen before the ASICS start shipping.

So: plan accordingly.


Bulk transactions are for video streaming. Anything derived from financial transactions should have every byte handshaked. Cheesy
Ofc, it can be done like that, but again, we are back at start, I have to overdesign chip controllers to cover extra bandwidth.
BTW: I never intended to start arguing, its rather, as I said, an annoyance I wanted to talk about.

25Khs at 5W Litecoin USB dongle (FPGA), 45kHs overclocked
https://bitcointalk.org/index.php?topic=310926
Litecoin FPGA shop -> http://ltcgear.com
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
October 10, 2012, 04:49:45 PM
 #105

Ofc, it can be done like that, but again, we are back at start, I have to overdesign chip controllers to cover extra bandwidth.

It is nice to see you agree that the only problem is sub-optimal software in miners.

a) Optimize wrongly designed mining software
or
b) Hard fork of whole bitcoin network?

I vote for b)

Btw it would be quite comfortable for me to agree with you. With bigger nonce range I won't need to switch to Stratum protocol, because getwork protocol would be good enough for ages. But still I decided that there's much easier solution than trying to do hard fork, so I just re-designed protocol. Btw it isn't easy, I'm working on it almost two months on full time.

Stop calling optimizations "work arounds" and let's go back to work.

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
October 10, 2012, 09:04:17 PM
 #106

My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average.

... so transfer 1,000 headers with different extranonces in one handshake.  Or don't handshake every time. Or modify the firmware that speaks whatever mining protocol you're sending at it to do the increment-extranonce-and-recompute-the-merkle-root-thing itself.

All of this discussion is useless; even if you could convince us core developers that we need A HARD FORK RIGHT THIS VERY MINUTE! there is absolutely zero chance we could make that happen before the ASICS start shipping.

So: plan accordingly.

Yes - plan ... that's the point of this thread ... but not of the "We can't ever do a hard fork" devs Tongue
... and that your post clearly shows a lack of understanding 'planning'.

Plan for a future hard fork to allow a 2nd version block header.
The issue is obvious, the cause is obvious, the path to ultimately fix it is obvious, but then you make this stupid statement
"A HARD FORK RIGHT THIS VERY MINUTE"
... who said that? (other than you)

Though - as has already been pointed out - this issue came up 2 years ago ... yeah a lot of foresight back then ignoring it Tongue
No doubt nothing was learned from that mistake.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
tacotime
Legendary
*
Offline Offline

Activity: 1484



View Profile
December 14, 2013, 08:38:16 PM
 #107

So... has this issue been resolved?  Will it still break all ASICs if they get too fast?

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
TierNolan
Legendary
*
Offline Offline

Activity: 1036


View Profile
December 14, 2013, 08:57:07 PM
 #108

So... has this issue been resolved?  Will it still break all ASICs if they get too fast?

You can send much more complex info to miners now.  The "getblocktemplate" rpc call allows the pool to give miners enough info to generate their own headers on the fly.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
btharper
Sr. Member
****
Offline Offline

Activity: 389



View Profile
December 16, 2013, 12:27:35 AM
 #109

So... has this issue been resolved?  Will it still break all ASICs if they get too fast?

You can send much more complex info to miners now.  The "getblocktemplate" rpc call allows the pool to give miners enough info to generate their own headers on the fly.
Seconded. Between Stratum and GBT there really wasn't a problem and one failed to materialize for no reason. Everything's moving along nicely now. Probably an idea worth revisiting in the future if there's another, more important, reason to do a hard-fork (like switching to SHA-512 or an SHA-3 family item) which would break current ASICs due to the massive change in protocol.
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
December 17, 2013, 05:17:27 AM
 #110

So... has this issue been resolved?  Will it still break all ASICs if they get too fast?

You can send much more complex info to miners now.  The "getblocktemplate" rpc call allows the pool to give miners enough info to generate their own headers on the fly.
Seconded. Between Stratum and GBT there really wasn't a problem and one failed to materialize for no reason. Everything's moving along nicely now. Probably an idea worth revisiting in the future if there's another, more important, reason to do a hard-fork (like switching to SHA-512 or an SHA-3 family item) which would break current ASICs due to the massive change in protocol.
Stratum, GBT and "getblocktemplate" have not solved this in any way whatsoever.

As before, each single nonce work item that allows for O(9) tests, is sent to the device.

At the moment, still no miners do any more than this.

The solution I presented a year ago would allow the information sent to the device to be able to produce O(9) more results with just a 32 bit extension to the nonce size - i.e be future proof by simply increasing it by O(9) (32 bits) O(19) (64 bits) or even O(28) (48bits) easily enough

The solution you are implying (that doesn't exist) would be to code the stratum protocol into the mining device, rather than having the extreme simplicity of just having a counter that is larger.

GBT is not even relevant to the topic since having to send up to a megabyte of data to the mining device at least every 30s and delaying work restart after an LP until that data is sent is ridiculous.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Pages: « 1 2 3 4 5 [6]  All
  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!