Claude for performance analysis.
ke4pjw
Posts: 1,298
After having Claude create a multithreaded webserver for the Blitzen 24, a problem popped up where lock contention for the W6100 was causing a performance problem. Asking it about the contention, it suggested the additional threads were the cause. I asked it to do an analysis of creating a dispatcher that could check the status of all of the sockets and dispatch the httpd requests so that it wasn't just looping through each task checking to see if there was anything needing to be serviced. Here is the analysis it came up with and a plan to implement it. I will actually see how this performs later.
Here's the contention comparison from the plan:
Current: 4 Tasks Polling Independently
| Operation | Locks/task | × 4 tasks | Total |
|---|---|---|---|
| EstablishTCP: readreg Sn_IR (initial) | 1 | 4 | 4 |
| EstablishTCP: readreg Sn_IR (loop) | 1 | 4 | 4 |
| mdnscheck: readreg Sn_IR on Socket7 | 1 | 4 | 4 |
| mdnscheck: ReceiveData → readreg RX_RSR | 1+ | 4+ | 4+ |
| Total per cycle | ~4 | ~16+ |
Proposed: SIR Dispatcher
| Operation | Locks | Total |
|---|---|---|
| ReadSIR (1 byte, covers all 8 sockets) | 1 | 1 |
Side-by-side
| Scenario | Current | Dispatcher | Reduction |
|---|---|---|---|
| Idle (no connections, no mDNS) | ~16+ | 1 | ~94% |
| 1 connection arrives | ~16 + handling | 1 + handling for 1 task | ~94% idle overhead gone |
| mDNS query arrives | ~16 + mDNS work | 1 + mDNS work | ~94% idle overhead gone |
The E1.31 PASM cog needs 9 lock acquisitions per packet. Currently it competes with ~16 idle Spin2 attempts per cycle. Cutting those to 1 means the PASM cog spends far less time waiting for the lock and more time moving data off the W6100 bus.