• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

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

robin-fo

Well-known member
2 minutes = 120 seconds700 kilobytes = 5600 bitst = 120 seconds, where t is timeD = 700 kilobytes, where D is the data file size t--- = R, where R is the transfer rate d120--- = 5.83700R = 5.83 kilobits per second
I cannot follow your calculation…

You get 5.83 KBytes per second, not KBits. If you multiply by 8, you get 47 Kbits/s, which is much less than the 230.4 you could theoretically get. In reality, a lot of time gets lost with handshaking and random waiting periods between frames.
 
Last edited:

cheesestraws

Well-known member
I wonder how that is compares to AirTalk

The short answer here is 'the speed of a network is a much more complicated thing than you seem to think'.

The long answer is: these are totally different beasts. The Farallon box just takes LocalTalk, which is 230.4 kbps, and modulates that over IR, then back again. No packet-level processing is done. It's just a media converter, so it can operate at very low latency, but it is literally just like a wireless wire with all its benefits and shortcomings.

But note that the 230.4 kbps of wired LocalTalk, and of the Farallon box, is line speed, and line speed does not mean actually achievable useful throughput, for a very large number of reasons. Line speed is the speed with which an individual bit or byte is transmitted down the line, it's the clock rate of the line itself.

First of all, you have the framing overhead, the packet bureaucracy, the mucking about that is necessary to get frames and packets to their intended destinations. You have collision avoidance. You have the fact that the machines are slow (one could, in theory, wedge a 10gbit Ethernet interface onto a 68000. Think it could push 10gig? Nope). And then you have latency, and latency is the big one.

Latency is the amount of time that a packet takes 'in flight' between two network nodes. It's the time it takes between leaving the source node and arriving at the destination node. And the problem with it is that during that time, both the source and destination are just sitting there scratching themselves and not doing much useful. And adding 'wait time' to the middle of a transmission means that the transmission as a whole takes longer, even if each individual packet in flight is being transmitted at line speed.

The link between AirTalk and the Mac is 230.4 kbit/sec. It has to be, or the whole thing wouldn't work, because that's the defined line rate of LocalTalk. The WiFi segment at the other end is running a lot faster. And yet the whole system has, basically unavoidably, less throughput for any given two machines, because the latency of IP multicast over WiFi is wildly unpredictable compared to the very strict latency requirements for wired LocalTalk. When you add Mini vMac and desktop OS's packet scheduling into the mix, it becomes more so, and this is fundamenta,ly why speeds into mini vMac tend to be a bit questionable over WiFi.

But even this isn't the full story. AirTalk is essentially a switch-like device, not just a repeater. It keeps track of the machines on the LocalTalk side of the device, and only relays LToUDP packets for machines it actually has. So this means that if you have two disjoint sets of machines with their own AirTalks, the aggregate throughput from set A to set B can be substantially greater than 230 kbit/sec, because the speed of the "backbone" is limited by the speed with which multicast packets can be transmitted over WiFi, not the speed of the line between the Mac and the AirTalk. And latency issues average out the more machines you have on a segment.

But it goes deeper still! This speed, of the WiFi segment, depends on a bewildering number of things, including how crappy the AP is, and how full the RF environment is. The RF bits of WiFi are deep magic and I am not going to pretend I understand them, but they too add their share of chaos to, especially, latency.

So, the tl;dr here is that when you're talking about the speed of a network, you must always be very careful about what you're actually measuring. Marketing materials pick the biggest number and quote that, but marketing is just the empirical mapping of the edges of falsehood, and marketing numbers don't mean very much.

The tl;dr of the tl;dr is: don't use AirTalk because it's fast. It isn't, even compared to wired LT. What it is is more convenient, and that's why it exists.
 

cheesestraws

Well-known member
as well as comparing mini vMac to AirTalk against AirTalk to AirTalk to see if my router or if mini vMac is my bottleneck.

Sorry for slowness in replying to things in this thread, I've been busy melting...

Yes, this would be worthwhile, along with testing with the machine running mini vMac on wired ethernet rather than WiFi. As I've noted upthread, something weird happens with mini vmac on a host that's wireless, at least if that host is a modern Mac. I've not heard from any Windows-runners or Linux-runners. Mini vMac obviously doesn't know whether the host is on wireless or wired, and I can only assume that the LToUDP packets are being deprioritised somewhere in OS X's wireless stack for some reason I don't understand.

And it works! Using two AirTalks, I was able to connect an iMac G4 (using CircuitTalk for native LocalTalk), a WGS 8550 and a a modern Mac using WiFi only.

This screenshot makes me unreasonably happy :) @CircuitBored and I did test that CircuitTalk and AirTalk worked together but it's really cool to know that people are using them together! And the sneaky M1 in there...
 

CircuitBored

Well-known member
This screenshot makes me unreasonably happy :) @CircuitBored and I did test that CircuitTalk and AirTalk worked together but it's really cool to know that people are using them together! And the sneaky M1 in there...

I wholeheartedly agree! It is super cool to see my work out in the wild, especially when it's being used in tandem with a product made by a friend of mine.

Thanks @robin-fo for re-verifying that AirTalk + CircuitTalk is a happy combination. I hadn't tested it on an iMac and more data is always good. I'm currently working on an ungodly combination of the two devices, which should (touch wood) make it into the wild in the next couple of months.
 

robin-fo

Well-known member
I'm currently working on an ungodly combination

Cool!

One minor drawback with the CircuitTalk in the iMac is that I cannot fully plug a serial cable into the port (you’d need to move the female connector outwards by 1-2mm). It still works great though… 👍🏻
 

CircuitBored

Well-known member
One minor drawback with the CircuitTalk in the iMac is that I cannot fully plug a serial cable into the port

This is sort of a "feature" as the clearance in that part of the iMac's chassis is very tight. You may have noticed that the pins on the mini-DIN are bent flat in order to make the board actually fit. With the mini-DIN any closer to the edge of the case you start to run into clearance issues both above and below it. That said, I'll see if I can shift it a millimetre or two in the next batch.
 

robin-fo

Well-known member
This screenshot makes me unreasonably happy
What about this one? The AppleTalk internet you see here consists of an AirTalk-"backbone", an Ethernet network and a standard LocalTalk network. I could have easily added more Macs, but I was somehow afraid that it might blow the fuse...:cool:

Routing is done by The Quadra and the Performa, both running System 7.1 and AIR 3.
Network.pngBildschirmfoto 2022-07-20 um 23.31.17.png
 
Last edited:

lisa2

Well-known member
robin-fo, can please explain how the air-talk and the Localtalk networks are physically connected to the Perfroma 475 router? Are they both plugged into the same port on the computer? I get that AIR is creating logical zones, but if the both zones are connected together then all the traffic on the wired zone is also on the AirTalk zone..
 

robin-fo

Well-known member
robin-fo, can please explain how the air-talk and the Localtalk networks are physically connected to the Perfroma 475 router? Are they both plugged into the same port on the computer? I get that AIR is creating logical zones, but if the both zones are connected together then all the traffic on the wired zone is also on the AirTalk zone..
Using AIR, you can use both modem and printer port individually for LocalTalk. The AirTalk was connected using a standard serial ("StyleWriter") cable to the printer port. On the modem port, there was a standard LocalTalk box with only one of the two Mini-DIN 3 connectors used (as shown in the drawing). AIR was configured on the Performa to seed the "Compact Macs" zone on the modem port with network number 101 and to seed the "AirTalk" zone and network number 100 on the printer port. On the Quadra however, the printer port with the AirTalk attached was non-seed and the internal Ethernet seeded the "EtherTalk Zone" with network range 102-102. Alternatively the seeding of the "AirTalk" zone/network could have been done on the Quadra instead with the Performa only seeding the "Compact Macs".
but if the both zones are connected together
Remember that the AIR is a router and not a bridge, so all networks connected to it stay individual networks
 

lisa2

Well-known member
Thanks robin-fo! I learned something today. Never knew that the Macintosh hardware could support LocalTalk signaling on both ports at the same time. I wonder if doing this reduces the localtalk bandwith since both ports are using the same SCC chip. I will try to test this.
 

retr01

Member
I cannot follow your calculation…

You get 5.83 KBytes per second, not KBits. If you multiply by 8, you get 47 Kbits/s, which is much less than the 230.4 you could theoretically get. In reality, a lot of time gets lost with handshaking and random waiting periods between frames.

Ah! I see. Thank you for clarifying. :)
 

retr01

Member
The short answer here is 'the speed of a network is a much more complicated thing than you seem to think'.

The long answer is: these are totally different beasts. The Farallon box just takes LocalTalk, which is 230.4 kbps, and modulates that over IR, then back again. No packet-level processing is done. It's just a media converter, so it can operate at very low latency, but it is literally just like a wireless wire with all its benefits and shortcomings.

...

Thank you, @cheesestraws, for clarifying. :)
 

cheesestraws

Well-known member
A quick note: @stepleton has identified, and @joshc and I have both verified, there appears to be a fairly big incompatibility between the 6100—of all things—and AirTalk. The 6100 just doesn't seem to see most frames I fire at it, and I do not yet know why.

If you are wanting to use a 6100 with your AirTalks, you might be best holding off until I can work out why it's broken. And if anyone has arcane knowledge about how the 6100's serial ports are different from everyone else's, I'd be all ears...
 

LaPorta

Well-known member
Good that we can at least rule that out. What about 7100 or 8100 machines? Any commonality there?
 

cheesestraws

Well-known member
Quick update for folks who are waiting: the next batch of boards has arrived but my normal supplier is out of stock of Mini DIN sockets. When they get some I'll get building. I don't really want to change socket at this stage,since the old ones seem pretty predictably decent.

I have a 6100. This weekend I can try it with mine to see if I can get a different result.

Sorry, only just saw this message. That would be great if you have time!
 

just.in.time

Well-known member
Sorry, only just saw this message. That would be great if you have time!
I did have a chance to try it. Setup was the following:

PM 6100/66 w/PC Compatibility card (powered off), running Mac OS 8.1, AirTalk on Printer port.

Mini vMac SE FDHD running 7.1 (or 7.0.1, would have to double check)

The Mini vMac SE could see the 6100 in the Chooser, however selecting it would freeze it for about 30 seconds until an error about server not responsive. During this time the AirTalk LT section lights would all flash ever 5 or 10 seconds, including the Err red light.

The 6100 was unable to see the Mini vMac SE, selecting AppleShare in the Chooser was causing the LT section light to all flash ~1/second, including Err red light. Though interestingly once I had closed out of Mini vMac (and had no other AirTalks powered on, so no Apple Talk devices on the WiFi), the 6100 Chooser -> Apple Share would flash the LT and UDP Tx lights only. Err and Rx for both sections stayed dark.

Let me know if you want me to try any other configuration and I can do that tonight or tomorrow night.
 
Top