Mining downtime reduces time available to contribute work, but it does not necessarily reduce every expense by the same percentage. A device may be connected without hashing, or hashing without all its work being accepted. Define the operating state first, then compare time, contribution, energy and costs across the same period.
Rejected shares mean a pool did not count some submitted work under its acceptance rules. Reasons can differ, and a rejection percentage without its denominator or time window can mislead. Before changing firmware or performance settings, match the device record, pool definition, sample size and error messages. Then assess accepted contribution and energy over the same period.
A payout threshold helps determine when an internal mining-pool balance becomes eligible for transfer. It does not mean every reward displayed on a dashboard has already left the pool. Before calling a payment stuck, identify the balance type, threshold, schedule, destination and payment route. Each stage requires different evidence.
Mining pool payment methods determine how accepted work becomes a reward and how exposure to block-finding variation is distributed. Labels such as PPS, PPLNS, FPPS and PPS+ provide a starting point. A useful comparison also reads the service's current rules, fees, eligible-work window and payment schedule, then separates reward accounting from operating profit and custody risk.
A mining pool uses shares to account for contributed work. Shares are not a count of blocks added to Bitcoin, and their raw number does not necessarily establish which worker contributed more. Understand difficulty, acceptance and the observation period before connecting a counter to earned rewards or payments arriving in a wallet.