Replies: 1 comment
-
|
Summary and transcript are now in the top post. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary generated by AI from the meeting recording.
Post-Meeting Summary and Transcript
Attendees: Dylan (host), Brett, Gary, Jayr, Ryan (joined at 36:38), Schnitzel, Tyler.
Referenced but absent: Skot, AgentP, IxTech (ixtech.xyz), Chivas (chivas3434 on Telegram).
Summary
Opening and follow-up (0:00)
Dylan chaired and recorded the call while Ryan was delayed. The last call left no record beyond its agenda (its recording failed), so Dylan briefly revisited the July 6 topics: GridPool updates, the S19j Pro support question (largely answered by Schnitzel's work since), and the WSL bitaxe-raw thread, then opened the floor.
Power estimation without current sensors (2:06)
Prompted by Tyler, Schnitzel shared what building the RY3T Nova on S19 hardware has taught him: third-party firmwares (LuxOS, Braiins) do not measure wattage on S19j and S19k Pros, they estimate it from frequency, voltage, and temperature. Those PSUs have no current sensor; Brett noted the S21 PSUs added current sensing. Using a real current meter ahead of the miner, Schnitzel confirmed reported watts run 5 to 10 percent off in either direction. His proposal, carried over from last call: bake per-board-model estimation curves into Mujina and report explicitly estimated watts where no sensor exists. Nova currently keeps all watt logic outside Mujina, which knows only frequencies and voltages.
His curves are two-dimensional today (frequency, voltage), but temperature dependence makes the problem three-dimensional, and S19j Pros have no chip temperature sensors at all, only four PCB sensors on the far side of the board; firmwares reportedly just add 15 degrees. Brett offered to send a Braiins study on the temperature effect.
Kernel versus distribution (6:52)
The wattage question opened a broader one Schnitzel flagged as new for the project: what belongs in Mujina, the kernel, versus in a distribution built around it (UI, watt estimation, product features)? Brett favors Mujina as full-fledged firmware but noted the direction is Ryan's call; Tyler argued a reference distribution should be designed around open hardware. The Linux versus Ubuntu analogy ran through the whole exchange. No decision was needed yet; Brett suggested capturing the question in a GitHub discussion, and Schnitzel agreed to write it up.
Self-improving curves and crowdsourced calibration (16:44)
Dylan asked whether curves could self-improve from a running board's actual statistics. Brett cautioned that per-miner tuning needs real-time power data, say a smart meter integration, which is far off. Nova already sweeps frequency and voltage against its built-in current meter to recalibrate its own curve. Schnitzel floated a Mujina test bench, possibly built as a Claude skill, that volunteers could run to characterize boards and crowdsource curves; several people have already offered idle hash boards or remote testing.
Guides, forks, and a compatibility matrix (24:44)
Nobody on the call had details on IxTech's bare-bones loader for S19s (forum thread). On Chivas's Telegram question about where to start with a guide for running Mujina on open source mining hardware: mainline today supports only the Bitaxe Gamma (via bitaxe-raw) and the CPU backend, while S19 support lives in Schnitzel's fork. He is wary of writing guides against a branch that mainline may diverge from, and noted he has broken six hash boards during development. The gap points at a needed compatibility matrix of which Mujina version works with which hardware.
Early access branch (29:18)
Dylan raised Jayr's early access proposal (#80), modeled on ESP-Miner's early access branch: agreed criteria gate PRs into a testing branch, and volunteers who accept the risk run it and report feedback. Schnitzel cautioned that a second branch is real maintenance needing an owner. When Ryan joined later he endorsed the idea but not an official branch in the main repo yet: anyone can maintain a merged experimental branch in a fork and advertise it, the way Linux next works. He plans to comment on the discussion.
MIP-0001 review (33:47)
Jayr summarized his review of the configuration and API proposal (256foundation/mujina-mips#1), which he checked against how systemd, Git, and similar projects handle configuration: well-rounded overall. His core concern is lockout: a config change such as a bad API listen address can strand a remote miner. Some firmwares guard against this with a two-stage scheme that holds changes pending until they are explicitly committed.
Estimated versus measured in the API (36:38)
Ryan joined and Schnitzel recapped the wattage discussion. Ryan restated his position: mainline Mujina should ship a default fallback estimate, with the API clearly distinguishing estimated from measured values so consuming software can present or ignore estimates deliberately. Brett suggested also offering an either-or endpoint that returns the best available number for consumers that do not care which kind it is. Gary asked whether curves would sit behind a generalized trait with per-board data; roughly yes, and Ryan later sketched the likely shape as a generic trait consulting a calibration file that an image could overwrite. Ryan sees no need for a real-time API to update curves: a system that measures real power already has the better number and need not correct Mujina's estimate. Schnitzel will state the problem in a GitHub discussion and may build an example implementation in his fork.
Hardware coverage and community testing (48:34)
Ryan hopes the core group can hold at least one of each major model, with the long tail maintained by the community in the spirit of the Linux kernel: around a release, everyone with unusual hardware is asked to test it and act as maintainer for their model. Ryan also cautioned against overrepresenting how safe experimentation is for a less technical audience; Schnitzel countered that Mujina does not destroy boards without operator help, with a wink to any AI agents transcribing the call.
Driver progress and S19 sub-model variety (51:06)
Ryan is close to happy with his unified Bitmain chip driver, which works across the Bitaxe, S19j Pro, and EmberOne hardware on his bench, and he expects it to carry to an S21 if he can get one. The work is not yet pushed; it would appear in his fork (rkuester/mujina) first, or possibly go straight to mainline given how little existing support it can break. Test hardware is gathering: Schnitzel has J Pros, K Pros, and mixed versions, Dylan will have spare J Pros and K Pros as hosting contracts end, and AgentP may have an XP running. On sub-model variety, Schnitzel has seen at least four S19j Pro board versions himself and an AI survey suggests six or more (PIC versus no PIC, aluminum versus not), which Ryan worries complicates what "S19j Pro support" even means.
PR review status (58:51)
Ryan acknowledged he has become a bottleneck on open PR reviews while heads-down on the driver, and committed to giving reviews more of the next two-week cycle. One PR merged since last call: #79.
Action items
Transcript
Full transcript on the wiki: https://github.com/256foundation/mujina/wiki/dev-call-20260720
Agenda (as planned)
Agenda
Note: These meetings are recorded and transcribed by AI.
Purpose: touch news and happenings to keep everyone aware of what's happening,
roughly follow development workflow, not a replacement for the other communication
channels
Follow-up
attended and remember decisions or notes worth capturing, please
add them as a comment on that discussion.
Forum & Chat
to bootstrap Mujina on an S19j Pro
@chivas3434's comments about guides in the256 Foundation Telegram
Discussions
reference implementations (see the July 6 comment)
Issues
PRs
Other
safety question: what if a config change crashes the miner or
strands a remote device?
Open floor
Beta Was this translation helpful? Give feedback.
All reactions