Hi n0nce,
it is just for education purposes, trying to understand and fiddling in the code.
Topic: why cgminer increases "nonce2" and "ntime" every 5 seconds ? - page 2. (Read 467 times)
Meanwhile while exploring the debug log, I have recognized that not only ntime is being flipped each 5 seconds but also the incrementing nonce2 is being reset after the 5 secs.
Where does the 5 seconds come from ? any help appreciated.
Yup, it makes sense that the nonce is reset once you have a new block template with updated timestamp, right? Where does the 5 seconds come from ? any help appreciated.
I'm happy you found the code segment, though; but it leaves me curious what you need it for. Are you trying to mess with the 'reset timeout'? If so, why?
I know that it represents the timestamp in UNIX time format. But I would like to understand where in the program code the 5 seconds are pulled from. I can't find the corresponding place in cgminer.c
EDIT: Meanwhile while exploring the debug log, I have recognized that not only ntime is being flipped each 5 seconds but also the incrementing nonce2 is being reset after the 5 secs.
Where does the 5 seconds come from ? any help appreciated.
EDIT2:
SOLVED Found it!
It comes from block
in line 9364
EDIT: Meanwhile while exploring the debug log, I have recognized that not only ntime is being flipped each 5 seconds but also the incrementing nonce2 is being reset after the 5 secs.
Where does the 5 seconds come from ? any help appreciated.
EDIT2:
SOLVED Found it!
It comes from block
Code:
static void *watchpool_thread(void __maybe_unused *userdata)
{
...
}
in line 9364
Code:
cgsleep_ms_r(&cgt, 5000);
NTime is just a unix timestamp.
You can take the 63667f00 or 63667f05 ntimes, convert from hex to decimal and put it into https://www.unixtimestamp.com/ to check what dates those refer to.
I suppose cgminer creates a new block template with updated timestamp only once every 5 seconds to reduce overhead; especially since the timestamp in Bitcoin's block header doesn't have to be very accurate, anyway.
You can take the 63667f00 or 63667f05 ntimes, convert from hex to decimal and put it into https://www.unixtimestamp.com/ to check what dates those refer to.
Code:
$ python3 -c 'print(int("63667f00", 16))'
1667661568
Quote from: https://www.unixtimestamp.com/
GMT Sat Nov 05 2022 15:19:28 GMT+0000
Code:
$ python3 -c 'print(int("63667f05", 16))'
1667661573
Quote from: https://www.unixtimestamp.com/
GMT Sat Nov 05 2022 15:19:33 GMT+0000
I suppose cgminer creates a new block template with updated timestamp only once every 5 seconds to reduce overhead; especially since the timestamp in Bitcoin's block header doesn't have to be very accurate, anyway.
Hi Snowy Pear,
thank you for creating an extra new account to reply to me. I looked into submit_noffset_nonce, but I just couldn't manage to change ntime variation to a different value every 5 seconds or turn it off briefly for testing. I even tried test turning off all of the following functions by commenting those functions: modify_ntime, roll_work, roll_work_ntime and everywhere else where noffset occurs (including the references to it, of course). After a "make" and restarting the program in debug mode, the ntime is still incremented every 5 seconds.
I don't understand your quoting. I hope you don't confuse my question with the 5 sec which is the default setting for page rendering? Because cgminer automatically refreshes the status page every 5 seconds. But that's not my point at all. I related my question exclusively to the counting up ntime.
Where does it get this info, if I have disabled everything in cgminer.c regarding noffset? And why 5 seconds, where does it get this value = 5sec ?
thank you for creating an extra new account to reply to me. I looked into submit_noffset_nonce, but I just couldn't manage to change ntime variation to a different value every 5 seconds or turn it off briefly for testing. I even tried test turning off all of the following functions by commenting those functions: modify_ntime, roll_work, roll_work_ntime and everywhere else where noffset occurs (including the references to it, of course). After a "make" and restarting the program in debug mode, the ntime is still incremented every 5 seconds.
I don't understand your quoting. I hope you don't confuse my question with the 5 sec which is the default setting for page rendering? Because cgminer automatically refreshes the status page every 5 seconds. But that's not my point at all. I related my question exclusively to the counting up ntime.
Quote
[2022-11-05 16:19:28.314] Work nonce2 0 ntime 63667f00
[2022-11-05 16:19:33.319] Work nonce2 0 ntime 63667f05
[2022-11-05 16:19:33.319] Work nonce2 0 ntime 63667f05
Where does it get this info, if I have disabled everything in cgminer.c regarding noffset? And why 5 seconds, where does it get this value = 5sec ?
Can someone explain to me what this is all about and where in the source code these 5 seconds were set. Why is a new ntime being pulled in every 5 seconds? Thanks in advance.
You can adjust the ntime binary data in submit_noffset_nonce or resubmit to be able to pull the stratum split every 5 seconds to 2 minutes.You can see here https://bitcointalksearch.org/topic/official-cgminer-mining-software-thread-for-linuxwinosxmipsarmr-pi-4110-28402, for more clarity.
Code:
The output line shows the following:
(5s):223.5G (avg):219.6Gh/s | A:330090 R:0 HW:6904 WU:3027.6/m
Each column is as follows:
5s: A 5 second exponentially decaying average hash rate
avg: An all time average hash rate
A: The number of Accepted shares
R: The number of Rejected shares
HW: The number of HardWare errors
WU: The Work Utility defined as the number of diff1 equivalent shares / minute
AVA 0: 23C/ 47C 2280R | 77.10G/83.20Gh/s | A:120029 R:0 HW:2295 WU:1162.5/m
Each column is as follows:
Temperature (if supported)
Fanspeed (if supported)
A 5 second exponentially decaying average hash rate
An all time average hash rate
The number of accepted shares
The number of rejected shares
The number of hardware erorrs
The Work Utility defined as the number of diff1 equivalent shares / minute
Hello everbody,
i have a few questions about the mining process related to cgminer. I did read this and that.
Following is an excerpt example of cgminer mining on mainnet (against bitcoind @localhost) with a GekkoScience Compac F USB miner at an average hash rate of 387 GH/s. I have shortened/masked the long values for clarity.
The nonce range is 0 to 2^32-1 (0-4294967295) which we could express simply as 4.3G
If I am not wrong, this USB miner at the hash rate of 387 GH/s should be able to run the whole nonce range in 1/90th second. Or in other words: it should be able to run 90x per second through the whole nonce range. So far correct ?
If I understand it correctly, then the process looks like this with the respective hash attempts after a block header is formed:
- the entire nonce range is tested by starting at nonce value and incrementing by one to the upper limit of 4294967295
- if no hash could be calculated which was below the target, then nonce2 (also called extranonce) can be changed. This is arbitrary random data which changes the coinbase transaction slightly (new Merkle root). Now we have millions of additional tries to find a good hash. If even that did not lead to success....
- then you can also vary with the ntime. This is the integer timestamp in seconds. Every second ntime is increased by one. Ntime can be changed locally but the limits are fixed here, you can't go back or forward arbitrarily, because that would not be accepted by the chain. Somewhere I had read that plus minus 10min would be allowed, is that true? I was not able to find it quickly by searching the net. Please refer me to the appropriate page so I can read through the limits and the detailed process for ntime.
In the example shown, you can clearly see how nonce2 is incrementally increased while ntime remains constant. But what I don't understand is: after exactly 5 seconds ntime is increased, although you could actually change nonce2 further.
Where does this come from, why is this done? I have searched through the source code cgminer.c, but I can't find any reference to these 5 seconds that I could find in the debug log as shown in the example above. In the source code there are definitions where ntime rolling can be set to 60 seconds or something like that, but no trace of 5 seconds.
Can someone explain to me what this is all about and where in the source code these 5 seconds were set. Why is a new ntime being pulled in every 5 seconds? Thanks in advance.
i have a few questions about the mining process related to cgminer. I did read this and that.
Following is an excerpt example of cgminer mining on mainnet (against bitcoind @localhost) with a GekkoScience Compac F USB miner at an average hash rate of 387 GH/s. I have shortened/masked the long values for clarity.
Code:
[2022-11-05 16:19:28.299] Work nonce2 1257 ntime 63667efb
[2022-11-05 16:19:28.299] Generated GBT SOLO work
[2022-11-05 16:19:28.299] Pushing work from pool 0 to hash queue
[2022-11-05 16:19:28.306] Discarded work
[2022-11-05 16:19:28.306] Selecting pool 0 for work
[2022-11-05 16:19:28.306] Generated GBT solo merkle 1111aaaa...
[2022-11-05 16:19:28.306] Generated GBT solo header 200000001111aaaa
[2022-11-05 16:19:28.306] Work nonce2 1258 ntime 63667efb
[2022-11-05 16:19:28.306] Generated GBT SOLO work
[2022-11-05 16:19:28.306] Pushing work from pool 0 to hash queue
[2022-11-05 16:19:28.306] Popping work from get queue to get work
[2022-11-05 16:19:28.306] Got work from get queue to get work for thread 0
[2022-11-05 16:19:28.306] Selecting pool 0 for work
[2022-11-05 16:19:28.306] Generated GBT solo merkle 2222bbbb...
[2022-11-05 16:19:28.306] Generated GBT solo header 20000000...2222bbbb...
[2022-11-05 16:19:28.306] Work nonce2 1259 ntime 63667efb
[2022-11-05 16:19:28.306] Generated GBT SOLO work
[2022-11-05 16:19:28.306] Pushing work from pool 0 to hash queue
[2022-11-05 16:19:28.309] previousblockhash: 000000000000000000067944108e1b9ecfc1f250a6cb33d4d63de8be70c23733
[2022-11-05 16:19:28.309] target: 00000000000000000007a4290000000000000000000000000000000000000000
[2022-11-05 16:19:28.309] version: 536870912
[2022-11-05 16:19:28.309] curtime: 1667661568
[2022-11-05 16:19:28.309] bits: 1707a429
[2022-11-05 16:19:28.309] height: 761845
[2022-11-05 16:19:28.309] flags: (null)
[2022-11-05 16:19:28.310] MH0 abcdef123456789abcdef1111123...
[2022-11-05 16:19:28.310] MH1 bcdef123456789...
[2022-11-05 16:19:28.310] MH2 cdef1234567890...
[2022-11-05 16:19:28.310] MH3 def8178975438974593...
[2022-11-05 16:19:28.310] MH4 cc33dd....
[2022-11-05 16:19:28.310] MH5 11dac36188991a89789b3c00c...
[2022-11-05 16:19:28.310] MH6 817367f93890a87983...
[2022-11-05 16:19:28.310] MH7 92c8ca781ff10...
[2022-11-05 16:19:28.310] Stored 1417 transactions from pool 0
[2022-11-05 16:19:28.310] calculated witness data: abcdef123456789abcdef012345...
[2022-11-05 16:19:28.310] Successfully retrieved and deciphered work from pool 0 http://localhost:8332
[2022-11-05 16:19:28.310] Solo mining to valid address: bc1qf8d71b...
[2022-11-05 16:19:28.310] Pool 0 coinbase 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff...
[2022-11-05 16:19:28.314] Discarded work
[2022-11-05 16:19:28.314] Selecting pool 0 for work
[2022-11-05 16:19:28.314] Generated GBT solo merkle 111111aaaaaa
[2022-11-05 16:19:28.314] Generated GBT solo header 20000000...111111aaaaaa...
[2022-11-05 16:19:28.314] Work nonce2 0 ntime 63667f00
[2022-11-05 16:19:28.314] Generated GBT SOLO work
[2022-11-05 16:19:28.314] Pushing work from pool 0 to hash queue
[2022-11-05 16:19:28.315] Popping work from get queue to get work
[2022-11-05 16:19:28.315] Got work from get queue to get work for thread 0
[2022-11-05 16:19:28.315] Selecting pool 0 for work
[2022-11-05 16:19:28.315] Generated GBT solo merkle 222222bbbbbb
[2022-11-05 16:19:28.315] Generated GBT solo header 20000000...111111aaaaaa...
[2022-11-05 16:19:28.315] Work nonce2 1 ntime 63667f00
[2022-11-05 16:19:28.315] Generated GBT SOLO work
[2022-11-05 16:19:28.315] Pushing work from pool 0 to hash queue
[2022-11-05 16:19:28.321] Discarded work
[2022-11-05 16:19:28.321] Selecting pool 0 for work
[2022-11-05 16:19:28.321] Generated GBT solo merkle 333333cccccc
[2022-11-05 16:19:28.321] Generated GBT solo header 20000000...333333cccccc...
[2022-11-05 16:19:28.321] Work nonce2 2 ntime 63667f00
[2022-11-05 16:19:28.321] Generated GBT SOLO work
[2022-11-05 16:19:28.321] Pushing work from pool 0 to hash queue
[2022-11-05 16:19:28.322] Popping work from get queue to get work
[2022-11-05 16:19:28.322] Got work from get queue to get work for thread 0
[2022-11-05 16:19:28.322] Selecting pool 0 for work
[2022-11-05 16:19:28.322] Generated GBT solo merkle 444444dddddd
[2022-11-05 16:19:28.322] Generated GBT solo header 20000000...444444dddddd...
[2022-11-05 16:19:28.322] Work nonce2 3 ntime 63667f00
[2022-11-05 16:19:28.322] Generated GBT SOLO work
[2022-11-05 16:19:28.322] Pushing work from pool 0 to hash queue
[2022-11-05 16:19:28.329] Discarded work
[...]
[2022-11-05 16:19:33.312] Selecting pool 0 for work
[2022-11-05 16:19:33.312] Generated GBT solo merkle fed987...
[2022-11-05 16:19:33.312] Generated GBT solo header 2000000070...fed987...
[2022-11-05 16:19:33.312] Work nonce2 1276 ntime 63667f00
[2022-11-05 16:19:33.312] Generated GBT SOLO work
[2022-11-05 16:19:33.312] Pushing work from pool 0 to hash queue
[2022-11-05 16:19:33.312] Popping work from get queue to get work
[2022-11-05 16:19:33.312] Got work from get queue to get work for thread 0
[2022-11-05 16:19:33.312] Selecting pool 0 for work
[2022-11-05 16:19:33.312] Generated GBT solo merkle bbb555...
[2022-11-05 16:19:33.312] Generated GBT solo header 2000000070...bbb555...
[2022-11-05 16:19:33.312] Work nonce2 1277 ntime 63667f00
[2022-11-05 16:19:33.312] Generated GBT SOLO work
[2022-11-05 16:19:33.312] Pushing work from pool 0 to hash queue
[2022-11-05 16:19:33.316] previousblockhash: 000000000000000000067944108e1b9ecfc1f250a6cb33d4d63de8be70c23733
[2022-11-05 16:19:33.316] target: 00000000000000000007a4290000000000000000000000000000000000000000
[2022-11-05 16:19:33.316] version: 536870912
[2022-11-05 16:19:33.316] curtime: 1667661573
[2022-11-05 16:19:33.316] bits: 1707a429
[2022-11-05 16:19:33.316] height: 761845
[2022-11-05 16:19:33.316] flags: (null)
[2022-11-05 16:19:33.316] MH0 aa11bb22...
[2022-11-05 16:19:33.316] MH1 cc55aa31...
[2022-11-05 16:19:33.316] MH2 85bc1ac3...
[2022-11-05 16:19:33.316] MH3 7c4e01ac...
[2022-11-05 16:19:33.316] MH4 e3f987af...
[2022-11-05 16:19:33.316] MH5 1a8c3d22...
[2022-11-05 16:19:33.316] MH6 d6c55331...
[2022-11-05 16:19:33.316] MH7 e499375c...
[2022-11-05 16:19:33.316] MH8 a6d2b1c5...
[2022-11-05 16:19:33.316] Stored 2279 transactions from pool 0
[2022-11-05 16:19:33.317] calculated witness data: aa22bb33bb44bb5bb6b7b8b9b15c567...
[2022-11-05 16:19:33.317] Successfully retrieved and deciphered work from pool 0 http://localhost:8332
[2022-11-05 16:19:33.318] Solo mining to valid address: bc1qf8d71b...
[2022-11-05 16:19:33.318] Pool 0 coinbase Pool 0 coinbase 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff...
[2022-11-05 16:19:33.319] Discarded work
[2022-11-05 16:19:33.319] Selecting pool 0 for work
[2022-11-05 16:19:33.319] Generated GBT solo merkle 55bb44cc...
[2022-11-05 16:19:33.319] Generated GBT solo header 200000007055bb44cc...
[2022-11-05 16:19:33.319] Work nonce2 0 ntime 63667f05
[2022-11-05 16:19:33.319] Generated GBT SOLO work
[2022-11-05 16:19:33.319] Pushing work from pool 0 to hash queue
[2022-11-05 16:19:33.320] Popping work from get queue to get work
[...]
The nonce range is 0 to 2^32-1 (0-4294967295) which we could express simply as 4.3G
If I am not wrong, this USB miner at the hash rate of 387 GH/s should be able to run the whole nonce range in 1/90th second. Or in other words: it should be able to run 90x per second through the whole nonce range. So far correct ?
If I understand it correctly, then the process looks like this with the respective hash attempts after a block header is formed:
- the entire nonce range is tested by starting at nonce value and incrementing by one to the upper limit of 4294967295
- if no hash could be calculated which was below the target, then nonce2 (also called extranonce) can be changed. This is arbitrary random data which changes the coinbase transaction slightly (new Merkle root). Now we have millions of additional tries to find a good hash. If even that did not lead to success....
- then you can also vary with the ntime. This is the integer timestamp in seconds. Every second ntime is increased by one. Ntime can be changed locally but the limits are fixed here, you can't go back or forward arbitrarily, because that would not be accepted by the chain. Somewhere I had read that plus minus 10min would be allowed, is that true? I was not able to find it quickly by searching the net. Please refer me to the appropriate page so I can read through the limits and the detailed process for ntime.
In the example shown, you can clearly see how nonce2 is incrementally increased while ntime remains constant. But what I don't understand is: after exactly 5 seconds ntime is increased, although you could actually change nonce2 further.
Where does this come from, why is this done? I have searched through the source code cgminer.c, but I can't find any reference to these 5 seconds that I could find in the debug log as shown in the example above. In the source code there are definitions where ntime rolling can be set to 60 seconds or something like that, but no trace of 5 seconds.
Can someone explain to me what this is all about and where in the source code these 5 seconds were set. Why is a new ntime being pulled in every 5 seconds? Thanks in advance.
Jump to: