Line 115 in getwork_listener.py on the proxy:
print '!!!', self.stratum_port
Produces a lot of !!!! 3333 in my output.
Reason to be concerned, debugging left over or something else?
Topic: [ANN] Stratum mining protocol - ASIC ready - page 17. (Read 146083 times)
With your proposal the host still needs to send work to each 60GHz miner 14 times a second to keep it busy. (That's true no matter how it's structured as a cluster, I think.)
I'm not sure about USB protocol used in first ASICs, but 14 packets per second is *absolutely* without any problem. It is at least 100x less than any possible limitation. I think you're trying to solve non-issue.
Ok, you and Con have convinced me that host CPU isn't of itself going to be a problem. But does this architecture really scale? What if your host is driving a couple of dozen 60GH/s miners? Are you confident that the USB bus will take kindly to hundreds of transactions per second? Are you confident that all host OSs you're targeting will service the USB interrupts in a timely enough manner when you're doing hundreds of transactions a second?
As for running a dozen 60 GH/s miners. Assuming we ever get to that point where a single device is registered as 60 GH/s [something tells me those ASICs will be recognized as multiple smaller devices], and somebody has a farm like that with a single controller PC, the miner could use ntime to reduce overhead if needed.
Assign each device ntime+x, and send them the same work with a unique ntime [this is assuming the devices do not support internal ntime adjustment].
Not sure that helps a whole lot, except to reduce the number of Merkle roots the host has to compute (which we've already agreed is a non issue for the forseeable future).
With your proposal the host still needs to send work to each 60GHz miner 14 times a second to keep it busy. (That's true no matter how it's structured as a cluster, I think.)
roy
Ok, you and Con have convinced me that host CPU isn't of itself going to be a problem. But does this architecture really scale? What if your host is driving a couple of dozen 60GH/s miners? Are you confident that the USB bus will take kindly to hundreds of transactions per second? Are you confident that all host OSs you're targeting will service the USB interrupts in a timely enough manner when you're doing hundreds of transactions a second?
As for running a dozen 60 GH/s miners. Assuming we ever get to that point where a single device is registered as 60 GH/s [something tells me those ASICs will be recognized as multiple smaller devices], and somebody has a farm like that with a single controller PC, the miner could use ntime to reduce overhead if needed.
Assign each device ntime+x, and send them the same work with a unique ntime [this is assuming the devices do not support internal ntime adjustment].
You can still roll the time once per second, starting the second nonce field all over again. It really isn't going to be an issue unless some dramatic new technology that doesn't even exist yet is thought up and developed and manufactured and released in the decades ahead. Quantum computers anyone?
Why only once a second? An ASIC is going to run through all nonces in far less than a second - why can't it roll ntime rapidly at least for a few seconds? No one cares if ntime is exact to the second, as long as it's roughly right.
The argument (I think) is that you'd have to rebuild the merkleroot with each extranonce, which requires extra work to either be done on the CPU, or on-board future ASICs (would be recommended, due to latency of relaying new work between the miner and the ASIC), meanwhile with ntime rolling there is no extra building of work, just increasing a secondary counter in the header.
Right.
What I'm envisaging happening is that host will tell hardware to mine with a given block header and ntime range (from now to now+30 seconds, say). a 60GH/s miner will take about 2 seconds to complete this work.
Then the host will increment extranonce and compute a new block header, and again tell the hardware to mine with the new block header and a new ntime range (again from now to now+30).
So one transaction every two seconds per 60GH/s miner.
The alternative, when driving hardware that doesn't support calculating Merkle roots, would be a minimum of 14 transactions per second per 60GH/s miner, maybe more depending on the design of the mining protocol.
Ok, you and Con have convinced me that host CPU isn't of itself going to be a problem. But does this architecture really scale? What if your host is driving a couple of dozen 60GH/s miners? Are you confident that the USB bus will take kindly to hundreds of transactions per second? Are you confident that all host OSs you're targeting will service the USB interrupts in a timely enough manner when you're doing hundreds of transactions a second?
It may well be a non-issue. But it just seems so easy to avoid potential problems here simply by allowing the hardware to work with an ntime range.
ETA: is there a risk of USB bus contention if asynchronous notifications are rapidly coming back from a large array of miners (e.g. to notify completion of work units)?
roy
What ckolivas said. My point is that ntime doesn't need to be exact to the second. We could require every miner to own their own atomic clock, but why bother.
Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?
Stratum does not need ntime rolling because a single stratum work unit is 4.2 billion times larger than a standard getwork unit (by default, it can be increased and the spec supports it very easily). However, Stratum also does support ntime rolling, the official spec is that ntime should not be increased faster than real-time.
Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?
Just don't increase it faster then real time. But the real salient point is can you really preform 4.2 billion times the work of a single work unit in 30 seconds?
Yes I see that you could bite off sections to feed verious hashing contraptions and roll the time at the speed of real time to keep them spitting out results. Far more sensible would be to have a que built in to said hashing gizmo to actually allow pre loading the next work unit making the usb time a non issue.
Edit: and of course the ability to flush the queue and abort work
What ckolivas said. My point is that ntime doesn't need to be exact to the second. We could require every miner to own their own atomic clock, but why bother.
...
In any protocol, the time will be wrong while we hash at 5/10/20 seconds per nonce range, coz if you set the time when you start hashing, the time when you find a nonce will be later....
You can't even predict it coz with e.g. a 250Mh/s device, it can take 17s to complete the nonce range, but guess what, the first nonce returned will depend on the device.
If it's an Icarus, ModMiner or Cairnsmore1, then the time is unknown. you don't know when it will find a nonce.
But that is all to do with keeping the time close to the block find time.
Setting it during Stratum mining wont make much difference (up to 30s - or on average 15s)
Yes if you set it for Stratum or GBT it will be closer than not setting it (though GBT extends transaction confirm times by on average 1 minute instead of average 15 seconds like Stratum so in the GBT case you can multiply that 15s/30s by 4)
I've no idea where anyone has actually said that it would be a bad thing to set the ntime - it doesn't matter much in the Stratum case, though, coz the time it still small.
The problem is roll-n-time (on GetWork) which can create blocks up to 2 hours in the future when abused (or if used on soon to be seen high GH/s ASICs)
Luke's pool used to set them way in the future on occasion - e.g. 90 minutes - no idea if it was a long ongoing bug, crap programming or by his choice - but of course it's pointless asking coz you've no idea if what he replies is true or not.
What ckolivas said. My point is that ntime doesn't need to be exact to the second. We could require every miner to own their own atomic clock, but why bother.
Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?
Stratum does not need ntime rolling because a single stratum work unit is 4.2 billion times larger than a standard getwork unit (by default, it can be increased and the spec supports it very easily). However, Stratum also does support ntime rolling, the official spec is that ntime should not be increased faster than real-time.
Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?
Just don't increase it faster then real time. But the real salient point is can you really preform 4.2 billion times the work of a single work unit in 30 seconds?
Yes I see that you could bite off sections to feed verious hashing contraptions and roll the time at the speed of real time to keep them spitting out results. Far more sensible would be to have a que built in to said hashing gizmo to actually allow pre loading the next work unit making the usb time a non issue.
What ckolivas said. My point is that ntime doesn't need to be exact to the second. We could require every miner to own their own atomic clock, but why bother.
Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?
Stratum does not need ntime rolling because a single stratum work unit is 4.2 billion times larger than a standard getwork unit (by default, it can be increased and the spec supports it very easily). However, Stratum also does support ntime rolling, the official spec is that ntime should not be increased faster than real-time.
Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?
DrHaribo means cgminer doesn't change the time stamp with stratum, which it doesn't since I didn't see the point. Since most pools update stratum structures with a push every 30 seconds, the time can be out by 30 seconds. Compare with ntime rolling where it can be out by 2 hours... I didn't see much point in trying hard to get the time correct to within 1 second.
Then I've no idea where his coming from coz that has nothing to do with me 
(though it is a rather pointless argument on his behalf anyway as you pointed out)
DrHaribo means cgminer doesn't change the time stamp with stratum, which it doesn't since I didn't see the point. Since most pools update stratum structures with a push every 30 seconds, the time can be out by 30 seconds. Compare with ntime rolling where it can be out by 2 hours... I didn't see much point in trying hard to get the time correct to within 1 second.
Maybe I misunderstood you, kano.
So are you saying that an inaccurate ntime is fine and you must never touch ntime (let's call it the "magic token") after you got it from bitcoind?
Or are you saying that inaccurate ntime is harmful for bitcoin? Let's call it the "kano attack". By that logic would you also say that cgminer is becoming just another miner that people should avoid using? Maybe look at bfgminer or poclbm in hope that they are less harmful to Bitcoin? I mean you often recommend people to not use other products and services for much less serious reasons. What if your own product can destroy Bitcoin?
There's always the third option. You know that I'm right, you just like to write a lot of words.
No, I'm saying your an idiot. I've never said that ntime shouldn't be changed.So are you saying that an inaccurate ntime is fine and you must never touch ntime (let's call it the "magic token") after you got it from bitcoind?
Or are you saying that inaccurate ntime is harmful for bitcoin? Let's call it the "kano attack". By that logic would you also say that cgminer is becoming just another miner that people should avoid using? Maybe look at bfgminer or poclbm in hope that they are less harmful to Bitcoin? I mean you often recommend people to not use other products and services for much less serious reasons. What if your own product can destroy Bitcoin?
There's always the third option. You know that I'm right, you just like to write a lot of words.
You even pointed out your stupidity yourself above:
...
Riddle me this: How can a clock never change and yet be accurate?
Which of course is stupid.Riddle me this: How can a clock never change and yet be accurate?
The problem with roll-n-time is that the block's ntime is regularly wrong
I run a diff report in php on my computer often and it shows the block times ... and in red where they go back in time ... often
The problem when ASIC comes along is that they will be even more wrong with roll-n-time.
(and there is the risk of valid block orphans due to this) <- I guess you don't know about this one then ...............
I have also argued that vardiff and roll-n-time works with ASIC.
They do work, even up to 500GH/s for 60 seconds worth or work.
Doesn't mean I don't think that roll-n-time is bad.
But of course it will be necessary for those crappy miners and pools that don't support stratum or gbt (like ...)
I've no idea where you even got the stupid idea that cgminer doesn't touch the ntime.
With GetWork:
If a pool wants ntime rolling, then cgminer rolls it (up to 7000). That's simply using the GetWork rules provided by the pool.
Yep it's not good to use that pool - and with ASIC it could be problematic due to the bitcoind rules regarding block timestamps.
Roll-n-time has been around for a long time - no idea why you would think that cgminer wouldn't use it - I guess you should check things before making stupid statements.
If a pool doesn't want ntime rolling it, then it doesn't change it - since it can't of course ... and anyone who tries to mine on such a GetWork pool with a 50GH/s ASIC device is gonna get a rude shock.
Maybe I misunderstood you, kano.
So are you saying that an inaccurate ntime is fine and you must never touch ntime (let's call it the "magic token") after you got it from bitcoind?
Or are you saying that inaccurate ntime is harmful for bitcoin? Let's call it the "kano attack". By that logic would you also say that cgminer is becoming just another miner that people should avoid using? Maybe look at bfgminer or poclbm in hope that they are less harmful to Bitcoin? I mean you often recommend people to not use other products and services for much less serious reasons. What if your own product can destroy Bitcoin?
There's always the third option. You know that I'm right, you just like to write a lot of words.
So are you saying that an inaccurate ntime is fine and you must never touch ntime (let's call it the "magic token") after you got it from bitcoind?
Or are you saying that inaccurate ntime is harmful for bitcoin? Let's call it the "kano attack". By that logic would you also say that cgminer is becoming just another miner that people should avoid using? Maybe look at bfgminer or poclbm in hope that they are less harmful to Bitcoin? I mean you often recommend people to not use other products and services for much less serious reasons. What if your own product can destroy Bitcoin?
There's always the third option. You know that I'm right, you just like to write a lot of words.
...
In the BitMinter thread I suggested rolling ntime in sync with the clock and reusing work, but you protested vehemently against any modification to ntime. And cgminer does indeed stick with the old (now inaccurate) ntime it got from the server. Yet you also said an inaccurate ntime is bad.
Riddle me this: How can a clock never change and yet be accurate?
Quote me Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.
... I wonder where I said that But please keep in mind that such an inaccurate ntime is bad for Bitcoin.
In the BitMinter thread I suggested rolling ntime in sync with the clock and reusing work, but you protested vehemently against any modification to ntime. And cgminer does indeed stick with the old (now inaccurate) ntime it got from the server. Yet you also said an inaccurate ntime is bad.
Riddle me this: How can a clock never change and yet be accurate?
To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.
That requires actually storing them all somewhere.You have to store the merkleroot and the extranonce2 bytes at least until you submit all proofs of work based on them. After that you could free them, but you will need to reallocate that memory to create new work in less than 1 second. It's better to keep those few bytes of memory sitting there until the server gives you new work, rather than constantly free and reallocate those tiny memory fragments.
Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.
... I wonder where I said that But please keep in mind that such an inaccurate ntime is bad for Bitcoin.
In the BitMinter thread I suggested rolling ntime in sync with the clock and reusing work, but you protested vehemently against any modification to ntime. And cgminer does indeed stick with the old (now inaccurate) ntime it got from the server. Yet you also said an inaccurate ntime is bad.
Riddle me this: How can a clock never change and yet be accurate?
To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.
Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.
... I wonder where I said that Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.
While this is true, I think a better rebuttal would be:
An average piece of work would only take ~10 SHA256 hashes to rebuild the merkleroot. The # of transactions in a block has to double to require each extra hash to build the merkleroot. Those ~10 SHA256 hashes produce 4.2 billion hashes worth of work. So if the chip implements nonce rolling internally, it would only decrease effective speed by ~0.000000238%.
In practice it's unlikely that nonce rolling will be implemented on the ASIC itself. It'd require much more complicated control logic than the actual mining core itself, and also enough fast RAM to store the merkle branch and potentially quite a large chunk of the coinbase transaction. Currently, people are looking at doing it on a seperate microcontroller which is obviously going to be a lot slower and somewhat memory-constrained.An average piece of work would only take ~10 SHA256 hashes to rebuild the merkleroot. The # of transactions in a block has to double to require each extra hash to build the merkleroot. Those ~10 SHA256 hashes produce 4.2 billion hashes worth of work. So if the chip implements nonce rolling internally, it would only decrease effective speed by ~0.000000238%.
To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.
That requires actually storing them all somewhere.
To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.
Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.
Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.
You can still roll the time once per second, starting the second nonce field all over again. It really isn't going to be an issue unless some dramatic new technology that doesn't even exist yet is thought up and developed and manufactured and released in the decades ahead. Quantum computers anyone?
Why only once a second? An ASIC is going to run through all nonces in far less than a second - why can't it roll ntime rapidly at least for a few seconds? No one cares if ntime is exact to the second, as long as it's roughly right.
The argument (I think) is that you'd have to rebuild the merkleroot with each extranonce, which requires extra work to either be done on the CPU, or on-board future ASICs (would be recommended, due to latency of relaying new work between the miner and the ASIC), meanwhile with ntime rolling there is no extra building of work, just increasing a secondary counter in the header.
While this is true, I think a better rebuttal would be:
An average piece of work would only take ~10 SHA256 hashes to rebuild the merkleroot. The # of transactions in a block has to double to require each extra hash to build the merkleroot. Those ~10 SHA256 hashes produce 4.2 billion hashes worth of work. So if the chip implements nonce rolling internally, it would only decrease effective speed by ~0.000000238%.
It really all comes down to how ASICs are designed. If they ever reach the 1 TH/s point in a single chip/set of chips (1 device as the miner software would see it), it could be an issue due to needing 250 pieces of work per second. A 1 ms latency of providing new work would mean the device is idle roughly 20% of the time since. Of course, I assume by that point the ASIC hardware would have more internal support for mining protocols to handle extranonce rolling+ntime.
You can still roll the time once per second, starting the second nonce field all over again. It really isn't going to be an issue unless some dramatic new technology that doesn't even exist yet is thought up and developed and manufactured and released in the decades ahead. Quantum computers anyone?
Why only once a second? An ASIC is going to run through all nonces in far less than a second - why can't it roll ntime rapidly at least for a few seconds? No one cares if ntime is exact to the second, as long as it's roughly right.
Jump to: