Shop OBEX P1 Docs P2 Docs Learn Events
Claude for performance analysis. — Parallax Forums

Claude for performance analysis.

ke4pjwke4pjw Posts: 1,300
in AI Tools and Techniques

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.

Comments

  • ke4pjwke4pjw Posts: 1,300

    I am having just too much fun with this.

    SIR Dispatcher + SENDOK Fix — COMPLETE

    Summary of Changes

    All work is implemented, tested, and ready for check-in.

    W6100drv.spin2

    • Added REG\_IR = $2100 and REG\_SIR = $2101 constants
    • Added ReadSIR() method — single bus read of Socket Interrupt Register
    • Added ReopenTCP() method — fast socket recycle skipping MR/PORTR writes
    • Fixed SENDOK bug: SendData() was reading REG\_Sn\_IMR (mask, always $FF) instead of REG\_Sn\_IR (status) for SENDOK check — loop exited immediately, causing TCP RSTs before data finished transmitting. Fixed in both SendData instances.

    Blitzen24.spin2

    • SIR dispatcher replaces independent EstablishTCP polling (16+ → \~4 bus txns/cycle idle)
    • socket\_ready\[] hub flag array for inter-task signaling
    • SIMR register configured for HTTP sockets (1,2,4,5) + mDNS (7)
    • Stale interrupt clearing on boot via Sn_IRCLR
    • ReopenTCP() used for socket recycling after disconnect
    • resp\_js\_ptr with Content-Type: application/javascript for all JS responses
    • Static .JS MIME routing from SD card

    Test Results

    • All JS files load correctly (net.js, e131.js, output.js)
    • Concurrent requests: all 3 complete in \~0.1-0.3s (no E1.31 load)
    • No more connection resets (SENDOK fix)
    • Under 60-universe E1.31 load (\~1781 pkt/s): webserver slows to \~7s — expected bus contention at that packet rate

    Status: COMPLETE — ready for real-world testing

  • ke4pjwke4pjw Posts: 1,300

    Well, I am just tickled pink. That all worked amazingly well. After all of the improvements it made, this thing feels more solid than ever. I validated it on a controller with about 2000 pixels connected and everything just worked. As a matter of fact, it also resolved the issues I was having with some of the pages not loading correctly on Android and the MDNS hostname not resolving on Android. The latency on the webserver is much less.

    Claude is really great at iterating. It would program the P2, run integration tests, find problems, ask for direction, allow me to offer suggestions on performance strategies, build-upload-test, analyze, build-upload-test, analyze, until things are about as tight as I can get. Just amazing! Worth the $25/mo.

Sign In or Register to comment.