why cgminer increases "nonce2" and "ntime" every 5 seconds ?

[Skot]

if cgminer has absolutely nothing to do with the nonce  then who does? does the hardware miner have a routine to run through the nonce range - is it triggered by cgminer in some way? weird

The mining chip (ASIC) increments the nonce after each hash. Hundreds of billions of times a second.

AFAIK it starts at 0 and goes up to 2^32 unless you configure it to start somewhere else. This takes less than a second.

It’s kinda crazy to think about; the fastest CPUs out there wouldn’t even be able to increment the nonce as fast as an ASIC, much less do any actual hashing.

[1715218220]

1715218220

[1715218220]

1715218220

[NotFuzzyWarm]

It’s kinda crazy to think about; the fastest CPUs out there wouldn’t even be able to increment the nonce as fast as an ASIC, much less do any actual hashing

Huge difference between any CPU/GPU and a mining ASIC -- the number of cores in them. A top-end CPU might have what, 48 cores in it?

The s17 mining ASIC has 8192 cores in the 1 chip and each core handles 1 part of the range being ran through so with each clock cycle a block of up to 8192 values are processed at 1 time. Add in the fact that most large miners will have 100-200 ASICs in them and that's how they achieve such incredible performance.

It should be noted that it is rare for all of the cores to be usable and often a chip will have many dead ones. That is part of the difference between the fastest (and most expensive) miners and their slightly slower and cheaper brethren - the fastest/most expensive are using chips that are binned (selected) as most functional cores and those make up a rather small % of usable dies from each wafer. The lower number of perfect/near-perfect ones allows them to be priced at a premium.

[kano]

'nonce' has nothing to do with this part, cgminer has nothing to do with the nonce ranges.

if cgminer has absolutely nothing to do with the nonce  then who does? does the hardware miner have a routine to run through the nonce range - is it triggered by cgminer in some way? weird

The nonce range is dependent upon a combination of few things.

A) As Fuzzy mentioned above

B) How work is queued in the physical miner.

b1) You can't always divide 2^32 evenly with the number of chips and the number of cores.
So some values may not be used because of this.

b2) If we are talking about a small miner, there may be no work queue inside the hardware, so the miner must have it's work refreshed by cgminer, before it reaches 2^32, so it doesn't repeat doing the same work again from the start.
Thus. timing here will mean that all sub-ranges that are divided up among the chips, would rarely if ever complete.

Be aware of the obvious fact that you don't need to mine the full range.
It makes absolutely no statistical difference if you stop a range before it completes and start again from the bottom with new work.
As I mentioned

It does not matter what the asic nonce range is. The only point of interest is for the asics to test a high % of the range to minimise work I/O to the asic.

[sidehack]

Fuzzy, the S17 chip has 672 cores. Interestingly, the chip actually has four blocks of 168 cores each built in series within the die.

[Skot]

Fuzzy, the S17 chip has 672 cores. Interestingly, the chip actually has four blocks of 168 cores each built in series within the die.

That would make sense then how it can do hundreds of GH/s with a clock of only hundreds of MHz

[NotFuzzyWarm]

Fuzzy, the S17 chip has 672 cores. Interestingly, the chip actually has four blocks of 168 cores each built in series within the die.

Interesting - I'd swear I've come across infor with it being over 8k of them. The Bitfury's in the Apollo has 4k of them per Bitfury's spec and the A1 (2014) had 1024 cores. Most odd.

[sidehack]

Bitfury are rolled cores, so multiple clocks per calculation. Bitmain's always used unrolled cores, which take up a lot more die space but do the whole hash in a single cycle. BM1384 has 55 cores, 1387 has 114 cores.