Effective Hash Rate Calculator
Turn observed shares and time into a measured hashrate. Solve E = (S / T) × D for any of its four unknowns — effective hash rate, shares accepted, observation window, or share difficulty — with step-by-step math and a clean mining-performance schematic.
Effective ≠ nominal hashrate
Your rig's nameplate hashrate is what the manufacturer quotes in a lab at ideal temperature and with a perfect pool connection. Effective hashrate is what your pool actually sees: rejected shares, stale shares, downtime, firmware throttling, thermal issues and network hiccups all reduce it. A healthy rig normally shows 95–99% of nameplate over a multi-day window; anything below 90% usually indicates a hardware, cooling or connectivity problem worth investigating.
Share difficulty is the bridge between shares and hashes
A share is not a hash — it is a lottery ticket whose difficulty is calibrated so that a given miner submits them at a manageable rate. To convert shares back to hashes you must multiply by the hashes each share represents. For Bitcoin-derived coins one difficulty-1 share ≈ 2³² hashes ≈ 4.295 gigahashes, so D scales directly with pool difficulty. If you enter the wrong D you will be off by exactly the ratio between the true and entered difficulties — a common source of 10× and 1,000× errors.
Longer windows are more accurate
Share arrivals are a Poisson process. Over a short window — a few minutes — the standard deviation of the share count is comparable to the mean, so the inferred hashrate can easily be off by tens of percent. The relative standard error scales as 1/√(S), so to get a hashrate accurate to 1% you need roughly 10,000 accepted shares in the window, and to get to 0.1% you need a million. This is why pools quote a 10-minute and a 24-hour hashrate: the short one is a live indicator, the long one is the truth.
Stale and rejected shares distort the estimate
If you plug submitted rather than accepted shares into S, you will over-estimate your effective hashrate — sometimes by several percent. A share is only real work if the pool has credited it. Many dashboards show submitted, accepted, stale and rejected counts separately; use accepted only. Some pools count "valid but stale" shares at a partial rate, in which case the correct S is the accepted count plus the fraction of stale shares the pool actually pays for.
How to Use This Calculator
The effective hash rate relation links four quantities: E, S, T and D. Choose which one you want the tool to solve, then fill in the other three.
1. Choose what to solve for
Pick E, S, T or D from the toggle. The calculator rearranges E = (S / T) · D automatically for whichever variable you select.
2. Read accepted shares from your pool
Copy the accepted-share count for a chosen window straight off your pool dashboard. Do not include stale or rejected shares. Presets cover 1K to 100M shares.
3. Match the window to the share count
The observation time T must be the same window the share count came from. Presets run from 1 minute to 30 days. Longer windows give more reliable hashrate estimates.
4. Enter your pool share difficulty
Most pools state the share difficulty in their help pages. Bitcoin-style difficulty-1 shares equal 4.295 GH/share; a difficulty-1000 share equals 4,295 GH/share. The hint below the field shows the equivalent Bitcoin difficulty.
5. Read the result and verdict
The result card shows the effective hash rate in GH/s plus equivalent kH/s, MH/s, TH/s, PH/s, and a share-rate breakdown. A colour-coded verdict classifies the hashrate from micro through industrial scale.
6. Switch to Advanced for depth
Advanced mode adds a hashrate-vs-time chart, a sensitivity check on a +1% input change, companion metrics including share rate and hashes per day, and a profitability snapshot with power cost.
What This Tool Offers
Built around the classic effective-hashrate relation E = (S / T) · D — the direct link between observed shares, time, difficulty and delivered hashrate.
Four-way solving
Solve for effective hash rate, shares accepted, observation time, or share difficulty. The calculator rearranges the formula for whichever you choose.
Live measurement schematic
A shares-to-time-to-difficulty-to-hashrate diagram that redraws its labels and values as you change the inputs.
Hashrate-class verdict
Each result is classified from micro (CPU) through GPU, ASIC, rig, small farm, mid farm and industrial scale, with a coloured badge.
Multi-unit readouts
Every result is echoed in H/s, kH/s, MH/s, GH/s, TH/s and PH/s, plus shares per second, per minute, per hour and per day.
Dual comparison charts
Effective hash rate vs. shares accepted for three observation windows, plus an advanced hashrate vs. time chart for three share counts.
Reference tables & profitability
A hashrate unit converter, a share-difficulty lookup table, typical pool difficulty values, a variable reference and a power-cost profitability snapshot.
Reference Tables & Conversions
A hashrate unit converter, a profitability snapshot, a share-difficulty lookup grid, and typical pool parameters.
Hashrate unit converter
Profitability snapshot
Effective Hash Rate Lookup Grid
Computed from E = (S / T) · D using the share difficulty currently entered above. Values are GH/s.
Typical Pool Share Difficulty
Representative values. Pool share difficulty changes over time and is often tuned so that a miner submits shares every few seconds.
| Pool / coin | Share difficulty | GH per share | Notes |
|---|---|---|---|
| Bitcoin — typical pool | 1,000 – 10,000 | 4,295 – 42,950 GH | Tuned so mid-size miners submit every few seconds |
| Bitcoin — small miner | 1 – 100 | 4.295 – 429.5 GH | Low-diff shares for slow miners |
| Litecoin (Scrypt) | 1 – 16,384 | 4.295 – 70,370 GH | Scrypt pools often use variable diff |
| Dogecoin (merged) | 1 – 16,384 | 4.295 – 70,370 GH | Merged-mined with Litecoin |
| Monero (RandomX) | 1 – 50,000 | 4.295 – 214,750 GH | Higher diff for CPU miners |
| Ravencoin (KawPow) | 1 – 8,000 | 4.295 – 34,360 GH | GPU-oriented difficulty |
| Ethereum Classic | 1 – 4,000 | 4.295 – 17,180 GH | GPU-oriented difficulty |
| Bitcoin Cash | 1,000 – 10,000 | 4,295 – 42,950 GH | Same SHA-256 convention as BTC |
Variable Reference
| Symbol | Meaning | Typical range | Units |
|---|---|---|---|
| E | Effective hash rate | 0.001 – 1,000,000 | GH/s |
| S | Shares accepted | 1 – 10⁹ | shares |
| T | Observation time | 1 – 10⁷ | seconds |
| D | Share difficulty (hashes per share) | 0.0001 – 10⁴ | GH/share |
| 2³² | Hashes per difficulty-1 share | ≈ 4.295 × 10⁹ | hashes |
| sps | Shares per second | 0.001 – 10⁶ | shares/s |
| σrel | Relative standard error of E | 1 / √S | dimensionless |
What Does E = (S / T) · D Measure?
The effective hash rate relation turns raw share counts into a measured hashrate. Pools know the difficulty at which each miner submits shares, and they know the time elapsed, so the product (shares ÷ time) × difficulty is the hashing power the miner demonstrated over that window. It is the same calculation every pool dashboard performs to produce the number labelled "reported" or "effective" hashrate, and it is the only hashrate that matters for payout — nameplate numbers count for nothing if the shares never arrive.
The Effective Hash Rate Formula
The defining relationship is:
Rearranged to solve for the other three unknowns:
T = S · D ÷ E
D = E · T ÷ S
The relation is linear in shares and difficulty, and inverse-linear in time. Doubling the shares you submitted in the same window doubles the inferred hashrate; doubling the window at the same share count halves it.
Effective Hash Rate Variables
| Symbol | Meaning | Notes |
|---|---|---|
| E | Effective hash rate | Delivered hashrate as seen by the pool; measured, not nameplate |
| S | Shares accepted | Only shares the pool credited count; exclude stales and rejects |
| T | Observation time | Wall-clock window matched to the share count |
| D | Share difficulty | Hashes represented by one accepted share |
| 2³² | Difficulty-1 constant | ≈ 4.295 × 10⁹ hashes; the bridge from difficulty to hashes |
| σrel | Relative standard error | 1 / √S; falls as more shares are counted |
How Each Variable Affects the Estimate
Shares accepted is the raw signal. Its precision improves with count: to infer a hashrate accurate to 1% you need about 10,000 accepted shares in the window; for 0.1% you need a million. This is why a pool's "10-minute hashrate" jumps around while its "24-hour hashrate" is stable — the long window contains far more shares, so the Poisson noise averages out. Any single-share hiccup, thermal throttle or reconnect shows up disproportionately in a short window.
Observation time is the denominator, so it must match the share count exactly. If your dashboard reports a share count for "the last hour" but you enter 86,400 seconds, you will under-estimate your hashrate by 24×. When in doubt, use the longest consistent window your pool exposes — many pools show a 24-hour and a lifetime figure, and the lifetime number (with lifetime shares and lifetime time) is the single most reliable estimate of your true delivered hashrate.
Share difficulty is the scaling constant that converts tickets into hashes. Get it wrong and the result is wrong by the same factor. Bitcoin-style pools express difficulty in units where difficulty 1 = 2³² hashes ≈ 4.295 gigahashes. Some newer pools use a different unit (for example, "network difficulty" or a per-algorithm scale), so it is always worth confirming the convention before using the number. The hint under the difficulty field shows the equivalent Bitcoin difficulty as a sanity check.
Comparing effective to nameplate hashrate is the single most useful diagnostic you can run on a rig. A rig showing 97–99% of nameplate over 24 hours is healthy. A rig showing 90% has a cooling or firmware problem. A rig showing 60% is either throttling badly, submitting a high fraction of stale shares, or is being starved by a network or pool-side issue. Fixing that gap is usually worth more than any overclock.
Effective Hash Rate Calculation Examples
E = (1,000,000 / 86,400) × 4.295 = 11.574 × 4.295 = 49.71 GH/s
S = 49.71 × 86,400 ÷ 4.295 = 1,000,000 shares
T = 1,000,000 × 4.295 ÷ 49.71 = 86,400 s (24 hours)
D = 49.71 × 86,400 ÷ 1,000,000 = 4.295 GH/share (Bitcoin difficulty 1)
E = (250,000 / 21,600) × 4,295 = 11.574 × 4,295 = 49,710 GH/s = 49.71 TH/s
Frequently Asked Questions
Because nameplate hashrate is measured in a lab at ideal temperature with no pool connection, and effective hashrate is measured in the real world. The usual culprits are: thermal throttling (the rig runs hotter than the lab and the firmware reduces clocks), stale shares (work submitted after the pool has moved on to a new block, so it goes unpaid), rejected shares (the pool refused work, often due to overclock-induced errors), network latency (shares arrive late), pool downtime, and firmware or driver overheads. A rig at 95–99% of nameplate is healthy; 90% suggests a fixable problem; below 85% is a real issue. Check temperatures first, then pool-side stale/reject rates, then network.
For Bitcoin and all SHA-256 derived pools, multiply the pool difficulty by 2³² hashes, then divide by 10⁹ to get gigahashes. Since 2³² ÷ 10⁹ ≈ 4.295, a difficulty-1 share represents 4.295 GH, a difficulty-100 share represents 429.5 GH, a difficulty-1000 share represents 4,295 GH, and so on. Some pools and coins use a different scaling — for example, some GPU coins define difficulty 1 differently — so always check the pool's own documentation. The tooltip and hint under the difficulty field will show the equivalent Bitcoin difficulty for whatever value you enter, which is a useful cross-check.
Share arrivals follow a Poisson distribution, so the relative standard error of the share count is 1/√S. That means 100 shares gives a 10% standard error, 10,000 shares gives 1%, 1,000,000 shares gives 0.1%, and 100,000,000 shares gives 0.01%. For a quick check, a few thousand shares is plenty. For a precise diagnosis of a rig you want at least a full day of data, ideally a week. Note that the estimate is also biased by non-Poisson effects — pool downtime, scheduled maintenance, thermal drift — so even a million shares will not fix a rig that throttles overnight.
Always accepted shares. Submitted includes stale and rejected shares, which represent work that the pool has not credited and that therefore did not contribute to your payout. Plugging submitted shares into S will over-estimate your effective hashrate — sometimes by 5% or more on a poorly tuned rig. Most pool dashboards show the breakdown separately: accepted, stale, rejected. Add stales to accepted only if your pool pays a partial rate for stale shares, and in that case add only the fraction the pool actually pays for.
Three reasons. First, window length: the pool's "current" or "10-minute" hashrate uses a much shorter window than your 24-hour calculation, so it will be noisier and will not necessarily match. Compare like with like. Second, difficulty conventions: if the pool counts shares at a different difficulty than the one you entered, the hashrate will scale by the ratio. Third, timing: the pool may use a sliding window (for example "last 600 shares") rather than a fixed time window, which produces a slightly different number from the same underlying data. Over a long enough window all reasonable methods converge to the same value.
Yes — this is one of the most useful applications. Run the calculation per card or per board using its individual share count over the same window, then compare to the same card's earlier value or to the pool's nominal expectation. A card that drops by more than a few percent while the others stay flat is developing a problem: a failing fan, dried thermal paste, a degraded memory chip, or an unstable overclock. Because the estimate scales linearly with shares, a 5% drop in share count at constant difficulty and time means a 5% drop in delivered hashrate, which is usually enough to justify pulling the card for maintenance.
Share difficulty itself does not change your long-run payout — a share at difficulty 1000 represents 1000× the work of a difficulty-1 share, and the pool pays accordingly, so total income is the same. What difficulty does affect is the granularity and variance of your income: higher difficulty means fewer, larger shares, so your per-share payments are lumpier and your dashboard readings are noisier over short windows. Most pools use variable difficulty, raising your share difficulty as your hashrate grows, to keep the share submission rate roughly constant across miners and to keep pool-side bookkeeping cheap.
Reported hashrate is what your mining software says it is doing — it is the software's own estimate based on the work it has dispatched. Effective hashrate is what the pool actually sees, derived from accepted shares. The two should agree within a few percent; a large gap usually means shares are being lost between your miner and the pool, whether through network issues, pool rejections, or a client-side bug. Some pools and monitoring tools also display a "calculated" or "average" hashrate, which is the same effective calculation over a longer window.
Variables
| Symbol | Quantity | Unit |
|---|---|---|
| Effective Hash Rate | Measured effective hash rate | H/s |
| Valid Shares Submitted | Number of valid shares submitted | |
| Time | Time period measured | s |
| Difficulty Constant | Mining difficulty scaling constant |
What it means
The effective hash rate is derived from the number of valid shares submitted over time and the network difficulty. It may differ from the reported hash rate due to latency, stale shares, and hardware efficiency. This is used to monitor mining rig performance and to diagnose issues. A low effective hash rate may indicate connectivity or hardware problems. Understanding this helps miners optimise their setups and to ensure they are getting the expected return. It is a practical metric for mining operations.
Worked example
Effective Hash Rate – Two Detailed Examples
Real‑World| Parameter | Value |
|---|---|
| Valid Shares | 720 |
| Time (hours) | 1 |
| Parameter | Value |
|---|---|
| Valid Shares | 500 |
| Time | 1 |
Common mistakes
- Valid shares submitted: The number of shares that meet the current difficulty target.
- Time: The duration over which shares were submitted.
- Difficulty constant: A network‑specific factor to convert shares to hash rate.
- Effective hash rate: May differ from reported due to luck and variance.
Applications
Effective hash rate is calculated from the number of valid shares submitted and the difficulty constant, providing a measure of the miner's actual performance. This is used to monitor mining rig health and efficiency. By comparing the effective hash rate with the nominal hash rate, miners can detect issues such as overheating or overclocking instability. This metric is also used by pools to allocate rewards. Understanding effective hash rate helps miners optimise their equipment and maximise profitability.
- Monitoring mining rig performance and stability
- Detecting hardware issues or thermal throttling
- Comparing actual vs. expected hash rate
- Optimising overclocking and power settings
- Troubleshooting mining operations
Related calculators · Mining & Blockchain
Recently updated formulas
Suggest an improvement
Found a mistake? Have a better example? Let us know.
You may send up to 3 suggestions per 24 hours.