Martino FerrariandClaude Opus 4.6
deabd257e5
Reported as samples sporadically carrying a previous packet's timestamp: holes on one side of the stream and collisions on the other, in both the Go and the MARTe2 receiver. That it appeared in both is what located it -- the shared cause is upstream of either client. Four independent defects, all of which end in a packet's values being placed at a time that is not theirs. Reassembly slot exhaustion (the "Reassembly slots full; evicting oldest" flood). Chunk size was learnt only from fragment 0, so an out-of-order burst destroyed a packet whose bytes had all arrived and left the slot occupied until the 2 s GC. Slots were keyed on the counter alone, but DATA and CONFIG number independently, so equal counters merged the two streams. The 32-byte received-mask covered 256 of the 512 fragments the client accepts, so a duplicate above 255 was counted as new and the packet was delivered with a hole of stale bytes in it. And one datagram was read per Execute(), which cannot drain a fast producer. Fixed with a pendingTail deferral, (counter, type) keying, a 64-byte mask, a 256-datagram drain, counter-age slot reclamation, and a 1 Hz aggregated warning in place of the per-eviction flood. UDPStreamer dropping whole Accumulate batches. EventSem::ResetWait is Reset-then-Wait, so a Post() landing while the sender thread was inside ServiceClients()/SendData() was destroyed by the next Reset. The batch was then skipped with dataReady false, readyFill was never cleared, and the following flush overwrote it: an entire run of RT cycles never reached the wire. The record of pending work now lives in the buffers rather than in the semaphore edge, which also removes up to UDPS_DATA_WAIT_MS of latency; genuine backpressure overwrites are counted and reported. Against the unfixed code the new test sees 2999/3000 batches never consumed. Period inflation after loss. Accumulated scalars carry no SamplingRate, so the receiver derives dt from the sender-clock gap -- but dividing it by the previous packet's sample count is only right while nothing is lost. One loss doubles the reported period, which spreads a batch a full batch past its own end and into the range the next packet claims. That is the hole and the collision, exactly. Inferring the cycle count from the estimate's own period is not a way out: it has a stable fixed point wherever gap/dt is an integer, so a real rate change locks it at the old one for good (AccumDtGTest.FollowsSustainedRateChange). The packet counter removes the ambiguity, so all three receivers now order on it: a DATA packet that does not advance the counter is dropped rather than delivered, because its values are older than data already handed over. Ordering is on the signed difference so it survives the uint32 wrap, and the sequence resets on reconnect, where the producer's counter restarts independently of ours. The loss count that falls out of the same delta feeds the period estimate as cycles = prevN * (1 + lost), which reduces exactly to gap/prevN when nothing is lost and therefore still tracks a genuine rate change. UDPSClient::AcceptDataCounter (C++), udpsprotocol.SequenceGate (Go), decode_data (C). The C client's existing gap counter was wrap-unsafe and let a stale packet rewind last_counter, which made every subsequent gap wrong; it uses the same code now. Docs/Protocol.md gains an Ordering DATA section stating the requirement for any receiver, including ones outside this repository. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
50 lines
1.7 KiB
Go
50 lines
1.7 KiB
Go
package udpsprotocol
|
|
|
|
// SequenceGate orders DATA packets by the producer's packet counter.
|
|
//
|
|
// Reassembly completes in arrival order, not counter order, so a packet that
|
|
// was delayed or duplicated on the wire is handed up after a newer one has
|
|
// already been consumed. Its samples then carry an older time base than the
|
|
// data already in the ring: they land on top of samples that are already
|
|
// there, and the span they should have filled stays empty. That is a hole on
|
|
// one side and a collision on the other, from a packet that is entirely
|
|
// well-formed — the counter is the only thing that distinguishes it.
|
|
//
|
|
// A SequenceGate is not safe for concurrent use; each receive loop owns one.
|
|
type SequenceGate struct {
|
|
last uint32
|
|
valid bool
|
|
// Stale counts packets rejected for not advancing the counter (reordered
|
|
// or duplicated), for diagnostics.
|
|
Stale uint64
|
|
}
|
|
|
|
// Reset forgets the sequence. Call it on (re)connect: the producer's counter
|
|
// restarts independently of ours, so a counter carried over from the previous
|
|
// connection would reject the whole new stream.
|
|
func (g *SequenceGate) Reset() {
|
|
g.last = 0
|
|
g.valid = false
|
|
}
|
|
|
|
// Accept reports whether a DATA packet with this counter should be delivered,
|
|
// and how many packets went missing immediately before it.
|
|
//
|
|
// The counter is a wrapping uint32, so ordering is done on the signed
|
|
// difference: a plain comparison would call the first packet after the wrap
|
|
// stale and reject everything from then on.
|
|
func (g *SequenceGate) Accept(counter uint32) (ok bool, lost uint32) {
|
|
if !g.valid {
|
|
g.valid = true
|
|
g.last = counter
|
|
return true, 0
|
|
}
|
|
delta := int32(counter - g.last)
|
|
if delta <= 0 {
|
|
g.Stale++
|
|
return false, 0
|
|
}
|
|
g.last = counter
|
|
return true, uint32(delta) - 1
|
|
}
|