<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Rdma on Under the Model</title><link>https://oguzpastirmaci.com/tags/rdma/</link><description>Recent content in Rdma on Under the Model</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 20 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://oguzpastirmaci.com/tags/rdma/index.xml" rel="self" type="application/rss+xml"/><item><title>Why torchrun Can't Find Node Two on the Host Network</title><link>https://oguzpastirmaci.com/posts/why-torchrun-cant-find-node-two-on-the-host-network/</link><pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate><guid>https://oguzpastirmaci.com/posts/why-torchrun-cant-find-node-two-on-the-host-network/</guid><description>&lt;p&gt;If you want RDMA inside a Kubernetes pod, the simplest way is the host network. The pod uses the network namespace of the node, NCCL sees the RDMA NICs directly, and you get the bandwidth you paid for. On two BM.GPU4.8 nodes on OKE (8 A100 GPUs and 16 RDMA NICs each), NCCL &lt;code&gt;all_reduce&lt;/code&gt; reached about 191 GB/s bus bandwidth with an 8 GiB buffer.&lt;/p&gt;&#10;&lt;p&gt;Then torchrun gets confused. With the host network, every pod has the host name of its node, and torchrun uses host names to make two decisions. On these nodes, both decisions went wrong, because each node resolves its own name to &lt;code&gt;127.0.1.1&lt;/code&gt; and the other node cannot resolve it at all. Either no node starts the rendezvous store, or node two cannot find node one.&lt;/p&gt;</description></item></channel></rss>