Hi Joe, thanks for having entertained this email of mine! I'll admit that I had a few, erm, drinks while writing it. This time at least, I'm still writing in sobriety. Cheers!
On Monday, 4 August 2025 07:36:43 CEST Joe Abley wrote: > On 4 Aug 2025, at 04:04, Michael De Roover <[email protected]> wrote: > > [...] And that's what I > > actually want for these ATtiny85 chips in situ. They will have a serial > > interface for whenever I want to interface with them and probe their > > internal state. But for the most part, they will be shouting into the > > void. > Your application seems like it is plausibly one-way ("I tell you regularly > about my sense of time" does not invite a reply or a triggering question) > and that the scope of the announcement is naturally limited (to whatever > you plug into your repurposed GPIO pins). By contrast, shouting into the > void from well-connected DNS servers is a known hazard and imposes costs on > third parties. I would say so too yeah. That chip in particular (the ATtiny85) does only one- way communication, with the option to be wired into an UART controller, or for those pins to just send out their data into.. well, nothing. I think it can do bidirectional communication too, but only if each has its own dedicated time slot, and only once I get around to implementing that. So far, I haven't done that yet. On the Arduino boards themselves which have hardware serial meanwhile, I use a different code base which does do bidirectional communication. Only one "CPU core" still, but at least the serial communication can leave both ends open and listen for commands in, while reporting its sense of time out every hour (well, what it thinks an hour is). > Requiring a session to be established as a bar to entry is a feature which > comes with a cost on the server (e.g. dealing with failed setup and > teardown) and on the client (e.g. setup overhead and its impact on > transaction latency) but it avoids the costs of not requiring a session. As > has been widely noted, those costs of session establishment also exist for > other successful protocols that are sensitive to latency and which often > involve short-lived transactions. I've observed that tonight on my ATtiny85's communication too, which got me to write this email. It seems that the 43% activity on the serial link (as received by a Silicon Labs CP210x UART Bridge), doesn't really bother anything further downstream. The USB hub is unbothered, same for the USB driver on my ThinkPad x220 running Debian, same for the `screen /dev/ttyUSB1 9600` session.. if that session is detached. Once it needs to draw all that serial data, the system starts to heat up. Detached and running my own fan driver, it maintains 70C. Attached meanwhile, it spikes up to 90C. So yeah, there is a real cost to dealing with the incoming data in a meaningful way. Having to do that for TCP transactions, I would consider it more or less the same thing. Stateful firewalls (e.g. iptables) would have to maintain state, while with UDP it doesn't (at least as far as I'm aware, could be mistaken). Doing that for a handful of transactions like AXFR and the odd device that insists on using TCP for its regular DNS queries, sure why not I guess. It's there, go ahead and use it if you have to. But to consider it the primary means of transferring DNS information, probably not a great idea. Come to think of it, I noticed something similar as a bottleneck in SSH. There were a handful of times in which I needed to execute many commands in quick succession to a given server. The establishing and tear-down of SSH sessions for each of those commands, came with hundreds of ms of overhead every time. Eventually I came across the concept of session multiplexing, where the session stays open for a while and remains available on a socket. That meant that only once does the session gets established, 10 commands or whatever get sent into that session, and then SSH tears it down if it idles for long enough (let's say 5 minutes). The time savings of that, compared to each of those 10 commands requiring its own setup and tear-down, it was enormous. Met vriendelijke groet, Michael De Roover Mail: [email protected] Web: michael.de.roover.eu.org What are ideas but thoughts in our heads, if we cannot collaborate to make them reality? -- [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
