High Latency to Bitmern Solo Stratum

High Latency to Bitmern Solo Stratum

The hostname resolves. The session often connects. Yet jobs feel late, firmware complains about laggy responses, or shares start feeling “stale” because the path to Bitmern Solo stratum is slow or noisy — high RTT, congested Wi-Fi, a half-open VPN, or a long detour through the wrong network hop.

If your Bitaxe or home ASIC shows high latency / laggy stratum behavior on Bitmern Solo, run an ordered network-path checklist: confirm the string is already correct (btc.bitmernsolo.com:3132 for BTC easy-start, WALLET.worker / x), prefer a clean LAN path (Ethernet over flaky Wi-Fi when you can), remove VPN / proxy detours, clear guest-SSID and soft firewall noise, re-apply on the primary slot, then prove fresh accepts on the matching coin tab. Never treat :3102 as the Bitaxe / home default. This post does not invent millisecond thresholds or Bitmern Solo product latency SLAs.

This is the high-latency / laggy-jobs lane. Link type vs radio noise: Ethernet vs Wi-Fi. Tunnel on the path: VPN / proxy stratum fix. Shares already stale: stale shares fix. Hung connect / timeout: stratum timeout fix. Session flaps after connect: reconnect loops fix.

Bitmern Solo is solo infrastructure: flat 1% fee on finds only, you keep 99%. Fee context stays light here — the job is cleaning the network path so jobs arrive in time for useful work.

High latency ≠ Wi-Fi choice ≠ VPN ≠ stale shares ≠ timeout ≠ reconnect loops

Six patterns get mixed up:

1. High latency / laggy stratum — session may connect, but RTT / path delay makes jobs feel late and work less reliable. That is this post.
2. Ethernet vs Wi-Fi — radio noise and guest SSIDs as the link-type problem. Use Ethernet vs Wi-Fi.
3. VPN / proxy on the path — tunnel routes or mutates stratum. Use VPN / proxy stratum fix.
4. Stale shares — work already late enough to reject as stale. Use stale shares fix.
5. Stratum timeout / hung connect — session never completes. Use stratum timeout fix.
6. Reconnect loops — session connects then flaps. Use reconnect loops.

Do not invent a Bitmern Solo “ideal ping under N ms” product SLA, a guaranteed latency budget, or a claim that the pool “always answers in N milliseconds.” The product facts that matter: per-coin hosts (for BTC, btc.bitmernsolo.com), BTC easy-start :3132, username WALLET.worker, password x.

What usually looks like “pool lag” when the path is slow

Common high-latency desks on Bitaxe-class and small ASIC setups:

1. Congested or distant Wi-Fi — board associates; phone browses; miner RTT spikes under load (Ethernet vs Wi-Fi).
2. VPN / “smart” proxy leftovers — tunnel “off” in the UI but traffic still hairpins (VPN / proxy).
3. Guest / client-isolation SSID — soft path delays that feel like lag rather than a clean deny.
4. Wrong host / port still in play — operators blame latency while still on :3102 or a non-coin host.
5. Failover flapping — primary Bitmern Solo; secondary elsewhere; path never settles long enough for stable jobs.
6. Upstream ISP / CGNAT noise — intermittent delay that looks like “pool lag” from the miner’s point of view.
7. Latency already turned into stales — if rejects are already stale-coded, also walk stale shares fix.

Separate these from a session that never connects (stratum timeout fix) or one that flaps (reconnect loops).

Ordered fix checklist

Run top to bottom. Stop when the matching coin tab shows the worker under the expected label, fresh accepts move, and firmware is no longer stuck on laggy / high-latency symptoms.

1. Confirm the stratum string is already correct

Symptom: You have never verified host/port/user/pass; “high latency” is a guess.

Action: First pass host / port / user / pass cleanliness. For BTC easy-start:

stratum+tcp://btc.bitmernsolo.com:3132
WALLET.worker
password: x

Never treat :3102 as the Bitaxe / home default. Host must match the coin (btc.bitmernsolo.com for BTC; other coins use their matching per-coin hosts). Only after the string is clean do you treat laggy jobs as a path problem.

2. Open the matching coin tab before you blame latency

Symptom: You watch the wrong coin tab and conclude “pool lag” because nothing useful updates.

Fix: Open the same coin the miner is pointed at. A BTC-pointed board will not populate LTC worker cards.

3. Prefer a clean LAN path (Ethernet when you can)

Symptom: High RTT / lag only on Wi-Fi; Ethernet on the same desk feels stable.

Fix: Move the miner to wired Ethernet or the primary (non-guest) SSID. Reduce radio congestion for the test. Details: Ethernet vs Wi-Fi. Do not invent an “ideal ping” number — prove accepts after the path change.

4. Kill VPN / proxy detours on the miner’s path

Symptom: Latency spikes only when a router VPN, bridge-PC tunnel, or “split” proxy is in play.

Fix: Fully disable the tunnel on the path the miner uses (not just pause the client UI). Renew DHCP if needed. Retest. Do not invent Bitmern Solo “VPN latency” product claims — see VPN / proxy stratum fix.

5. Clear guest Wi-Fi, captive portals, and client-isolation

Symptom: Phone browses; miner associates then shows laggy jobs; Ethernet is fine.

Fix: Move to the primary LAN SSID or wired Ethernet. Disable guest isolation for the test. Re-apply pool settings after the hop.

6. Username and password shape (still required)

Required:

WALLET.worker
password: x

Traps that scramble attribution while you chase “latency”: missing dot, spaces, wrong wallet prefix vs the registered receive address, password not exactly x, or watching the wrong worker suffix.

7. Primary slot only while diagnosing

Symptom: Primary points at Bitmern Solo; secondary still points elsewhere; jobs never stay stable on Bitmern Solo.

Fix: Put Bitmern Solo on the primary (or only) pool slot. Clear or disable failover slots that point elsewhere while you diagnose. Host must match the coin. Save and apply.

8. Power-cycle / re-apply after path changes

Symptom: You fixed Wi-Fi / VPN / guest SSID, but firmware still shows old lag lines.

Fix: Save pool settings, reboot the board (or full power-cycle), and watch logs for a new session — not stale lag complaints from before the path change.

9. If latency already became stales, timeouts, or reconnect loops

• Shares rejecting as stale → stale shares fix
• Session never completes → stratum timeout fix
• Session connects then flaps → reconnect loops

Stay on this post when the main complaint is high RTT / laggy jobs with a session that still sometimes works.

10. Prove first accepts on the Bitmern Solo dashboard

Open the matching coin tab. Confirm:

• Worker row present under the expected WALLET.worker label
• Fresh accepts moving (not stuck empty)
• Hashrate reading believable while the board hashes
• Current Effort leaving a stuck empty reading when attribution works

Card reading stays in the dashboard guide. Here you only verify a cleaner path landed timely work on the account.

When Ethernet, VPN, stales, timeouts, or reconnect loops is the real story

If radio / guest SSID is the culprit, use Ethernet vs Wi-Fi. If a tunnel is still on the path, use VPN / proxy. If shares are already stale, use stale shares fix. If the session never completes, use stratum timeout fix. If the session flaps, use reconnect loops.

What this post will not invent

• No Bitmern Solo product latency SLA or “ideal ping under N ms” promise
• No fabricated millisecond thresholds presented as product fact
• No claim that :3102 is the home Bitaxe default (easy-start is :3132)
• No “first accept within N seconds” guarantee after a path cleanup
• No luck formulas, dollar EV, or find-time promises from lower latency
• No competitor fee comparisons

Fee reminder only if you need it: flat 1% on finds; you keep 99%. A cleaner path is an ops signal, not a fee.

Quick retest sequence after a path change

After you move to Ethernet, kill a VPN leftover, or leave a guest SSID, do not stare at a stale firmware lag line forever. Use a short retest loop:

1. Save the stratum string again (BTC easy-start still btc.bitmernsolo.com:3132, WALLET.worker, password x).
2. Reboot or power-cycle the board so it opens a new session on the clean path.
3. Watch for stable jobs instead of another laggy / high-latency complaint.
4. Open the matching coin tab and wait for the worker row + first accepts — not for a luck promise or invented ms SLA.

If the board connects then drops and reconnects, leave this post and use reconnect loops. If shares reject as stale, use stale shares fix.

Soft next step

Lock a correct stratum string (btc.bitmernsolo.com:3132 for BTC easy-start, WALLET.worker / x), prefer a clean LAN path, remove VPN / guest detours, then confirm first accepts on the matching coin tab before you chase deeper stale or reconnect issues.

Start mining

Start Mining — after login, open the matching coin tab and confirm workers / shares / hashrate.

FAQ

Does Bitmern Solo publish an “ideal ping” number?

No. This guide does not invent millisecond thresholds or product latency SLAs. Clean the path, keep :3132 / WALLET.worker / x, and prove accepts.

What BTC port should a home Bitaxe use first?

:3132 on btc.bitmernsolo.com. Never treat :3102 as the Bitaxe / home default.

What username and password does Bitmern Solo expect?

Username WALLET.worker (wallet prefix must match the registered receive wallet for that coin). Password exactly x.

Can Wi-Fi alone cause high latency symptoms?

Yes. Congested or guest Wi-Fi often raises RTT while phones still browse. Prefer Ethernet or the primary LAN; also see Ethernet vs Wi-Fi.

Where do stale shares fit?

If latency already turned into stale rejects, use stale shares fix in addition to cleaning the path here.

Where do timeouts and reconnect loops fit?

Hung first connect → stratum timeout fix. Connect-then-flap → reconnect loops.

Where do I confirm the fix on Bitmern Solo?

Matching coin tab → worker row → fresh accepts → believable hashrate. Guide: dashboard workers / shares / effort.