• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Introducing (and interest check) AirTalk: Wireless plug-and-play LocalTalk dongles

cheesestraws

Well-known member
No, I mean ping just straight on the wireless network, rather than across the AirTalk virtual network.

I've got a couple of vague ideas what's going on but I don't have a strong clue. If you could run one across a single AP and see if that's better, that would be extremely helpful but that sounds quite a disruptive test to your network...
 

LaPorta

Well-known member
Not at all. I have one or two base stations I only use if I have extra machines to plug them in to. I will set it up as its own network to connect these to.

I can also get that ping for you straight from one machine to the other across the network; that I can easily do.
 

cheesestraws

Well-known member
I can also get that ping for you straight from one machine to the other across the network; that I can easily do.

The underlying question I am basically trying to answer is: is there generally high latency across the network, or are the APs specifically deprioritising/slowing down the kind of traffic AirTalk is using? Neither of those is great, but potential solutions/mitigations differ depending on which is the case.
 

CC_333

Well-known member
Do you have an option in AirPort Utility to turn on "IGMP snooping"?
I realize I'm not the intended recipient of that question, but I got curious nevertheless and checked my AirPort Utility to see if it has that option, and it does.

c
 

LaPorta

Well-known member
Some updated news: finally had some time to experiment with the AirTalks, Mac Portable, and my IWII. So, having isolated the machines to a dedicated AirPort Extreme that does indeed support (and has turned on) "snooping", the ImageWriter II prints at probably, if I had to guess, 1/4 the speed of normal, physical connected AppleTalk. I still get a red LED 5 with each and every receive flash of the other green LEDs, so there must be some sort of issue with what the IWII does on its end. It would be interesting to see just what might cause this (although @NJRoadfan gave us a possible mechanism on the previous page).

Tomorrow, now that I have a dedicated, isolated network, I will begin tests between machines copying files.
 

cheesestraws

Well-known member
Tomorrow, now that I have a dedicated, isolated network, I will begin tests between machines copying files.

Great. Would you mind checking the latency across that with a couple of modern machines like you did before, as well? I'm trying to get some data together about what latency will give what kind of results.
 

LaPorta

Well-known member
So between my 2012 Mac mini and my 2016 MBP, I get about ~200ms latency. Again, this could be due to there being other networks in my house within range and all. However, there is another thing to note: my house network is fairly speedy in general: meaning I can stream HD movies and such across the airports from my server.....again, though, my server is connected via ethernet so, oh well, I don't know :p. ANyhows, I will be set up in another house in a few months, so I will have to start over and maybe I will get something simpler set up.

Average of 7 ms for my hard-wired server.
 

LaPorta

Well-known member
Well, I did just do something I think to be rather cool: bridged my entire wireless/ethernet network through the AirTalk! What I did was connect the AirTalk straight to my iPrint Ethernet to LocalTalk adapter. The ethernet portion is connected into one of my AirPorts that extends my main house network. I then used the other AirTalks on my IIfx and Portable, and both were able to see my Macs that are hard-wired via Ethernet into my main network! This was what I had hoped for, as just having AirTalks only talk to each other seemed a bit limited to me. Boy, what a lot of things you can do with these little wonders when you fool around with them!
 

cheesestraws

Well-known member
What I did was connect the AirTalk straight to my iPrint Ethernet to LocalTalk adapter

Woohoo, I'm glad that worked! I've had one of mine plugged into my AppleTalk router box and it's been really handy. I'm very glad to hear it works with the iPrint too.

However, there is another thing to note: my house network is fairly speedy in general: meaning I can stream HD movies and such across the airports from my server

Yup, but part of the point here is that TCP/IP compensates for links that are high bandwidth but high latency (e.g. you can get a lot of data down them but it takes a while to arrive; most Internet links are of this kind anyway, because the Internet is big), and is designed for those links, which is why WiFi works so well most of the time. AppleTalk, which was really designed for wired LANs, doesn't deal with that kind of link anywhere near so well, so it'd be totally normal to have a network that AppleTalk would work really badly on and TCP/IP would be basically fine on (this is also one of the reasons why AFP-over-TCP often performs better). If that makes sense. So that's why I'm asking, I'm trying to get a feeling for how AppleTalk works under various circumstances it doesn't usually run under. :)

Boy, what a lot of things you can do with these little wonders when you fool around with them!

I'm really glad you're having fun with them :-D.
 

LaPorta

Well-known member
Now, I know absolutely nothing about this at all, and have no knowledge of how these things work. But…

Would it be possible to “encapsulate” the AppleTalk packets inside something that the wireless routers would treat with the same care as, say, HD video? So like you have the incoming packet to the AirTalk from a Mac. Something on the AirTalk “boxes” the packet inside this wrapper, sends it to the router that treats it as
Something else, then sends that to the other AirTalk, which then “unboxes” the packet and passes it to the other Mac.

I might just be blowing smoke, but is anything like that possible to fool the router?
 

cheesestraws

Well-known member
Something else, then sends that to the other AirTalk, which then “unboxes” the packet and passes it to the other Mac.

That's pretty much exactly what AirTalk already does to 'smuggle' AppleTalk past APs that don't speak it. The problem is deeper and harder to fix, unfortunately: all the AppleTalk protocols basically request a fixed amount of data at once (this is a simplification but it'll do here). So, let's do a bit of a thought experiment. We'll pretend that sending back a chunk of data takes 100ms, that the query takes 1ms, and that the network link has a latency of 1ms. So it looks like this:

  • Computer A asks for a chunk of data (1ms).
  • Computer B waits for the request to arrive (1ms latency), then sends the data.
  • Computer A waits for another 1ms (latency) for the first part of the data to arrive, then 100ms for the data.
  • Repeat from beginning
In this world, a chunk of data takes 103ms to transfer from computer A to computer B.

Let's transfer this same chunk of data over a network link with latency 50ms:
  • Computer A asks for a chunk of data (1ms).
  • Computer B waits for the request to arrive (50ms latency), then sends the data.
  • Computer A waits for another 50ms (latency) for the first part of the data to arrive, then 100ms for the data.
  • Repeat from beginning
The total here is 203ms! We've nearly halved the amount of data that has been transferred per second just by making data take longer to get from one end of the link to the other.

Try thinking of it like this: imagine you're having a conversation with someone by letter, but your letters can only be a fixed length (like an aerogramme or something). If you'd been having this conversation for a while but it suddenly took twice as long for the letter to get to its destination, you'd be able to have less conversation in a given time.

TCP deals with this by allowing the size of the chunk of data to change to adapt to changing network conditions: so if you're on a high-latency high-bandwidth link, the amount of data you can send before the other end has to explicitly say 'got that, please send the next bit' can be much higher. So you don't need as many round-trips.

In our letter analogy, that is like - letters take longer to arrive, but we can write a longer letter, so we can still say all we need to. But AppleTalk can't do that adaptation, all the letters are fixed length. So the only way you could really fix this in all cases would to be to build a time machine, because it'd need perfect knowledge of the future.

edit: it's also worth adding that things like HD video streaming pre-download a big chunk of video to smoothe out variations in the network and to hide the latency problem. This option isn't available to AppleTalk (and also isn't available to me at work, where I wrangle sending live video over the Internet; and at that point one becomes very aware of the tradeoffs).
 
Last edited:

LaPorta

Well-known member
Look, don't be so glum on the possibilities. I am sure that you can write some code aptly named flux capacitor and make the final option workable :p
 

LaPorta

Well-known member
Some further tests: Have my Portable and IIfx via AirTalk, and my SE FDHD connected via Ethernet over AirTalk/iPrint bridge, and all seem to function nicely. I copied an 800k floppy image from the IIfx to the Portable in three minutes, which is fairly acceptable over what the lowest common denominator would be (straight serial-based LocalTalk). I did encounter an interesting issue: I had my IIfx connected to the network via it's ethernet card (so I could copy what I needed from my Quicksilver). My Portable saw it in the Chooser, but could not actually connect to it: it sat with watch cursor for about a minute and returned an error message. This had not happened previously. However, I realized that I still had an AirTalk connected to it - even though the Ethernet port was selected for AppleTalk, might the AirTalk still have been somehow broadcasting the availability of the IIfx, confusing the Portable somehow? Maybe it was just a glitch, but I will tomorrow hook the AirTalk to the SE and use the SE's ethernet connection, and see if the same error occurs.
 

cheesestraws

Well-known member
Maybe it was just a glitch, but I will tomorrow hook the AirTalk to the SE and use the SE's ethernet connection, and see if the same error occurs

This is all brilliant stuff, thankyou. I think I know what this is about: it takes longer for a computer to "go away" on the wireless network than it does on a wired one, so if you move a computer from one network interface to another, then try to contact it at its old address, before it broadcasts information about its new one, it'll sit there trying to contact it for longer than it would normally. I'll try to work out what I can do to ameliorate this.

More good news here is that techfury found a major bug in my firmware which would have damaged the performance in high-latency situations, so the situation there may not be as dire as I had feared. I'll test it here and then try to work out how to get it onto your devices, @LaPorta, to see if it makes your life better.
 

LaPorta

Well-known member
If there’s a way to flash the device, I’ll give it a go. I only have Macs, but my 2020 iMac has Windows 10 via Boot Camp if need be.
 

cheesestraws

Well-known member
Thanks all for all the encouragement! Due to both family and work stuff, this has been going slower the last two or three weeks, but it has still been going.
  • There's an updated firmware! This fixes the power saving bug, and also adds a "recovery/setup/bootstrap" feature for people who can't get the chooser extension onto their old mac without having the network working. This feature allows you to initially set up the WiFi from a modern computer or phone (with WiFi). I'm getting testers set up with the new firmware at the moment as I have time to send and explain it.

  • The new PCB design is done-ish, based on feedback: the most noticeable addition is that it now has two ADB ports so it can be used as a passthrough. It also has screw holes and an LED header so it can have a case. I probably won't be getting those manufactured till next month now—I am away from home for most of the remainder of this one. I've also got a "dust cover" which is really just a piece of PCB material with the screw holes in the right place so it will match up and stop things getting into the circuitry, but more excitingly...

  • Another member here (who can make themselves known if they'd like to) is designing a 3D-printable case for it in the proper style. More information will doubtless follow on that, but it means that hopefully people who want this to look like an actual project will be able to.
A question I would like some feedback on:

How annoying would it be if IIfx/Q9x0 serial ports had to be in compatible mode to use this? I haven't got ... very far in working out why they're not working in "fast" mode, partly because of lack of time. I'm wondering whether people would hate it if in the interests of getting the thing finished I just put "fast" mode for those machines on an incompatibility list...
 
Top