Shard LCM stream channels across dedicated multicast buses. DIM - 1337 - #3207
Open
bogwi wants to merge 3 commits into
Open
Shard LCM stream channels across dedicated multicast buses. DIM - 1337#3207bogwi wants to merge 3 commits into
bogwi wants to merge 3 commits into
Conversation
bogwi
requested review from
Dreamsorcerer,
leshy,
mustafab0,
paul-nechifor and
spomichter
as code owners
July 27, 2026 06:42
Contributor
Greptile SummaryIntroduces deterministic channel-based sharding across dedicated LCM multicast buses.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart LR
C[LCM channel] --> H[CRC32 channel path]
H --> B[Dedicated multicast bus]
B --> P[Publisher and subscriber]
D[Default control bus] --> O[Spy and Rerun observers]
B --> O
Reviews (3): Last reviewed commit: "update tests" | Re-trigger Greptile |
❌ 4 Tests Failed:
View the top 2 failed test(s) by shortest run time
View the full list of 2 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
leshy
requested changes
Jul 27, 2026
Member
There was a problem hiding this comment.
This is a good change, had in mind as an LCM escape hatch for a while :D I think we should consider creating a new protocol because this is not an LCM anymore.
We can call it E-LCM, Efficient LCM, or something like this, in order to keep us LCM compatible with our standard LCM transports. It's viable we'll need to interface with third-party LCM implementations.
leshy
reviewed
Jul 27, 2026
| # Create transport | ||
| transport = PickleLCM() | ||
| # Create transport on the same sharded bus agentspy subscribes to | ||
| transport = PickleLCM(url=lcm_url_for_channel("/agent")) |
Member
There was a problem hiding this comment.
You took over decisions on what an URL is, and this is now an protocol level internal variable. users should not be exposed to it at all, URL as a value is effectively killed. We can replace this as a namespace value or something, a number, but it cannot be a URL anymore. (actually yes, "namespace" can effectively be your "port range" - more on this below)
Actual topic setting, a line below, will decide the URL you use, it is not known at the instantiation. This means that one pubsub instance can hold multiple LCM instances per topic on different ports
leshy
reviewed
Jul 27, 2026
| return parsed._replace(netloc=f"{host}:{port}").geturl() | ||
|
|
||
|
|
||
| _STREAM_BUS_COUNT = max(0, int(os.getenv("LCM_STREAM_BUSES", "16"))) |
Member
There was a problem hiding this comment.
why so conservative? this is a main knob that gives us efficiency, ideally we want each topic on its own port, I'd actually reserve a port range 50000-60000 or something, Allow user to exclude specific ports or redefine the range, But then just build the deterministic hash function. It takes a topic name and gives you a port number.
leshy
reviewed
Jul 27, 2026
| # spy sources (see default_sources). | ||
| from dimos.protocol.pubsub.impl.lcmpubsub import LCMPubSubBase | ||
| from dimos.protocol.service.lcmservice import lcm_bus_urls | ||
|
|
Member
There was a problem hiding this comment.
If we actually spread each topic per port, spying becomes a problem. I would actually ignore this problem as a first PR, just measure efficiency..
later, since we are implementing this as a separate protocol, we can have a simple meta topic that each instance can use to announce the topic it's on or something similar, can we somehow detect ports in use? and can auto-spy on all of them within our ELCM range
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MacOS
Running any blueprint even a lightweight like this uv run dimos --replay --transport=lcm run unitree-go2 under LCM and on MacOS - makes rerun to stall. That makes impossible to develop in Mac under LCM.
The changes on this branch fix that.
Linux
The fix ALSO greatly reduces CPU usage on Linux by 10%! Running the above blueprint on my machine has taken of about ~25% of CPU usage, but now only 15%!