In this post, I looked into the concept of Packets. I have a great fondness for packets, as it is packets that move the majority of the data in the world.
They are really good at moving data around in an ad-hoc fashion. Any piece of data can be broken down, transmitted and reassembled without any distortion.
Fall of the Packets
But that process is slow. It can take milliseconds to disassemble the data into manageable chunks, then add in all of the extra address, protocol information... and the data hasn't even left your device yet.
Obviously, when it comes to emails, images, or text a delay of even a couple of hundred milliseconds isn't going to be noticed by a mere human. So once again, the packet wins.
Time-critical Applications
However, let's take audio. I will go into how digital audio works at a later stage, but for now you should know that digital audio (e.g. CDs, common live audio mixers, MP3s etc) is made up of 24-bits of data, give or take. (a "bit" is a 0 or a 1). This is repeated around about 48 thousand times a second; or once every 0.02 milliseconds.
So, if the a "packet" of audio data arrived milliseconds out of sequence, we would end up with noise. And not the good type; I'm thinking Lou Reid's Metal Machine Music.
A Saviour in time
To get around this we need a faster method of transport. Enter Time-Division Multiplexing!
Modern computing equipment is more than capable of processing things at speeds fast enough for "real-time" applications like audio. A 2.66 GHz processor (like one of the 8 I am using now) can process a "sample" (that 24-bit thing I was talking about before) in about 0.3 nanoseconds.
For those of you that don't like maths, that's about 65,000 audio "samples" per "Sample"; meaning that any one of my 8 processors could play music for me and still only be working to 1/65,000th of its capacity.
Okay, so those numbers may have caused you to glaze over. Hence the "bird on the wire" to liven things up.
The thing to take away from the maths above is that even a fairly stock-standard computer takes one look at time-critical audio and laughs it off.
So, how can this help us with faster data transport?
Enter Time-division Multiplexing
The simplest way is to give each "device," or data-source, an "address" that corresponds to a certain time.
This "address" will then offset the data from each device by a certain time; device 0 will have a 0s offset; device 1 will have an offset of 0.02 microseconds, device 2 will have an offset of 0.04 microseconds... until we get to device 65,000 something.
Let's have a look at the diagram below:
First up, the Green wants to transmit some data, so it goes into the first "timeslot" (a timeslot is the base unit of a TDM network; kind of like a packet). Since there is no "Red" data in the first timeslot, the next slot is blank.
However in the second "Timeslot" both Green and Red want to transmit something. Green goes first and transmits its data, and then Red transmits, so we see a Green block and then a Red block.
And so on; each device waits for its turn, then transmits the data.
To read the data you need to know which data you are looking for, wait until that "timeslot" appears, and then read the data.
Forgiving the Chinese characters, this image shows the same concept, but for more devices. On the left we see all of the data that we want to transmit. In the middle we can see that each device waits until it is their turn, then transmits like crazy.
On the right hand side we can pick out any particular timeslot and read the data.
Why should we care?
One thing that you may have noticed in the above is that all of the devices have the ability to read all of the data on the network.
Time-Division Multiplexing (TDM) Networks are relatively simple; each device is directly connected to the next, and will usually transmit the entirety of the data to all connected devices.
One application that really likes this is large matrices. For example, take a communications. You could have 100 people trying to talk to each other. Any one of those 100 people may want to talk to any (or all) of the other 99 users at once.
A TDM Network makes mincemeat of this; each user is allocated a timeslot on the network. When they talk, their audio fills up their timeslot. When they aren't talking, nothing is transmitted (remember our Red and Green above).
At the other end, the user receiving the call pulls out the audio from all of the timeslots that they want to listen to.
Of course, this requires a bit of computer processing, but most common communications networks are more than capable of handling thousands of users on one TDM network.
In fact, most matrix routers/switchers employ a TDM network of one kind of another. The concept of a TDM can be applied inside a single "box". For example, a video matrix. Each input takes up one timeslot; each output reads from one timeslot. In this way, any input can go to any output without causing interruption to the video. When a TDM is contained in a single box, it is usually referred to as a backplane.
Downfalls?
The biggest drawback of a TDM TDM network is limited not by the address space, but by the processing speed of the devices and the size of the data being transmitted. Transmitting audio through a computer's processor gives many thousands of audio channels, however transmitting high-definition video over standard networking architecture yields only tens of channels.
TDM networks need to be connected to all other devices in the network. There are some funky devices out there that will bridge two TDM networks, but these are usually limited.
TDM networks are also super sensitive to clocking. Once again, I'll go into clocking in a different article, but for the time being think of it this way.
Think of all of the timeslots as trains. However on TDM station there aren't any "The next train goes to Sydney" announcements, there is only a timetable.
If you only have your wristwatch to go on, you may catch the wrong train; how do you know that your 1:13 is the same as the railway's 1:13?
However, if there is a clock on the station, and one on the train, then you can confirm that your train is the right one before you board.
The same thing happens with TDM; unless you synchronise all of the devices you have no way of knowing which "train" (timeslot) is the right one.
Conclusion
I hope you have enjoyed this. Please comment if you don't "get it" and I will edit this post in order to make it easier to understand.
TDM networks are prevalent in audio, video and communications networks, and that's why I wanted to get this up earlier rather than later. Apologies for the maths earlier; I hope the bird picture helped you through that.
