nprofile1qyt8wumn8ghj7un9d3shjtnyd968gmewwp6kytcqyr0lpcdrcrp3vqttmxf0h3yf56xm99vzrhngt0aml2ma2pdvcwlu6r99lkp (nprofile…9lkp) nprofile1qyt8wumn8ghj7un9d3shjtnyd968gmewwp6kytcqyrsu3dsu7qzarqmsx0utn3ym2aekltvdk5g5l0lru45ndmgqqxxyjn0yjfz (nprofile…yjfz) There is a fifo in the scopehal driver but it's capped at 5 waveforms in normal mode and flushed when you single/stop triggering. So I don't think that's the cause.
Given the memory depth dependency which I hadn't noticed before, I'm suspecting it might actually be half-sent waveforms queueing up in the socket buffer which is a tricky issue to address because we *want* to allow a lot of data in flight on high latency WAN connections to avoid WFM/s degradation (e.g. using a remote scope at work over VPN from home).
We might have to, for example, do some kind of nonblocking socket operations to delete an integer number of waveforms in flight (if there are any) when the trigger is stopped.
If this is in fact the cause, it's possible it could affect the ThunderScope after some planned optimizations to making it more latency tolerant. So we'll definitely want to root-cause and correct it.
Lasse - are you in the developer chat? If not, you should probably join so we can discuss there in front of the other devs.
Andrew Zonenberg
npub1cd…z9vpd
2025-10-26 13:20:07 UTC
in reply to nevent1q…hjnv
Author Public Key
npub1cddglts94qutscms0qpmk87lel9m8xku7q0wr20u2th5fxvvunqqxz9vpdSeen on
wss://relay.ditto.pubPublished at
2025-10-26 13:20:07 UTCEvent JSON
{
"id": "30ce7eb8f8d46558a083aa8cc180b2b0ff394ef76eb78016a3e9f0894057e4b6",
"pubkey": "c35a8fae05a838b863707803bb1fdfcfcbb39adcf01ee1a9fc52ef44998ce4c0",
"created_at": 1761484807,
"kind": 1,
"tags": [
[
"p",
"dff0e1a3c0c316016bd992fbc489a68db295821de685bfbbfab7d505acc3bfcd",
"wss://relay.ditto.pub/"
],
[
"p",
"e1c8b61cf005d1837033f8b9c49b57736fad8db5114fbfe3e56936ed00018c49",
"wss://relay.ditto.pub/"
],
[
"p",
"d1626f05a38d36e80f92ca33d0727e626e3e9d1f99a79320c0382b90f6113d5b",
"wss://relay.ditto.pub/"
],
[
"p",
"10d72613f972eb97326420981ae8004aa2718f5e9b95837db7416e2d293d01ff",
"wss://relay.ditto.pub/"
],
[
"e",
"8218c8b570d4bb7aa7d2d51afc13e06a7b7356c726716287e5a8744b920f84e2",
"wss://relay.ditto.pub/",
"reply"
],
[
"proxy",
"https://ioc.exchange/users/azonenberg/statuses/115440668338305631",
"activitypub"
],
[
"client",
"Mostr",
"31990:6be38f8c63df7dbf84db7ec4a6e6fbbd8d19dca3b980efad18585c46f04b26f9:mostr",
"wss://relay.ditto.pub/"
]
],
"content": "nostr:nprofile1qyt8wumn8ghj7un9d3shjtnyd968gmewwp6kytcqyr0lpcdrcrp3vqttmxf0h3yf56xm99vzrhngt0aml2ma2pdvcwlu6r99lkp nostr:nprofile1qyt8wumn8ghj7un9d3shjtnyd968gmewwp6kytcqyrsu3dsu7qzarqmsx0utn3ym2aekltvdk5g5l0lru45ndmgqqxxyjn0yjfz There is a fifo in the scopehal driver but it's capped at 5 waveforms in normal mode and flushed when you single/stop triggering. So I don't think that's the cause.\n\nGiven the memory depth dependency which I hadn't noticed before, I'm suspecting it might actually be half-sent waveforms queueing up in the socket buffer which is a tricky issue to address because we *want* to allow a lot of data in flight on high latency WAN connections to avoid WFM/s degradation (e.g. using a remote scope at work over VPN from home).\n\nWe might have to, for example, do some kind of nonblocking socket operations to delete an integer number of waveforms in flight (if there are any) when the trigger is stopped.\n\nIf this is in fact the cause, it's possible it could affect the ThunderScope after some planned optimizations to making it more latency tolerant. So we'll definitely want to root-cause and correct it.\n\nLasse - are you in the developer chat? If not, you should probably join so we can discuss there in front of the other devs.",
"sig": "c6bf4bac39720e9fe1e4416ac266685071ee21d84354309e7853f3d01d9c8fa7c3b2f10bea7260f8c20558f46257a9d7f2aca70f83bb52f3f3fc6c4d6ab9d893"
}