Huge battery drain

[bam80]

Possibly related with #516, needs testing by more people was confirmed by many people in other projects:
golang/go#48622
v2ray/v2ray-core#2564
shadowsocks/go-shadowsocks2#224
OutlineFoundation/tunnel-server#108
geekman/hapz2m@fe5d0ce
brutella/hap#36
saucelabs/forwarder#605
cbeuw/Cloak#82
forkgram/TelegramAndroid#448
binwiederhier/ntfy-android#90
binwiederhier/ntfy#1195
binwiederhier/ntfy#687
binwiederhier/ntfy@86ef2e8
gotify/server#343

So the first day of test with the proxy showed inadequately huge battery consumption, and I'm afraid this is not a coincidence:

Unfortunately, I can't test without proxy,
but it looks we definitely need to check it out.

I'm afraid this level of the consumption is unacceptable.

Originally posted by @bam80 in #516

[dolonet]

Triage / state-of-play for the next person:

• The technical question is still "does the outbound keep-alive cadence (30s idle / 10s probe / 3 retries, applied to mtg→DC dials) measurably contribute to phone battery drain vs. running Telegram without the proxy". The observation in #516 (comment) is one data point on one phone with no baseline.
• The cheap experiment that answers it is the A/B sketched in #516 (comment): same phone, two mtg instances with DefaultKeepAliveIdle patched to 30s vs 600s, same Telegram session, overnight idle-drain comparison. If patched ≈ stock, keep-alive isn't the culprit and a client-facing knob wouldn't help; if patched < stock by a meaningful margin, the knob has a reason to exist.
• Until that measurement exists, this stays in "needs data", not "ready to design a config option".

Labelling as question + help wanted — anyone with mobile-measurement capability welcome to pick it up.

[bam80]

The problem seems persistent:

I didn't notice it with other mtproto proxies,
and there is definitely no problem with Socks5 one.

[bam80]

As a way to move forward, I think maybe try telemt in the compose here instead of mtg.

[bam80]

So in my research, the culprit must be the keep-alive indeed, see the links above - people had the same issue and increased keep-alive timeout helped them. The fix was added to many Go projects suffered (but the bug triggering the problem is probably in Go itself and still present).

To make sure, I'll try to patch mtg and make a test build, as suggested by @dolonet:
#516 (comment)

I'll be back. Thanks. :)

[bam80]

So I tested it but got unexpected results.
To make sure I did everything right, I tried to dump the keep-alive packets from unpatched version first, but failed at this step already:
#534
So I couldn't actually compare the patched version with original, because I couldn't make sure the original works as expected. It seems like keep-alive just doesn't work there.
Any help appreciated.

[dolonet]

I think two questions are getting tangled here.

Keepalive is set on the socket — tcpdump is just a bad way to verify it. network/sockopts_test.go reads SO_KEEPALIVE, TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT off an accepted socket via getsockopt and confirms the expected values (1 / 30 / 10 / 3). The fastest live check on the mtg server:

ss -tneoi 'sport = :<mtg-port>' | grep -A1 <client-ip>

You'll see timer:(keepalive,Ns,0) counting down — unambiguous, no packet-capture guessing.

Why you don't see "one probe every 30s during silence" in tcpdump: TCP_KEEPIDLE is "time since the last packet on the socket", not a wall-clock interval. In foreground, Telegram's own ping_delay_disconnect and background chatter keep resetting the idle timer, so the probe never actually fires. When iOS suspends the app and client traffic really does stop — the probe fires; then either the other side ACKs (and the next probe is deferred 30s) or it doesn't, and after ~60s (3 × 10) the connection is torn down. To observe a probe empirically: open a deliberately idle TCP connection to the mtg port (nc <server> <port>, send nothing), tcpdump on the server filtering for zero-payload pure ACKs — first one appears after 30s.

Now battery drain. In the background scenario (phone sitting idle, app suspended) the probe does fire every 30s. But order-of-magnitude: probe ~54 bytes + reply ~54 bytes = 2 packets per socket per 30s ≈ 4 packets/min. Radio wake ~50–100ms per packet, so ~0.5% duty cycle per proxy socket. That doesn't explain the consumption level on the screenshot.

So the A/B Idle=30s vs Idle=600s will produce a real technical difference (especially when the phone is asleep for long stretches), but I'd expect single-digit percent, not "washing machine". If you measure a large difference — great, strong signal, but the next place to dig wouldn't be TCP keepalive; it would be the connection idle-timeout (also PR #441, raised to 5 min — different mechanism), or something above the TCP layer entirely. Without A/B numbers, tweaking keepalive parameters is premature.