Forza

@jr-m4 said:

$ cat /proc/sys/net/ipv4/tcp_mem
90147   120196  180294

Consider increasing your tcp memory buffers.?

❯ sysctl -a |grep tcp|grep mem
net.ipv4.tcp_mem = 372396       496530  744792
net.ipv4.tcp_rmem = 4096        262144  268435456
net.ipv4.tcp_wmem = 4096        262144  268435456

@olivierlambert said:

Follow-up on the questions left open in this thread. Three things came out differently from what I said above, so corrections first, and my earlier headline numbers need revising upward.

My earlier ratios were too low: the rig was the bottleneck

Everything I posted before ran NVMe to NVMe, where the destination disk saturates around 250 to 300 MB/s and degrades as it fills. That capped the faster arms, arm C worst of all.

Rebuilt with RAM-backed SRs on both hosts, no storage ceiling, full four-arm matrix on one rig, 3 runs per arm, interleaved.

arm	build	MiB/s	range	vs stock	stalls	B/seg
A stock	control	71.3	71.2-71.4	1.00x	78.3%	1441.6
B TCP_NODELAY only	+socket	303.8	303.1-305.0	4.26x	1.5%	1426.6
C NODELAY + pipelining	both	526.6	522.8-528.5	7.39x	1.1%	1425.7
D pipelining only	+pipeline	528.3	523.0-531.9	7.41x	16.1%	1442.0

Per-arm spread is 0.3% to 1.7%.

The full stack is worth 7.4x, not 5.51x, and TCP_NODELAY alone is worth 4.26x, not 2.80x.

The two changes are substitutes, not complements:

• TCP_NODELAY alone: 4.26x
• pipelining alone: 7.41x
• both together: 7.39x

So:

• Pipelining alone captures the whole win.
• Adding the socket option on top of it is 0.997x, with overlapping ranges. Nothing.
• The reverse is not true: pipelining on top of NODELAY is still worth 1.73x.
• NODELAY does not substitute for pipelining. Pipelining substitutes for NODELAY, on throughput.

What the socket option still does after pipelining is remove the stall, 16.1% of samples down to 1.1%, for 1.14% more segments. On this rig that buys no throughput. See the RTT caveat before writing it off.

Correction 1: I said Chunked might regress. It does.

xe vdi-copy between two host-local SRs, 100 GiB, interleaved A/B/A/B. @TeddyAstie was right.

arm	transfer	data_segs_out	B/seg	stalls
A control	442.1 s	74,746,948	1438.5	0.0%
A2 control	439.4 s	74,677,058	1439.9	0.0%
B NODELAY	449.5 s	75,205,400	1430.1	0.0%
B2 NODELAY	455.5 s	75,260,858	1428.7	0.0%

Both controls beat both patched runs with no overlap, so this is not drift. TCP_NODELAY costs +2.7% wall clock and +0.70% segments here, and buys nothing.

Nothing, because the stall it fixes does not occur on this path:

• Sub-MSS stalls are 0.0% in every arm, including the unpatched control.
• Chunked writes a 12 byte header then data, with no per-request reply.
• So the send queue stays backed up (median notsent about 3.3 MB, rwnd_limited 99.7%).
• Nagle never faces a small-segment decision. Packing is already 0.993x MSS before the patch.

Where the extra packets come from, and it is not mainly the headers:

• The disk is fully allocated, so expand_copy (f.ml:2745) splits at its 2 MiB cap: 51,200 chunks.
• That is only 9.8% of the 521,126 extra segments.
• The rest is TLS record boundaries. The channel is unbuffered (channels.ml:129), so each 16 KiB TLS record is its own 16,413 byte write, 11.33x MSS, leaving a sub-MSS remainder.
• With Nagle those coalesce with the next record. With NODELAY they go out uncoalesced whenever the send queue drains.
• strace confirms both shapes: 41 byte writes are the headers (12 plus 29 of AES-GCM), 16,413 byte writes are the bulk records.

Data is correct either way: the patched copy md5s identical to the source, ce647d9436b48401cd4b489c955ef0f7.

Protocol confirmed two ways, for anyone reproducing:

• An https destination not advertising transfer-encoding: nbd yields [Chunked; NoProtocol] (impl.ml:1084), and the code takes List.hd.
• At runtime the receiver runs vhd-tool serve --source-format raw --source-protocol chunked --source-fd 8.

Correction 2: my reasoning for "NODELAY is a no-op after pipelining" was wrong

I said that with 8 requests in flight there is almost always an MSS queued, so the sub-MSS condition rarely arises. Not what happens. Arm D is pipelining with the socket patch removed, and it still stalls on 16.1% of samples against 1.1% with it. Depth 8 does not keep the queue above MSS.

The conclusion survives, the reasoning does not: NODELAY after pipelining gives no throughput gain because the stall stops being the limiting factor, not because the stall goes away.

Correction 3: the export path needs nothing

• Export runs stream_raw (impl.ml:335) : export_raw_vdi.ml:56 passes "none" as the destination protocol. No headers, no replies, so no write-write-read pattern.
• The patch could not cover it anyway: --destination-fd becomes fd://N, then File_descr, then Channels.of_raw_fd (impl.ml:991), never touching the socket helper.
• It does not need to. http_svr.ml:624 already sets TCP_NODELAY on the listening socket and Linux passes it to accepted sockets. Verified on the 4.19 kernel these hosts run, with a listener without the option as a control returning 0.
• stunnel sets it independently too (xapi_stunnel_server.ml:66-68).

The cost of TCP_NODELAY, every test we ran

path	Nagle on	TCP_NODELAY	cost
NBD 107 GiB, NVMe	1441.7 (0.996x MSS)	1425.2 (0.984x)	+1.16% segments
NBD pipelined, RAM	1442.0 (0.996x)	1425.7 (0.984x)	+1.14% segments
NBD 6-pair repeat, RAM	1441.9 (0.996x)	1424.6 (0.984x)	+1.20% segments
Chunked 100 GiB	1438.5-1439.9 (0.993x)	1428.7-1430.1 (0.988x)	+0.70% segments

About 1.2% more segments, reproducible to three digits across four independent experiments. Small, and it is the real permanent cost of the option.

Where the ceiling is now

At 7.4x we are at about 525 MiB/s, and it is not the obvious things:

• Not the network: 10G link, roughly 46% utilised.
• Not the sender: sparse_dd at mean 57%, peak 64% of one core.
• On the receiving host, tapdisk is roughly 72% of all busy CPU (python3 9%, xapi 6%, stunnel 6%).

That sample spans more than one leg and sums several tapdisk processes, so read it as dominance rather than a precise figure. It is where we would look next.

Our reading

Both changes are worth having, they are independent, and they are not additive, so the order is a real decision.

TCP_NODELAY

• Strongest argument is precedent, not the benchmark: vhd-tool is the only NBD client in the toolstack that leaves Nagle on.
• QEMU sets it unconditionally (nbd/client-connection.c:143) and forwards it through TLS. blktap treats failing to set it as fatal (drivers/block-nbd.c:793). xapi and stunnel both set it.
• 12 lines, 4.26x on code that ships today.
• Costs, now measured rather than assumed: about 1.2% more segments everywhere, and 2.7% wall clock on vdi-copy between two host-local SRs where it gains nothing.

Pipelining

• 7.41x on its own, and it makes the socket option irrelevant to throughput.
• Less work than it looks: the multiplexer already exists and is unused (nbd/lib/client.ml:78), so this is not the NBD redesign it first appears to be.
• The real obstacle is buffer ownership. expand_copy hands out slices of one shared 2 MiB buffer, so a naive pipeline silently corrupts data while reporting success.
• Our prototype works around it with a local buffer pool and a memcpy per block. The proper fix belongs inside expand_copy in f.ml, a shared library with other consumers.
• The prototype is not mergeable as it stands: progress counts issued rather than completed work, and a failed write leaves its siblings unawaited.

We will follow whichever route the XAPI team prefers and are happy to do the work either way. Our own order would be the socket option first, then pipelining done properly rather than our prototype. That is a sequencing preference, not a claim that the gains compose. If you would rather go straight to pipelining and skip the socket change, our data supports that: it reaches 7.41x on its own.

One caveat that cuts in favour of the socket option, and our rig cannot measure it:

• Every number here is from a 0.2 ms RTT link.
• The Nagle stall costs a delayed-ACK round trip, so its cost scales with RTT.
• 0.2 ms is therefore the regime least favourable to fixing it.
• On a higher-RTT link (cross-rack, cross-site, DR replication) the same 16.1% stall rate that costs nothing here should cost real throughput.
• So read 4.26x as a floor for TCP_NODELAY, and "pipelining makes it redundant" as a statement about short links specifically.
• We have not measured a long-RTT link and would like to hear from anyone who has.

Open questions

1. Is the 2.7% on vdi-copy acceptable, or should the option be scoped to NBD? Unconditional is simpler and matches every other component. Scoping avoids a measured regression on a path that cannot benefit.
2. Is the Chunked header worth batching regardless? It is a separate unbuffered 12 byte write before every chunk, which under TLS becomes its own 41 byte record. Writing header and payload together removes that independently of any socket option, and helps the Nagle-on case too.
3. Should expand_copy own a buffer pool? Any pipelining implementation needs it. Fixing it in f.ml fixes it for every consumer, but that is a wider blast radius than we wanted to take unilaterally.
4. Is the receiving tapdisk the next real ceiling? At 7.4x the sender and the network both still have headroom and tapdisk dominates destination CPU. We have not dug into why.
5. Does the picture change on a high-RTT or faster link? Both conclusions, that NODELAY is worth 4.26x and that pipelining makes it redundant, are properties of a short fast link that never saturated.

Rig

• Two host XCP-ng 8.3 pool, xapi 26.1.16, 10G, 0.2 ms RTT.
• Arms differ by exactly one setsockopt where relevant, same tree and toolchain.
• Every run verified by binary sha256 before it started, transfers checksum verified.
• RAM SRs are ext4 on a brd ramdisk. tmpfs does not work: no O_DIRECT, so VDIs can be written onto such an SR but never migrated back off.

Excellent work.

IMHO, disabling Nagle's algorithm is the best and least risky option. Application code paths and protocol behaviour stays exactly the same, except for the socket option. For a very risk free change we gain a lot or performance in a known bottleneck.

Pipelining exposes a new code path which needs more debugging and verification before it should be deployed, especially in a LTS situation.

Speaking as a paying enterprise customer, stability and predictably is important to us. Therefore I propose that the short-term solution is to disable Nagle's algorithm and ship it in the current LTS release as a normal bug fix.

Then, in a longer term, develop the Pipelining option and ensure it get proper testing and verification before release, particularly if backporting it to current LTS.

@iams3le we have switched to the signed xcp-ng drivers. We also replaced our older 2022 servers.

@dinhngtu said in Execute pre-freeze and post-thaw:

There used to be quiescent snapshot capabilities in older versions (mainly for Windows VSS support), but it has since been removed. I'd say @Team-XAPI-Network knows more about the reason.

We have vmware with ppdm backups and the vss part is actually causing some annoying issues such as quite long io stalls. But I do understand the reason for vss, especially for applications that aren't crash safe.

I've been considering remote syslog too. Does enabling remote syslog remove local logging?

@Danp said in restore metadata for pool -> incompatible version:

My understanding is that you can only restore metadata to the exact same version of xapi. Does your old pool still exist?

This is quite the limitation. Is it documented?

@cmoriarty said in ️ XO 6: dedicated thread for all your feedback!:

I use the "VM notes" feature in XO 5 for lots of things, and I appreciate having the markdown capability. It seems now these VM Notes are stuffed into a small "Description" field inside the "Quick Info" panel for a VM.

Currently in XO 6, it looks like my notes are getting truncated in this new description field, are there plans to preserve the "VM Notes" functionality? Or should I be backing them up now before I lose them?

Me too. They serve as important info, documentation, and other bits of info that needs to be quickly on-hand.

What I would like to add is a way to upload images and include them in the Markdown.

What is the purpose of the SR scans, and why do they indeed have to run ao frequently?

@acebmxer said in ️ XO 6: dedicated thread for all your feedback!:

@ph7

So question what happens when i thinks the vm disk is full? When will it clear up? Only thing i can think of was coping 13gb veeam ISO over few times testing things and stuff. but that has been a while now.

No, it will not. You can create a new vdi and move the files over manually.

@Bastien-Nollet Thanks. I am on Stable channel as I use XOA Premium.