Skip to content

A frame slot for each frame instead of one for each mailbox transaction #106

Open

Description

@markosankovic

What to do

Find out whether the SOEM control plane can take a frame slot for each frame on the wire, instead of one slot for a whole SDO, SDO Information or FoE transaction. Do it in this order:

  1. On a bench, measure how long the real-time frame waits behind control-plane frames, with kFrameSlots reads in flight on a bus of several drives.
  2. If the measured delay is well below one cycle, decide between two changes: raise kFrameSlots, or take a slot per frame with a patch in ports/soem.
  3. Record the measurement and the decision in a NEXTGEN.md session.

Why

ControlPlaneLocks::lockDrive (libs/comm/control_plane_locks.cc) takes one of kFrameSlots frame slots, and the transaction holds it until it ends. kFrameSlots is 8. So over SOEM, at most 8 mailbox transactions from all callers are in flight on the whole bus.

A slot is held far longer than it uses the wire. An SDO on a SOMANET Integro costs about 5 ms. For most of that time, ecx_mbxreceive waits for the drive: it sends a short read of the mailbox status, sleeps for EC_LOCALDELAY, and reads it again. Only the mailbox write and the final mailbox read are full frames.

The cap of 8 limits the refresher of #79 on a large bus of slow drives. With 4 workers and one SDO object on each of 30 Integros, one round of reads takes about 40 ms. With 12 workers it takes about 13 ms. Both figures are calculated, not measured.

The cap exists to protect the real-time frame. ecx_getindex (oshw/linux/nicdrv.c in SOEM) searches for a free frame index, and when it finds none it returns an index that is still in use. The NIC sends frames in order, so the real-time frame can wait behind every control-plane frame in flight. NEXTGEN.md, Session 2026-10-17, calculates about 1 ms of delay for 8 full frames. That is a worst case that assumes every slot sends a full frame at the same time. Nobody measured the real delay.

Done when

Notes

  • A slot per frame cannot be done in libs/comm. SOEM takes the frame index inside ecx_FPRD, ecx_FPWR and the other datagram calls, so the slot must be taken where SOEM takes the index. That is a patch in ports/soem.
  • The real-time thread must never wait for a slot. A patch must keep a share of the frame indexes for the real-time thread, as the slots do today.
  • SPoE has no frame slots and is not affected.
  • Out of scope: the refresher itself. That is SDO objects in a monitoring keep a drive's mailbox busy, and one thread refreshes every drive #79.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions