curious how you keep the lyric highlight in sync across players given this is browser audio, not a native client. each phone's audio pipeline has different buffering (bluetooth headphones alone can add 100-200ms of latency depending on the device), so if the highlighted line advances off local playback position rather than a shared server clock, two players on the same "beat" can end up seeing different words highlighted, which matters a lot for a game about lyrical timing. also on iOS safari specifically, an audio element started from one gesture and then paused/resumed later (someone switching tabs to grab a drink) can get stuck needing another user tap to resume playback, which for a fast round based party game would just look like the game silently broke for that person mid round.
the game doesn't play or stream any audio (though i think maybe a countdown timer or other fun sound effects would be nice)
players usually either a) play in real life on their phones or b) use something like Google Meet or Discord to sing their lyrics
that being said, the "buzz in" feature is sensitive to latency (but, in my experience, it usually takes players a few seconds to think of a song that fits the target word anyway)
does the reflash actually stall every live connection, or just the ones whose request lands during that window? if the whole board goes dark for the full ~25s while any request is queued behind it, you could probably hide most of that behind partial reconfiguration, reflashing only the region holding the model weights while the sequencer and I/O logic on the rest of the fabric stay live and keep draining the queue. that's obviously a much bigger lift than what you've built here, but it would turn a hard stop into something closer to a brief latency bump for whoever's unlucky enough to hit it, rather than a shared 25s wall for everyone behind them in line.
Good question. short version: it's a shared wall, not a per-request bump. one KV260, one model on the fabric at a time, so the rotation is global. but the ~25s is mostly software, not fabric-dark time. the PL reconfigure is ~1-3s via fpgautil, the rest is orchestration (daemon teardown, streaming the weights back into URAM, clock change, coherence check, chat-server reconnect). DFX keeping the sequencer + I/O live only recovers that 1-3s slice, and it fights the design, since the weights are smeared across every URAM column while a reconfigurable partition wants a contiguous pblock.
The swap needs a fresh bitstream at all only because four little ROMs are baked at synthesis: layernorm gammas, the activation-quant scale, two dequant tables. the embeddings already ride the boot-streamed weight image. make those four boot-loadable through the same path and a same-arch model hot-swaps with no reconfigure. There is basically zero margin at the moment to implement this.
which is a decent excuse for a 24h telemetry update.
Peak 46 concurrent connections monday afternoon, 61 uniques in the busiest half hour, ~6,600 requests / ~400k tokens total. At no instant did more than 2 inferences overlap (although it came close once). the fabric finishes a ~100-char reply in ~2ms of compute (end-to-end round-trip is ~20-60ms once you add network + server), so even with 40+ people connected the queue sits empty ~100% of the time. Worst 30-second window of the whole day was p95 59.9ms, and the heaviest burst (~200 requests in 5 minutes from one enthusiastic visitor) didn't even produce it. still ticking at ~37 connections this morning, latency flat.
That's the counterintuitive bit about a 20k tok/s model with short replies: the "single stream" is busy for milliseconds per request, so it timeshares across human typing speed essentially for free. the synthetic ceiling (2,000 concurrent requesters, p95 ~9.4s, zero errors) is ~40x past anything real traffic did. every actual visitor had the chip to themselves.
After this is all over, I'll do a post-mortem to see how it held up. I was really hoping for FP with the amount of effort this one took compared to my other submissions, which really would have stressed it, but I guess it was just a bit too niche!
cycloidal designs are a great thing to have actually built rather than just read about. the eccentric motion is easy to follow on paper and then surprisingly fiddly once real tolerances show up.
two things worth measuring if you have not: backlash, and how much it changes after a few hundred cycles. cycloidal drives are usually sold on low backlash, so knowing your real number turns this from a nice print into something you can quote a spec for. if you have a way to load the output shaft, efficiency under load is the other number people will ask about.
