Just a quick note; I have an article in AV Magazine, Issue 21:
http://www.av.net.au/
http://www.av.net.au/contents/issue_21/soh_network.pdf
Since it relates to a lot of the things covered in this blog I thought I should post it.
Have a good one!
This is a story of technology and the people it serves.
Monday, December 19, 2011
Sunday, November 20, 2011
Wave Theory - Part 1
Apologies for the delay here. I started writing a number of things into this post, however it became a long, boring, technical marathon. So I'm going to break up these types of articles and post some interstitial things as well. I originally wanted to look at Quantization Noise, but there were so many concepts involved that I decided to start with the "Basics".
Superposition
Superposition
Science and nature detest corners. Curves, even constantly varying ones, are much easier to deal with. This is because curves add together nicely through a principle called "Superposition." Long story short, curves can be added together and taken apart without any difficulty.
If you've ever looked at music on an oscilloscope, you'll see a random squiggle that never seems to stop changing. Whilst it can make for an interesting visual effect, it's not very helpful. However, due to Superposition, we can break that seemingly random signal down into the component inputs. This is usually called the Fourier Function Transform, but you might be more familiar with the term "Spectrum Analyser." (I strongly advise not looking too deeply into it unless you really like maths.)
If you run a signal though a Spectrum Analyser, you change the random squiggle into a series of columns. Each column represents a frequency range; the height of each column denotes the amount that each particular frequency range is contributing to the original signal.
 |
| Input signals (Left) and the resultant Spectrum Analysis (Right) Thanks Wiki Commons |
The top picture is your standard sine-wave. Since there is only one frequency, the Spectrum Analysis shows us that information; one tall column. All of the power in this signal is contained within that narrow frequency range.
The second set of images shows static; a totally random signal at low level. If we look at the Spectrum Analysis, you'll see that the power is spread randomly across all frequencies. We'll get into the origins of static one of these days. Just not today.
The last set of images shows these two signals superimposed onto each other. At each point, the "height" of the two signals is added together to make the bottom left image. It's a bit hard to see in the image, but you'll note that the curve is no longer smooth. However, this is nearly impossible to tell by looking at the input signal.
However, when we look at the Spectrum Analysis, we can clearly see that most of the energy is still in that main frequency range, but there is energy spread out across the other frequencies.
This effect is normally called "Noise".
Repeating Patterns
There is one other cool thing about superposition.
Basically, any repeating pattern can be built up with the right combination of sine waves. Take, for instance, a square wave:
 |
| Once again, Thanks Wiki! |
The Red line is a "true" square wave. The Green-dashed line shows a Fourier Approximation of the square wave using 5 component waves. The blue-dashed line uses 15 component waves. These waves are superimposed onto each other, like this:
The left-hand images shows our four component waves and their relative powers. Just by looking at the left-hand side, we can see that the "Fundamental" frequency, which is the same as the frequency of the square wave, has the most power.
The second column shows the superposition, but without adding the waves together. The third column shows the resultant, superimposed wave. As we go down the list, it starts looking more and more like a square wave.
The right-hand column, again, is what you'd see if you put the signal into a Spectrum analyser. There's a couple of points to note here:
- For a square wave of a fundamental frequency F, the frequency of the component waves (f) is as follows - f = (2n+1)F, where n starts at 0 and goes to infinity
- The power of each wave drops off significantly as n gets bigger (or, to put it another way, as the frequency of the component wave goes up, the power of that component goes down).
It turns out that once you get past n=16 or so, the power in the higher frequencies is so low that it no longer matters if you include them or not.
Next Time
It is very tempting to plough ahead here and talk about why I just wrecked your mind with superposition, but I won't.
Here's a hint though, it has to do with square waves and noise, and why digital and analogue aren't all that different.
As always, please feel free to post questions in the comments section!
Tuesday, November 1, 2011
Pulse-Code Modulation - Music to our ears
Okay, so we've just spent a lot of time looking at how data moves around a network. I hope that you were all with me for the ride. If not then please feel free to comment on any of the posts and I'll answer your post.
For the next couple of weeks I'd like to start looking at the data that you actually put into those packets.
One of the easiest places to start looking at digital signals is the humble Pulse-code Modulation, or PCM, method of encoding analogue information into a digital signal.
Analogue vs Digital
No, I'm not going to get into the "aesthetic" differences between analogue and digital, save to say that the only instrument that you can trust is your own ears. If it sounds better to you, then it sounds better to you.
I would like, however, to clarify something quickly. An "Analogue" signal is a proportionate signal with no real limitation. The local air pressure around a microphone or a signal can be measured by a device and turned into an electrical signal that is proportionate to the pressure. The higher the pressure, the higher the voltage. The voltage is an "Analogy" of the pressure.
This is what we refer to as an "Analogue" signal. Most simple electronic devices will process and run on analogue signals.
At some point, everything is an "Analogue" signal; the pressure changes that reach your ear drums or the light changes that reach your retinas are "Analogue".
A "Digital" signal, however, is somehow encoded so that it is no longer proportionate to the original signal. Through some kind of electronic process the Analogue signal is broken down into symbols of some kind that are readable only by devices that use that format. Before we can interact with them again then they need to be converted into an Analogue signal again. This process is called "Encoding" (Analogue to Digital) and "Decoding" (Digital to Analogue). Combine "enCOder" and "DECoder" and you get CODEC... but we'll get to those later.
Pulse-Code Modulation
Anyone who's ever Google'd "Digital Audio" will have seen a picture similar to this one:
Let's assume that we are looking at the Encode (Analogue to Digital) side of things (although the process is exactly the same in reverse).
The red line is our input signal; a standard sine-wave. This could be anything; an audio signal, the number of people that like or dislike the current Prime Minister... it doesn't matter. We have a signal that is changing as time goes on.
The analogue signal is continuous and unbroken.
Pulse-Code Modulation sets a value (shown above as 0-15) for each equivalent amplitude. To convert the signal into a digital one, we record the value of the analogue signal at the start of each of the time divisions shown along the bottom access. This process is called "Sampling" - you are taking a sample of the Analogue signal at each of the time divisions.
You'll note that on the image above you can see a difference between the continuous Analogue (Red) signal and the Digital (Grey) one. It looks like a lot, right? In fact, the small differences in images like the above are one of the main arguments used by Analogue supporters. However, there is something missing from this picture...
Bit Rate
The picture above gives you a pretty good look at what you'd see in a phone-line; a 4-bit system. A bit is a single binary "symbol". One bit gives two states; two bits gives four, three bits give eight and four bits give sixteen states.
The number of "bits" that a digital signal contains is referred to as the Bit Depth. In basic terms, the higher the bit depth, the better the quality.
Even your most basic audio (CD-quality) has a bit depth of 16 bits; or about 65 thousand different states. The Human ear isn't really able to detect that kind of resolution; it would be like trying to look at the millimetre markings on a ruler that was 10 meters away.
Still, there are higher bit depths; standard digital audio (AES/EBU-3, which I will cover in a future article) runs at 20 bits (1,048,576 states) or at 24 bits (16,777,216 states). At this point, you're pretty much splitting hairs with a 2000-pound bomb...
But there is another factor that affects the quality of the sound; the rate at which the audio is sampled.
As a general rule, you want to take a sample at twice the frequency of the highest frequency you want to hear. The label on a new-born baby reads 20Hz-20,000Hz, although by the time you've used an MP3 player and gone to a concert or two you will be lucky if you can hear above about 17,000Hz.
Thus, the main sampling rate used in digital audio is 44.1kHz (CD-quality). "Professionals" will use 48kHz, or even go as high as 96kHz. Once again; at that level you are recording detail that humans just can't perceive. It's like taking a photo in ultraviolet; it might look brilliant, but there is no way for us to see the result.
I would like to continue this article, but in the interest of keeping things concise I will hold off for the time being. Next article I will look at a couple of the strange effects of PCM, and how we avoid them.
But for now, I must away. Until next time.
For the next couple of weeks I'd like to start looking at the data that you actually put into those packets.
One of the easiest places to start looking at digital signals is the humble Pulse-code Modulation, or PCM, method of encoding analogue information into a digital signal.
Analogue vs Digital
No, I'm not going to get into the "aesthetic" differences between analogue and digital, save to say that the only instrument that you can trust is your own ears. If it sounds better to you, then it sounds better to you.
I would like, however, to clarify something quickly. An "Analogue" signal is a proportionate signal with no real limitation. The local air pressure around a microphone or a signal can be measured by a device and turned into an electrical signal that is proportionate to the pressure. The higher the pressure, the higher the voltage. The voltage is an "Analogy" of the pressure.
This is what we refer to as an "Analogue" signal. Most simple electronic devices will process and run on analogue signals.
At some point, everything is an "Analogue" signal; the pressure changes that reach your ear drums or the light changes that reach your retinas are "Analogue".
A "Digital" signal, however, is somehow encoded so that it is no longer proportionate to the original signal. Through some kind of electronic process the Analogue signal is broken down into symbols of some kind that are readable only by devices that use that format. Before we can interact with them again then they need to be converted into an Analogue signal again. This process is called "Encoding" (Analogue to Digital) and "Decoding" (Digital to Analogue). Combine "enCOder" and "DECoder" and you get CODEC... but we'll get to those later.
Pulse-Code Modulation
Anyone who's ever Google'd "Digital Audio" will have seen a picture similar to this one:
The red line is our input signal; a standard sine-wave. This could be anything; an audio signal, the number of people that like or dislike the current Prime Minister... it doesn't matter. We have a signal that is changing as time goes on.
The analogue signal is continuous and unbroken.
Pulse-Code Modulation sets a value (shown above as 0-15) for each equivalent amplitude. To convert the signal into a digital one, we record the value of the analogue signal at the start of each of the time divisions shown along the bottom access. This process is called "Sampling" - you are taking a sample of the Analogue signal at each of the time divisions.
You'll note that on the image above you can see a difference between the continuous Analogue (Red) signal and the Digital (Grey) one. It looks like a lot, right? In fact, the small differences in images like the above are one of the main arguments used by Analogue supporters. However, there is something missing from this picture...
Bit Rate
The picture above gives you a pretty good look at what you'd see in a phone-line; a 4-bit system. A bit is a single binary "symbol". One bit gives two states; two bits gives four, three bits give eight and four bits give sixteen states.
The number of "bits" that a digital signal contains is referred to as the Bit Depth. In basic terms, the higher the bit depth, the better the quality.
Even your most basic audio (CD-quality) has a bit depth of 16 bits; or about 65 thousand different states. The Human ear isn't really able to detect that kind of resolution; it would be like trying to look at the millimetre markings on a ruler that was 10 meters away.
Still, there are higher bit depths; standard digital audio (AES/EBU-3, which I will cover in a future article) runs at 20 bits (1,048,576 states) or at 24 bits (16,777,216 states). At this point, you're pretty much splitting hairs with a 2000-pound bomb...
But there is another factor that affects the quality of the sound; the rate at which the audio is sampled.
As a general rule, you want to take a sample at twice the frequency of the highest frequency you want to hear. The label on a new-born baby reads 20Hz-20,000Hz, although by the time you've used an MP3 player and gone to a concert or two you will be lucky if you can hear above about 17,000Hz.
Thus, the main sampling rate used in digital audio is 44.1kHz (CD-quality). "Professionals" will use 48kHz, or even go as high as 96kHz. Once again; at that level you are recording detail that humans just can't perceive. It's like taking a photo in ultraviolet; it might look brilliant, but there is no way for us to see the result.
I would like to continue this article, but in the interest of keeping things concise I will hold off for the time being. Next article I will look at a couple of the strange effects of PCM, and how we avoid them.
But for now, I must away. Until next time.
Tuesday, October 25, 2011
1.5 Mile Wireless connection
Just saw this pop up on Engadget. Wireless repeaters that go for 1.5 miles (2.4km).
I'm thinking large stadia or live sites where you'd need to move a bunch of signals around but it would be impractical to run Cat5 across the ground, or events like the Sydney New Year's Eve fireworks where there are barges spread out across the harbour...
Press-release and first thoughts:
http://www.engadget.com/2011/10/24/amped-wireless-gives-your-wifi-1-5-mile-range-never-lose-signal/
Company Signal:
http://www.ampedwireless.com/
I'm thinking large stadia or live sites where you'd need to move a bunch of signals around but it would be impractical to run Cat5 across the ground, or events like the Sydney New Year's Eve fireworks where there are barges spread out across the harbour...
Press-release and first thoughts:
http://www.engadget.com/2011/10/24/amped-wireless-gives-your-wifi-1-5-mile-range-never-lose-signal/
Company Signal:
http://www.ampedwireless.com/
Sunday, October 16, 2011
Layers of the Internet - Part 4
If you are new to this area, or are looking for the first three parts of this series, please use the following links:
Layer 1 - Link Layer
Layer 2- Internet Layer
Layer 3- Transport Layer
To recap quickly, the Link layer is the physical connection between devices (be it wireless, electrical or optical).
The Internet Layer is the layer that deals with the virtual separation of the entire Layer 1 network into smaller, virtual networks, and also allows traffic to be routed from one side of the planet to another.
The Transport Layer deals with two main things; where the data goes inside the devices that receive it, and also how the packets are passed around the networks (e.g. error correction protocols - re-sending a packet that never arrived at the destination.
Layer 4 - The Application Layer
For a second, let's think about what we are trying to achieve with a data network. We are trying to move information (be it computer data, an image, live audio... anything) from one point to another. If we look at what we've done in layers 1-3, we can see that we've done nothing but move the data from one end of the earth to the other.
.
But before any data can be delivered, we have to actually work out what data we are going to transport, why we around going to transport it and then what we are going to do with it at the other end. Data is useless unless we actually do something with it. For example, you could send a friend a photo, but if they can't view it then there was no point to transferring the data in the first place.
This is where the application layer comes in. It is the layer of the Internet that interfaces with the Users, but it is also the layer where we actually change the information that we are sending.
But Layer 4 isn't all about the Users, there's a lot of background processes involved. Let's have a quick look at a simple internet action; checking this blog:
So, from your 31 keystrokes (including the "enter" key at the end) your browser and the Server have been communicating at Layer 4. You'll notice that I barely mentioned the Layer 1-3 protocols; and that is because at Layer 4, just like all of the layers below it, the lower levels are transparent. It doesn't matter that I'm on a wireless connection and the server is on a optical fibre connection; they are connected up to Layer 3, and that's all that matters.
I'll be doing little write-ups on the various protocols as I continue to write this blog, so please stay tuned to the Glossary. Once I write an article on each protocol I will link it from the Glossary.
Layer 1 - Link Layer
Layer 2- Internet Layer
Layer 3- Transport Layer
To recap quickly, the Link layer is the physical connection between devices (be it wireless, electrical or optical).
The Internet Layer is the layer that deals with the virtual separation of the entire Layer 1 network into smaller, virtual networks, and also allows traffic to be routed from one side of the planet to another.
The Transport Layer deals with two main things; where the data goes inside the devices that receive it, and also how the packets are passed around the networks (e.g. error correction protocols - re-sending a packet that never arrived at the destination.
Layer 4 - The Application Layer
For a second, let's think about what we are trying to achieve with a data network. We are trying to move information (be it computer data, an image, live audio... anything) from one point to another. If we look at what we've done in layers 1-3, we can see that we've done nothing but move the data from one end of the earth to the other.
 |
| Layers! Layer 4 is like the river and the clouds above; they rely on the lower layers of the earth, but they don't really care about them |
.
But before any data can be delivered, we have to actually work out what data we are going to transport, why we around going to transport it and then what we are going to do with it at the other end. Data is useless unless we actually do something with it. For example, you could send a friend a photo, but if they can't view it then there was no point to transferring the data in the first place.
This is where the application layer comes in. It is the layer of the Internet that interfaces with the Users, but it is also the layer where we actually change the information that we are sending.
But Layer 4 isn't all about the Users, there's a lot of background processes involved. Let's have a quick look at a simple internet action; checking this blog:
- Step 1: You open your browser and type "http://arts-comms.blogspot.com". This is the start of the process; you enter a small amount of data; 30 characters. It's not much when you think about it.
- Step 2: Your browser tries to find the address of this page. If you were going to send a letter to a friend you couldn't just write their name on an envelope, post it, and hope for the best. The "Human-readable" Universal Resource Locator (URL) is similar to you friend's name; you can use it to describe them and look them up, but it isn't exactly an address. So, before your browser starts downloading this page, it looks out for a Domain Name Server (DNS) that will translate the URL into a TCP/IP Address.This address combines the Layer 2 and 3 addresses for the webpage. In this case the IP part of the address is 74.125.71.132, and the port is 80. This could be written 74.125.71.132:80.
- Step 3: Your browser now requests a session with the blogspot.com webserver. Now that your browser knows where to look, it will send a request to 74.125.71.132:80 to ask if it can start talking to the Server. The server will normally check that there are no bans on your device, or any other reasons that it wouldn't want to talk to you.
- Step 4: The Server opens a port and allows a session to begin. Should everything in Step 3 check out, the server will allocate a port number (this can be random, or fixed; it depends on the server) and then sends the information to your browser, letting it know that it's all good to go.
- Step 5: Your Browser requests the Webpage. Now that the Server and your browser are talking, the browser finally asks for this page, sending along with the request any additional information that might be required (e.g. your login details, or which exact page you're requesting).
- Step 6: The Server retrieves the webpage from its hard drive, and then transmits it as a series of packets. If you were to send a entire webpage as a single packet, it would be huge, and that would slow it down through the Internet. So the Server splits up the webpage into a number of small packets, adds a bit of information to let your browser know the order of the packets, and then transmits them through the network.
- Step 7: Your browser assembles the webpage, checking for errors as it goes. There is always a chance that some packets will get lost in transit. However, since the server has added information for your browser, it will know if anything is missing. If something doesn't make it then your browser will re-request the missing pieces.
- Step 8: Close the Session. Once everything has been checked, and you're happily reading away, the browser sends a message to the Server to finish off the session that was opened in Step 4. Once this is closed the connection disappears from the internet.
So, from your 31 keystrokes (including the "enter" key at the end) your browser and the Server have been communicating at Layer 4. You'll notice that I barely mentioned the Layer 1-3 protocols; and that is because at Layer 4, just like all of the layers below it, the lower levels are transparent. It doesn't matter that I'm on a wireless connection and the server is on a optical fibre connection; they are connected up to Layer 3, and that's all that matters.
I'll be doing little write-ups on the various protocols as I continue to write this blog, so please stay tuned to the Glossary. Once I write an article on each protocol I will link it from the Glossary.
Monday, October 3, 2011
Layers of the Internet - Part 3
Before I start I would like to make a minor classification.
The "Layers" to which I am referring are the Internet Protocol layers, as specified in RFC 1122. I feel this model is more appropriate to the topics that I cover in this blog.
For those of you that wish to delve further into Networking as a subject, please refer to the Open Systems Interconnection (OSI) model. This model is the one that you would study in a networking degree, however it is slightly too specific for the purposes of this blog.
Layer 3 - The Transport Layer
In the previous two parts of this section of the blog, we looked at Layer 1 - The Link Layer and Layer 2 - The Internet Layer. In those layers, we say that each device was physically connected to all others, but with a bit of technology, we could divide up that huge network into smaller little sections.
As we have now connected on Layers 1 and 2, we can assume that our two devices are talking to each other. At this point it doesn't matter how that happens, or how many switches the packets have gone through in order to get from A to B. The tunnel through the Internet has been made, and for all intents and purposes, it isn't broken until the connection is shut off.
Layer 3 tells us two things; how a packet will move through a network, and where it will go when it gets there. In order to understand this we will examine two of the main Layer 3 Protocols, Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). And yes, if you noticed that the "TCP" looks very similar to the "TCP" in "TCP/IP", you'd be correct. Since TDP is the most common Layer 3 Protocol, and IP is the most common Layer 2 protocol, people refer to this model as the TCP/IP suite of protocols. However, due to the complexity of the protocol, I will start off with the UDP.
User Datagram Protocol
Take a moment to think about how many different network-enabled programs you are running now. On my machine I have two browsers with a few tabs in each, Skype, two email clients, a couple of automatic software updaters.... the list goes on. Now think about a lonely packet headed my way. It has the MAC address (from Layer 1) so it knows where my computer is. It has my IP address (from Layer 2) so it knows how to find me on the network. But once that packet finds its way into my wireless adaptor, where does it go? Is it a part of a webpage, or a message from a friend via Skype, or an email?
Both the UDP and TCP use a number, called a "Port," to direct a packet to the program that it needs to arrive at. Your network adaptor reads the Port number and forwards the data to the appropriate program for processing.
A UDP packet contains a bit of information that identifies it as a UDP packet and a Port number. That's about it. The advantage of this is that you have a smaller packet, which means faster transmission times. We'll look into this a bit later.
Transmission Control Protocol
Whilst a UDP packet basically only has the Port number, a TCP packet contains a lot of additional information. TCP packets can contain information relating to tracking and delivery protocols. For example, a TDP packet could identify that it was the 15th packet in a sequence, and that the receiving device should send notification of receipt.
This information can be used to make sure that packets that have been lost due to network errors can be re-requested and re-transmitted. Packets that take too long can killed off. Devices can send packets to each other to check the speed and path of the transmission.
All of this extra information makes the packets bigger, and hence slightly slower. However, in any non-real-time application this extra transmission time doesn't make much difference. Since very few transmissions actually require real-time transmission, the more Robust TCP is more common than UDP.
The main place we see UDP packets in the Arts industry is in audio/video transmissions, like Dante or AVB. UDP also requires less programming, and thus it is more common in smaller applications, so you may come across UDP systems in some control software.
"Layer 3 Switches"
Normally a switch will read the Layer 2 information (the IP Address) in order to find out where to send the packet. As we saw in the Layer 2 article, this is used to prevent every device receiving every packet on the network. If a switch only does this, then it is known as a Layer 2 switch.
However, some switches can be programmed to read the Layer 3 information. Switches can read the TCP information to adjust flow control (e.g. if the switch is over capacity, it can request the sending device to slow down the transmission rates). This can also allow for the ability for a switch to send more important packets before standard packets (e.g. Telephone or real-time audio is transmitted before a webpage).
The "Layers" to which I am referring are the Internet Protocol layers, as specified in RFC 1122. I feel this model is more appropriate to the topics that I cover in this blog.
For those of you that wish to delve further into Networking as a subject, please refer to the Open Systems Interconnection (OSI) model. This model is the one that you would study in a networking degree, however it is slightly too specific for the purposes of this blog.
Layer 3 - The Transport Layer
In the previous two parts of this section of the blog, we looked at Layer 1 - The Link Layer and Layer 2 - The Internet Layer. In those layers, we say that each device was physically connected to all others, but with a bit of technology, we could divide up that huge network into smaller little sections.
 |
| I'll admit, it's difficult to visualise the Transport Layer. Here's some model trains. |
As we have now connected on Layers 1 and 2, we can assume that our two devices are talking to each other. At this point it doesn't matter how that happens, or how many switches the packets have gone through in order to get from A to B. The tunnel through the Internet has been made, and for all intents and purposes, it isn't broken until the connection is shut off.
Layer 3 tells us two things; how a packet will move through a network, and where it will go when it gets there. In order to understand this we will examine two of the main Layer 3 Protocols, Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). And yes, if you noticed that the "TCP" looks very similar to the "TCP" in "TCP/IP", you'd be correct. Since TDP is the most common Layer 3 Protocol, and IP is the most common Layer 2 protocol, people refer to this model as the TCP/IP suite of protocols. However, due to the complexity of the protocol, I will start off with the UDP.
User Datagram Protocol
Take a moment to think about how many different network-enabled programs you are running now. On my machine I have two browsers with a few tabs in each, Skype, two email clients, a couple of automatic software updaters.... the list goes on. Now think about a lonely packet headed my way. It has the MAC address (from Layer 1) so it knows where my computer is. It has my IP address (from Layer 2) so it knows how to find me on the network. But once that packet finds its way into my wireless adaptor, where does it go? Is it a part of a webpage, or a message from a friend via Skype, or an email?
Both the UDP and TCP use a number, called a "Port," to direct a packet to the program that it needs to arrive at. Your network adaptor reads the Port number and forwards the data to the appropriate program for processing.
A UDP packet contains a bit of information that identifies it as a UDP packet and a Port number. That's about it. The advantage of this is that you have a smaller packet, which means faster transmission times. We'll look into this a bit later.
Transmission Control Protocol
Whilst a UDP packet basically only has the Port number, a TCP packet contains a lot of additional information. TCP packets can contain information relating to tracking and delivery protocols. For example, a TDP packet could identify that it was the 15th packet in a sequence, and that the receiving device should send notification of receipt.
This information can be used to make sure that packets that have been lost due to network errors can be re-requested and re-transmitted. Packets that take too long can killed off. Devices can send packets to each other to check the speed and path of the transmission.
All of this extra information makes the packets bigger, and hence slightly slower. However, in any non-real-time application this extra transmission time doesn't make much difference. Since very few transmissions actually require real-time transmission, the more Robust TCP is more common than UDP.
The main place we see UDP packets in the Arts industry is in audio/video transmissions, like Dante or AVB. UDP also requires less programming, and thus it is more common in smaller applications, so you may come across UDP systems in some control software.
"Layer 3 Switches"
Normally a switch will read the Layer 2 information (the IP Address) in order to find out where to send the packet. As we saw in the Layer 2 article, this is used to prevent every device receiving every packet on the network. If a switch only does this, then it is known as a Layer 2 switch.
However, some switches can be programmed to read the Layer 3 information. Switches can read the TCP information to adjust flow control (e.g. if the switch is over capacity, it can request the sending device to slow down the transmission rates). This can also allow for the ability for a switch to send more important packets before standard packets (e.g. Telephone or real-time audio is transmitted before a webpage).
Sunday, September 18, 2011
Interesting Enagadget article on Whitespace
http://www.engadget.com/2011/09/16/fcc-to-test-white-space-database-at-its-own-pace/
I know that I have been hoping to drip-feed information here, but occasionally I will need to jump the gun.
For those of you that don't know about the "White Space," it is referring to the spaces in the RF Spectrum that will be left between Television Channels, leaving clear bandwidth for devices to communicate on.
This spectrum remains unlicensed, and thus manufacturers can use this space for data transfer. Wireless Microphones operate in the same space; they are designed to work in the TV channel space, but in the "gaps" between channels. Of course, the introduction of more "White Space" devices sends shivers up most Radio Mic Technician's spine, because it potentially means that a device will suddenly appear in the middle of your spectrum... when you least expect it!
The reason White Space Devices didn't work so well in the past is due to the difference between Digital and Analogue TV transmission. Analogue is much less predictable, however Digital Channels stick out like a sore thumb to even the most basic devices. So, when you turn off the Analogue stations, you make it a lot easier to make White Space Devices.
It shouldn't be confused with the Digital Dividend, which is the space at the high end (~800MHz) of the spectrum that will be "empty" (i.e. no TV channels) once the Analogue TV stations are turned off. This spectrum will be sold off, and in the US it made a hell of a lot of money.
I will go into all of these topics in much greater detail, but for those of you that are hanging on any bit of Spectrum Information, please enjoy the link.
I know that I have been hoping to drip-feed information here, but occasionally I will need to jump the gun.
For those of you that don't know about the "White Space," it is referring to the spaces in the RF Spectrum that will be left between Television Channels, leaving clear bandwidth for devices to communicate on.
This spectrum remains unlicensed, and thus manufacturers can use this space for data transfer. Wireless Microphones operate in the same space; they are designed to work in the TV channel space, but in the "gaps" between channels. Of course, the introduction of more "White Space" devices sends shivers up most Radio Mic Technician's spine, because it potentially means that a device will suddenly appear in the middle of your spectrum... when you least expect it!
The reason White Space Devices didn't work so well in the past is due to the difference between Digital and Analogue TV transmission. Analogue is much less predictable, however Digital Channels stick out like a sore thumb to even the most basic devices. So, when you turn off the Analogue stations, you make it a lot easier to make White Space Devices.
It shouldn't be confused with the Digital Dividend, which is the space at the high end (~800MHz) of the spectrum that will be "empty" (i.e. no TV channels) once the Analogue TV stations are turned off. This spectrum will be sold off, and in the US it made a hell of a lot of money.
I will go into all of these topics in much greater detail, but for those of you that are hanging on any bit of Spectrum Information, please enjoy the link.
Thursday, September 15, 2011
The layers of the Internet - Part 2
The Internet Layer
In the last post I explained the basics of Layer 1 of the Internet Protocol; the Link Layer.
The Link Layer is where all devices are physically connected, either by wireless (e.g. Wireless LAN or 3G) or by a wired (e.g. Ethernet "Blue String" or ADSL) connection.
Whilst this is a great concept, if every device were to receive all of the data transmitted on the Internet, then we would be slowing down the process beyond belief.
Enter Layer 2 - The Internet Layer
In the last post I explained the basics of Layer 1 of the Internet Protocol; the Link Layer.
The Link Layer is where all devices are physically connected, either by wireless (e.g. Wireless LAN or 3G) or by a wired (e.g. Ethernet "Blue String" or ADSL) connection.
Whilst this is a great concept, if every device were to receive all of the data transmitted on the Internet, then we would be slowing down the process beyond belief.
Enter Layer 2 - The Internet Layer
 |
| This is Layer 2 |
On a network drawing, a network was always drawn using standardised symbols. Since everything that was on the "Internet" was connected at Layer 1, it no longer mattered how things were connected. You only had to show that there was some kind of connection.
And so the network symbol for the "Internet" became a cloud. It was some ethereal entity, floating out of the reach of Network Administrators across the globe.
Unfortunately marketing departments caught hold of this analogy, and thus Cloud Computing was born. You can see the "Cloud", and it brings you good things (like shade, and rain for your crops) but you have little to no power over it. It's there whether you like it or not.
So how does it work?
Packet-Switching Networks
In this previous blog post I explained the anatomy of a standard Internet Protocol (IP) Packet. Packets are the currency for IP networks, and indeed the entire Internet. Without repeating myself too much, they contain two main parts; a "Payload" (the data that you want to move around the network) and a "Header" (which contains the addresses relevant to the Data).
In order to understand how the Internet works, we are going to have to introduce our first specific piece of network hardware: the Switch.
The image above is that of a "Switch," and it is a common thing to be found in data centres across the world. However you are reading this blog, somewhere along the line you are connected to a Switch. It might be a little 4-port switch that came with your ADSL plan, or you might be connected to a commercial-grade switch (like the one above) at work.
Switches are the building blocks of the Internet, and they elevate matters from Layer 1 (Link Layer) to Layer 2 (Internet Layer).
Every blue or pink cable in the above image connects to a device; a telephone, a computer, a printer etc. This is the Layer 1 connection. You can tell they are working by the blinking green lights. The Orange cables connect those switches to other switches, which the connect to other switches... until they reach whatever destination they need to get to. These connections are called "Uplink Ports", as they are headed up towards the "Cloud".
When a packet is sent to a switch, it "opens" it up and reads the "Header" (not the "Payload"). In the "Header" is all of the addressing information that the Switch needs to send the packet to where it needs to go. If the destination address is connected directly to the switch, then the packet will be sent directly to that device. If not, then the switch will send the packet to the "Uplink" port, at which point the next Switch will repeat the same process until the packet arrives at its destination.
By doing this, Switches make sure that you only receive the packets that you need to read your emails, browse your websites, control your motors, or route audio. Switches don't care what your packet has in it, so long as the address in the Header is valid.
The address used by the Internet Layer is the Internet Protocol (IP) Address. I will go into (much) more details about IP Addresses in a later post as the topic is as broad as the Internet itself. Suffice to say, a common IP address is an 8-byte address, usually rendered in four groups of numbers from 0 to 255, e.g. 192.168.0.254.
Once two devices are connected at Layer 2 they are considered "Networked" and can now communicate as if they were in the same room. Layers 3 and 4 deal with how they communicate, and we will cover these in the next blog post.
Switches are the building blocks of the Internet, and they elevate matters from Layer 1 (Link Layer) to Layer 2 (Internet Layer).
Every blue or pink cable in the above image connects to a device; a telephone, a computer, a printer etc. This is the Layer 1 connection. You can tell they are working by the blinking green lights. The Orange cables connect those switches to other switches, which the connect to other switches... until they reach whatever destination they need to get to. These connections are called "Uplink Ports", as they are headed up towards the "Cloud".
When a packet is sent to a switch, it "opens" it up and reads the "Header" (not the "Payload"). In the "Header" is all of the addressing information that the Switch needs to send the packet to where it needs to go. If the destination address is connected directly to the switch, then the packet will be sent directly to that device. If not, then the switch will send the packet to the "Uplink" port, at which point the next Switch will repeat the same process until the packet arrives at its destination.
By doing this, Switches make sure that you only receive the packets that you need to read your emails, browse your websites, control your motors, or route audio. Switches don't care what your packet has in it, so long as the address in the Header is valid.
The address used by the Internet Layer is the Internet Protocol (IP) Address. I will go into (much) more details about IP Addresses in a later post as the topic is as broad as the Internet itself. Suffice to say, a common IP address is an 8-byte address, usually rendered in four groups of numbers from 0 to 255, e.g. 192.168.0.254.
Once two devices are connected at Layer 2 they are considered "Networked" and can now communicate as if they were in the same room. Layers 3 and 4 deal with how they communicate, and we will cover these in the next blog post.
Monday, September 12, 2011
The Layers of the Internet - Part 1
The Internet is a complex place. There are many articles about the history of the internet, and it's a little beyond the scope of what this blog is about, so I won't go into it too much.
Suffice to say, the only way the internet works is through rigorous adherence to global standards. These standards were developed over the 15-year genesis of the Internet from research labs to commercial use.
One of the best ways to describe how these standards, and indeed the entire internet, works is known as the "layer" method.
Layers are a great way to explain many things, and the layers that we will be looking at today not only apply to networking, but to almost every form of computing or digital signal processing.
There are four layers in the "standard" Internet topology:
Those short little descriptions probably mean very little to most of you, so let me break it down a little bit more.
The Link Layer
When I think of the best way to describe the Link Layer, this image comes to mind:
What you're looking at there is a fairly typical "Distribution" switch, and a lot of optical fibre.
The Link Layer is the only physical connection layer in the Internet Protocol. It defines all the different ways that you can connect devices together if you want them to be on the internet.
If you put your mind to it, you could easily rattle off a lot of the different standards that are in the Link Layer, for example:
Suffice to say, the only way the internet works is through rigorous adherence to global standards. These standards were developed over the 15-year genesis of the Internet from research labs to commercial use.
One of the best ways to describe how these standards, and indeed the entire internet, works is known as the "layer" method.
Layers are a great way to explain many things, and the layers that we will be looking at today not only apply to networking, but to almost every form of computing or digital signal processing.
There are four layers in the "standard" Internet topology:
- Layer 1: Link Layer. This is the physical link between devices
- Layer 2: Internet Layer. This is the "virtual" layer where the data moves around networks
- Layer 3: Transport Layer. This layer defines how data moves around devices
- Layer 4: Application Layer. This is the layer that shows how data is shared between programs.
Those short little descriptions probably mean very little to most of you, so let me break it down a little bit more.
The Link Layer
When I think of the best way to describe the Link Layer, this image comes to mind:
What you're looking at there is a fairly typical "Distribution" switch, and a lot of optical fibre.
The Link Layer is the only physical connection layer in the Internet Protocol. It defines all the different ways that you can connect devices together if you want them to be on the internet.
If you put your mind to it, you could easily rattle off a lot of the different standards that are in the Link Layer, for example:
- Wireless Networking
- Ethernet networking (a.k.a. "Blue String" - those blue cables that we are all familiar with)
- Fibre Networking
- ADSL (Asymmetric Digital Subscriber Line - The way most of us get our Home internet)
- 3G/HSDPA - The wireless Broadband that most of us use on our phones.
- DOCSIS, a.k.a "Cable Internet" - networking over Coaxial cable, similar to Cable TV (Thanks djzort)
The list goes on. The greatest thing about the "Layer" system of the Internet is that it doesn't matter how you connect devices together at the Link Layer, so long as they follow the Link Layer Standards. As soon as you have that "blinking light" that shows you are connected then you can start passing information around the Internet Layer.
The Link Layer extends across the entire Internet. Just ponder on that for a second; every device that is connected to the Internet is in some way, shape or form, connected. The Link Layer is the only layer at which every device is connected; once you start moving into the "Virtual" layers (layers 2-4) you start segregating devices into separate virtual networks (or "subnets"). But for now, let's just muse on the topic of every device acting together in synchronism.
The last thing that I will mention about the Link Layer is the address that applies to it. Obviously there is no point in connecting every device on the planet unless you knew which one you wanted to talk to. Therefore every device that connects to the internet has a unique address. This address, known as the Media Access Control (MAC) address, is a unique number assigned by the manufacturer.
The MAC Address is a 48-bit number (that is, 48 "1's" or "0's"), which makes for about 300 Trillion different addresses. Every single device that is capable of connecting to a network has a MAC address. This laptop, for example, has two addresses; one for the Wireless connection and one for the hard-wired connection. Even so, the IEEE doesn't expect that we'll run out of MAC addresses this century.
We'll look at the Internet Layer next time (probably in a couple of days). I thought it best to break things up for now.
The Link Layer extends across the entire Internet. Just ponder on that for a second; every device that is connected to the Internet is in some way, shape or form, connected. The Link Layer is the only layer at which every device is connected; once you start moving into the "Virtual" layers (layers 2-4) you start segregating devices into separate virtual networks (or "subnets"). But for now, let's just muse on the topic of every device acting together in synchronism.
The last thing that I will mention about the Link Layer is the address that applies to it. Obviously there is no point in connecting every device on the planet unless you knew which one you wanted to talk to. Therefore every device that connects to the internet has a unique address. This address, known as the Media Access Control (MAC) address, is a unique number assigned by the manufacturer.
The MAC Address is a 48-bit number (that is, 48 "1's" or "0's"), which makes for about 300 Trillion different addresses. Every single device that is capable of connecting to a network has a MAC address. This laptop, for example, has two addresses; one for the Wireless connection and one for the hard-wired connection. Even so, the IEEE doesn't expect that we'll run out of MAC addresses this century.
We'll look at the Internet Layer next time (probably in a couple of days). I thought it best to break things up for now.
Monday, August 15, 2011
Time Division Multiplexing - TDM (the root of all good)
Rise of the Packets
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:
Here we only have two devices; Red and Green. Green has address "0" and Red has address "1".
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.
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.
Tuesday, August 9, 2011
Arts Communication Session at Integrate Sydney 2011
This week I received confirmation that my seminar session has been accepted for the 2011 Integrate show.
I will be presenting with Ben Moore from ARUP Theatres and Nich Young from the Sydney Opera House.
We will be discussing the applications of networks in Theatres and Performance spaces, as well as the advantages (and disadvantages) of a converged network.
So feel free to pop on down; 1430 at the RHI Mezzanine on Day 3 (Thursday, 1st of September 2011).
We even have a spot in the official show guide.
Look forward to seeing people there
I will be presenting with Ben Moore from ARUP Theatres and Nich Young from the Sydney Opera House.
We will be discussing the applications of networks in Theatres and Performance spaces, as well as the advantages (and disadvantages) of a converged network.
So feel free to pop on down; 1430 at the RHI Mezzanine on Day 3 (Thursday, 1st of September 2011).
We even have a spot in the official show guide.
Look forward to seeing people there
Sunday, July 31, 2011
What is a Packet?
Packet-switching networks, or simply Packet networks, are the most common form of network around.
But what exactly is a "packet"?
Basically, a packet is a bit of information, formatted to move around its specific network. It usually consists of two parts; a payload and formatting/addressing information. The payload can be anything that can be digitised.
For those of us coming from the Audio side of things, we're already used to the thought of packeting information. Think about a Digital audio stream. We find out the amplitude of the analogue audio signal and convert it to 1's and 0's. But before we send it around our mixer, CD player or whatever, we also put a few extra bits of information into it; how many samples per second, if it is a stereo or a mono channel, etc.
The are common examples in Lighting as well. A DMX signal, when looked at obliquely, is a packet. It has a payload (a value) and addressing information (a DMX channel).
However, the most common packet, the one that causes the most joy and woe in the world, is the Internet Protocol (IP) packet.
Below is a pictorial description of the IP packet. Instead of trying to bore you with details, I thought this would be an easy way to show what I mean.
I can hear your brain cogs turning trying to understand what it is that you are looking at.
Let's start at the bottom. The black section that trails off toward the bottom of the page is the data that we are trying to transmit. This can be anything digital; a photo, some audio, a DMX channel change, a webpage... so long as you can turn something into 1's and 0's, you can transmit it over an IP network.
I think I should say that again; anything that can be digitised can be sent over an IP network.
That is why these networks are so powerful; any data, no matter what it is, can be sent over these networks. The amount of data contained in a packet has no real limitation. If you have a large bit of data, you can break it down into a number of packets, send it through the network, and reassemble it at the other end.
As we move from the bottom to the top, we see some things that should appear obvious; Options, Source and Destination address. Normally, a device that receives a packet will read this information and decide what it has to do with it.
I will be going into the way the internet works in future articles, but for the time being please think of a mail sorter in a post office. He looks at each letter and then sends it off to the next closest post office.
That's how addressing works; network equipment will look at the addresses and then decide what to do with it.
Next up the line is a bunch of information that doesn't really matter to us... yet. There are basic housekeeping flags, like the total length of the packet, the time that the packet should be kept around (time to live) and some checksums.
The reason that a lot of Performance Networking protocols (like Cobranet) don't work well on combined networks is because they don't have all of this "extra" information. They have the Source and Destination addresses, but they don't bother with the rest of the data.
In the "olden days" of networking , you could get away with this. Networks were kept separate, and in many cases all of the data was transmitted to every machine on the network.
However, as time has gone on and the Networking world has taken leaps and bounds ahead of the performing arts (private money helps...) they have added a lot of smarts to their technology. That is why we need those extra checksums, version and protocol type flags.
As mentioned above, the next few posts will be looking at the way packets move through the Internet, but please, if you have any questions, just email me and ask.
N.B. As mentioned in the comments below, a "Packet" is technically only the information that is shipped around at Layer 3, the "Transport Layer". This is why technologies such as CobraNet are not strictly IP-based, and also why they do not work on enterprise-type networks. However, this is a little beyond the scope of this Blog, which hopes to examine Networking in Theatres/Broadcasting, as well as the Theatre/Broadcasting aspects that are relevant to a Networking technician working in those areas. Please forgive any shortcuts that I may be taking in order to clarify a point.
But what exactly is a "packet"?
Basically, a packet is a bit of information, formatted to move around its specific network. It usually consists of two parts; a payload and formatting/addressing information. The payload can be anything that can be digitised.
For those of us coming from the Audio side of things, we're already used to the thought of packeting information. Think about a Digital audio stream. We find out the amplitude of the analogue audio signal and convert it to 1's and 0's. But before we send it around our mixer, CD player or whatever, we also put a few extra bits of information into it; how many samples per second, if it is a stereo or a mono channel, etc.
The are common examples in Lighting as well. A DMX signal, when looked at obliquely, is a packet. It has a payload (a value) and addressing information (a DMX channel).
However, the most common packet, the one that causes the most joy and woe in the world, is the Internet Protocol (IP) packet.
Below is a pictorial description of the IP packet. Instead of trying to bore you with details, I thought this would be an easy way to show what I mean.
 |
| By Nicolargo (Own work) [GFDL (www.gnu.org/copyleft/fdl.html) or CC-BY-SA-3.0-2.5-2.0-1.0 (www.creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons |
I can hear your brain cogs turning trying to understand what it is that you are looking at.
Let's start at the bottom. The black section that trails off toward the bottom of the page is the data that we are trying to transmit. This can be anything digital; a photo, some audio, a DMX channel change, a webpage... so long as you can turn something into 1's and 0's, you can transmit it over an IP network.
I think I should say that again; anything that can be digitised can be sent over an IP network.
That is why these networks are so powerful; any data, no matter what it is, can be sent over these networks. The amount of data contained in a packet has no real limitation. If you have a large bit of data, you can break it down into a number of packets, send it through the network, and reassemble it at the other end.
As we move from the bottom to the top, we see some things that should appear obvious; Options, Source and Destination address. Normally, a device that receives a packet will read this information and decide what it has to do with it.
I will be going into the way the internet works in future articles, but for the time being please think of a mail sorter in a post office. He looks at each letter and then sends it off to the next closest post office.
That's how addressing works; network equipment will look at the addresses and then decide what to do with it.
Next up the line is a bunch of information that doesn't really matter to us... yet. There are basic housekeeping flags, like the total length of the packet, the time that the packet should be kept around (time to live) and some checksums.
The reason that a lot of Performance Networking protocols (like Cobranet) don't work well on combined networks is because they don't have all of this "extra" information. They have the Source and Destination addresses, but they don't bother with the rest of the data.
In the "olden days" of networking , you could get away with this. Networks were kept separate, and in many cases all of the data was transmitted to every machine on the network.
However, as time has gone on and the Networking world has taken leaps and bounds ahead of the performing arts (private money helps...) they have added a lot of smarts to their technology. That is why we need those extra checksums, version and protocol type flags.
As mentioned above, the next few posts will be looking at the way packets move through the Internet, but please, if you have any questions, just email me and ask.
N.B. As mentioned in the comments below, a "Packet" is technically only the information that is shipped around at Layer 3, the "Transport Layer". This is why technologies such as CobraNet are not strictly IP-based, and also why they do not work on enterprise-type networks. However, this is a little beyond the scope of this Blog, which hopes to examine Networking in Theatres/Broadcasting, as well as the Theatre/Broadcasting aspects that are relevant to a Networking technician working in those areas. Please forgive any shortcuts that I may be taking in order to clarify a point.
Monday, July 25, 2011
Cisco Unveils new Wireless for Stadia etc
Just a quick one today (after my triumphant rant last week).
Cisco have just announced a new product for doing wireless networks in large areas, like stadia.
I obviously haven't covered the topic yet, however providing Wi-Fi access for an entire audience of thousands proves a lot harder than you'd expect. With the amount of access points (Wi-Fi Antennae, for want of a better word) required to support an entire audience you tend to get a lot of interference.
I haven't tried, or even seen, Cisco's solution, but as mentioned in last week's post they are one of the world leaders in networking. If they say that it can work, then I have a fair degree of confidence that it will work.
Their press release is here:
http://www.cisco.com/web/strategy/sports/connected_stadium.html
I'll be reading this over the next couple of days, and if I determine anything I will post it here.
Cisco have just announced a new product for doing wireless networks in large areas, like stadia.
I obviously haven't covered the topic yet, however providing Wi-Fi access for an entire audience of thousands proves a lot harder than you'd expect. With the amount of access points (Wi-Fi Antennae, for want of a better word) required to support an entire audience you tend to get a lot of interference.
I haven't tried, or even seen, Cisco's solution, but as mentioned in last week's post they are one of the world leaders in networking. If they say that it can work, then I have a fair degree of confidence that it will work.
Their press release is here:
http://www.cisco.com/web/strategy/sports/connected_stadium.html
I'll be reading this over the next couple of days, and if I determine anything I will post it here.
Wednesday, July 20, 2011
It can be done!
Converged Production Networks are possibile
After speaking to a lot of people in the last couple of days at SMPTE Sydney (and Entech... let's not forget about Entech....) I thought I'd write a quick post to summarise what it is that we are doing at the Opera House.
About three years ago I got talking to the in-house Information Systems (IS) team about the possibilities of a "converged" network. The IS world has been talking about Convergence for about a decade; I even operated the sound at a few of their conferences on the topic. Convergence was nothing new to them, and when I brought it up they were pretty confident that we could "do it".
By "it" I mean combine all of our IP-based services onto one network. At the moment, that includes:
- The SOH Webpage
- Ticketing/Box Office Services
- Security Cameras
- Telephones
- The Lighting Control Network
- Audio streams/distribution for the Concert Hall and Opera Theatre
- Audio and Amplifier Control for the Concert Hall, Opera Theatre and Drama Theatre
- Motor control for the Concert Hall PA
- Stage Communications
Plus all the other things that we don't think of on a daily basis.
I won't lie; it wasn't an easy path. We made a few blunders, but nothing too serious. Okay, we did crash the network, twice. But those crashes were actually caused by separating services rather than combining them.
Why did we do it?
There are a number of reasons.
Firstly, and most importantly, companies like Cisco and HP have been doing networking for decades. It's what they do best, and the reason they are on top is because their stuff works. All the time. If there is a fault then I get an email straight away. The Network admin gets an email. If we dont' fix it, then the Executive gets an email.
In terms of reliability you can't beat these professional systems.
Next up is cost. There is only a need for one network administrator, one set of spare parts, one warranty contract. We don't need to duplicate infrastructure, and that means that things get cheap, quickly.
In terms of service, I can run out a single fibre cable, and within 10 minutes I can set up a whole production office/box office/security office, all running off one of my switches. We do this all the time. A production manager will want to be near their event, but will also need to answer their phone and check their emails. They can now do all of that, and sell tickets on the side. Or they can be on a comms panel, talking to the stage crews.
Basically, there are advantages for days.
Separation and Show Criticality
Detractors will mention things like separated services and "Show Criticality".
In terms of separation, the IS world are already leaps and bounds ahead of us in the production world. They've been keeping your Credit Card number safe every time you swipe it at an EFTPOS terminal for years. They can link offices half-way across the world and make you think you're in the same building. There are so many ways to keep networks "separated" over the same infrastructure that's it's a little scary.
And critically? Cisco switches are used in military installations and banks all over the world. I know that losing a show is a dreadful thing in our world, but in terms of really needing things to work first time, every time, those kinds of industries have us beaten, hands down.
Besides, would you trust a product with a R&D team larger than most theatre companies, or a company that only has four people on staff?
We all know that the best way to get results is to get trained professionals.
You don't ask a flyman to run a lighting console, so why would you ask a Lighting guy to run your network?
Anyway, I've gone on a little longer than expected here. The moral of the story is to plan your network. If you're not a network planner, then maybe ask around for one. Heck, email me on camoneillsystems@gmail.com if you'd like. I'm more than happy to look over network designs, or even just to chat about our network.
For now, let me just say it one more time; it can be done.
Sunday, July 17, 2011
Stage Directions
Theatrical Logic
In is down, down is front
Out is up, up is back
And of course,
Left is right and Right is left
A Drop shouldn't and a
Block and fall does neither
A prop doesn't and
A cove has no water
Tripping is OK
A running crew rarely gets anywhere
A purchase line buys you nothing
A trap will not catch anything
A gridiron has nothing to do with football
A strike is work
(In fact, a lot of work)
And a Green Room, thank God, usually isn't,
Now that you're fully versed in
Theatrical Terms, Break a Leg,
But not actually.
I've seen this poem in a number of shapes and forms in a number of the theatres that I've worked in. It's one of those in-jokes that gets passed around, photocopied, transliterated and so on. It's like a chain-email from a time before the internet.
However, it does highlight one of the most difficult points about working in the theatre; there is a whole other language involved in mounting a show.
I am attempting to relieve this stress with the Glossary, but I wanted to spend a bit of time discussing theatre directions. This is especially relevant to people who may not have had any experience with the theatre.
Stage Directions
There are four main directions on stage; Upstage, Downstage, Stage Left and Stage Right.
To understand Up and Down stage you should think about a stage that is sloped towards the audience.
In days gone by this was the easiest way to ensure that the audience could see the entire stage. Many theatrical sets still incorporate this slope, or "rake" towards the audience for the same reason.
From this, "Up" and "Down" stage follow logically; Upstage is away form the audience, or the rear of the stage, and Downstage is towards the audience, or the front of the Stage.
Stage Left and Right are always given from the perspective of an actor on stage, facing the audience. This was started to get over the "Your left or my left?" confusion. Typically, the Director and other creatives sit in the Auditorium, watching the show, with the actors facing them.
If they were to call out "Move Left" then there is the obvious confusion. "Move to Stage Left" means that the actor would move to their left, or to the Director's Right.
The equivalent term for someone sitting in the auditorium is House Left/Right. House Left is in the same direction as Stage Right, and vice-versa.
The last term in the Left/Right set is Camera Left/Right. This is used in broadcast for cameramen, and is always related to what the cameraman sees. This could he House Left/Right for a camera in the auditorium, or perhaps Stage Left/Right for a cameraman on stage. I include them here because some people will often use House Left/Right and Camera Left/Right interchangeably.
In order to remove Left and Right from the Stage Directions, many directions are given in terms of Prompt Side and Opposite Prompt. Traditionally, the Prompter and/or Stage Manager would be located on Stage Left. Thus Prompt Side (PS) became synonymous with Stage Left and Opposite Prompt (OP) with Stage Right.
As these directions don't change no matter the viewing angle they have become the preferred direction.
In is down, down is front
Out is up, up is back
And of course,
Left is right and Right is left
A Drop shouldn't and a
Block and fall does neither
A prop doesn't and
A cove has no water
Tripping is OK
A running crew rarely gets anywhere
A purchase line buys you nothing
A trap will not catch anything
A gridiron has nothing to do with football
A strike is work
(In fact, a lot of work)
And a Green Room, thank God, usually isn't,
Now that you're fully versed in
Theatrical Terms, Break a Leg,
But not actually.
I've seen this poem in a number of shapes and forms in a number of the theatres that I've worked in. It's one of those in-jokes that gets passed around, photocopied, transliterated and so on. It's like a chain-email from a time before the internet.
However, it does highlight one of the most difficult points about working in the theatre; there is a whole other language involved in mounting a show.
I am attempting to relieve this stress with the Glossary, but I wanted to spend a bit of time discussing theatre directions. This is especially relevant to people who may not have had any experience with the theatre.
Stage Directions
There are four main directions on stage; Upstage, Downstage, Stage Left and Stage Right.
To understand Up and Down stage you should think about a stage that is sloped towards the audience.
In days gone by this was the easiest way to ensure that the audience could see the entire stage. Many theatrical sets still incorporate this slope, or "rake" towards the audience for the same reason.
From this, "Up" and "Down" stage follow logically; Upstage is away form the audience, or the rear of the stage, and Downstage is towards the audience, or the front of the Stage.
 |
| Image courtesy of StageHand Tees |
Stage Left and Right are always given from the perspective of an actor on stage, facing the audience. This was started to get over the "Your left or my left?" confusion. Typically, the Director and other creatives sit in the Auditorium, watching the show, with the actors facing them.
If they were to call out "Move Left" then there is the obvious confusion. "Move to Stage Left" means that the actor would move to their left, or to the Director's Right.
The equivalent term for someone sitting in the auditorium is House Left/Right. House Left is in the same direction as Stage Right, and vice-versa.
The last term in the Left/Right set is Camera Left/Right. This is used in broadcast for cameramen, and is always related to what the cameraman sees. This could he House Left/Right for a camera in the auditorium, or perhaps Stage Left/Right for a cameraman on stage. I include them here because some people will often use House Left/Right and Camera Left/Right interchangeably.
In order to remove Left and Right from the Stage Directions, many directions are given in terms of Prompt Side and Opposite Prompt. Traditionally, the Prompter and/or Stage Manager would be located on Stage Left. Thus Prompt Side (PS) became synonymous with Stage Left and Opposite Prompt (OP) with Stage Right.
As these directions don't change no matter the viewing angle they have become the preferred direction.
Sunday, July 10, 2011
Glossary Up and Running
I have now published the first version of this blog's Glossary.
This will be a useful tool for explaining the various terms that I will be using.
I intend to be updating it constantly, but for the understandability of this blog I have posted most of the basic terms I will be using.
If you would like any specific term added to the list, please just leave a comment on the glossary.
Thanks
This will be a useful tool for explaining the various terms that I will be using.
I intend to be updating it constantly, but for the understandability of this blog I have posted most of the basic terms I will be using.
If you would like any specific term added to the list, please just leave a comment on the glossary.
Thanks
Friday, July 8, 2011
What is communication?
Communication is the transfer of information between two or more parties. It can take many forms.
It can range from something as simple as a Stop sign to networks as complex and infinite as the Internet.
Communication is the basis of society. Without the transfer of knowledge or ideas there is no framework for the interpersonal relationships that make up our, or any, species.
Take a TV drama for example.
This is a highly polished form of communication. The writer, director, actor, cameraman, vision mixer, audio mixer... all of these people communicate their own version of the story to the viewer.
Or take our Stop sign; it is a message from the city planners that the intersection you are approaching is dangerous, and you should stop and survey the road before proceeding.
Communication can be as hard or as simple as you would like it to be. Therefore, in order to pull focus on this blog, I would like to define which forms of communication I will be dealing with.
The purpose of this blog is to inform and encourage theatre and broadcast professionals (my definition of the Performing Arts) about the methods of communication that directly affect them.
This includes, but isn't limited to:
The reason I'm doing this is to help both sides of the equation learn more about the other. Traditionally, performing arts technicians have had little to do with communications beyond a 2-channel "beltpack". Network administrators, on the other hand, had very little to do with the arts, and in many instances were banned from entering stage or studio areas except during planned maintenance.
However this has changed in the last few years. Many convergent technologies (I will define Convergence in a follow-up post) are meaning that networks are extending well into the realm of the arts to the point of running critical systems.
I hope that through my posts and the discussion created by them I can help spread the good word, as well as allay fears from both sides of the communication fence. Please feel free to comment at any time so that we can start a discussion.
It can range from something as simple as a Stop sign to networks as complex and infinite as the Internet.
Communication is the basis of society. Without the transfer of knowledge or ideas there is no framework for the interpersonal relationships that make up our, or any, species.
Take a TV drama for example.
This is a highly polished form of communication. The writer, director, actor, cameraman, vision mixer, audio mixer... all of these people communicate their own version of the story to the viewer.
Or take our Stop sign; it is a message from the city planners that the intersection you are approaching is dangerous, and you should stop and survey the road before proceeding.
Communication can be as hard or as simple as you would like it to be. Therefore, in order to pull focus on this blog, I would like to define which forms of communication I will be dealing with.
The purpose of this blog is to inform and encourage theatre and broadcast professionals (my definition of the Performing Arts) about the methods of communication that directly affect them.
This includes, but isn't limited to:
- Telephones
- Production Communication Systems (e.g. Clearcom, RTS, Riedel)
- FM Radio Transmission (including 2-way radio)
- Time Division Multiplexing (TDM)
- Packet-based networking
The reason I'm doing this is to help both sides of the equation learn more about the other. Traditionally, performing arts technicians have had little to do with communications beyond a 2-channel "beltpack". Network administrators, on the other hand, had very little to do with the arts, and in many instances were banned from entering stage or studio areas except during planned maintenance.
However this has changed in the last few years. Many convergent technologies (I will define Convergence in a follow-up post) are meaning that networks are extending well into the realm of the arts to the point of running critical systems.
I hope that through my posts and the discussion created by them I can help spread the good word, as well as allay fears from both sides of the communication fence. Please feel free to comment at any time so that we can start a discussion.
Subscribe to:
Posts (Atom)