Command Line or GUI?

Posted on July 2, 2011 by SJE

My first computer course was in high school. It was Fortran IV, and we utilized a mainframe on the other side of town. Programs were handwritten on paper that provided multiple rows of single-character blocks. Someone else turned them into punchcards that ran through the system. A few days later, we received printouts on greenbar paper. For us, there was direct interaction with the system. I had some direct interaction with a DEC PDP-8 in college. Among other things, it included bootstrapping the system which consisted of setting a binary address with one group of switches and setting a value with another. Placing the correct value in two addresses rebooted the machine.

It was 2 or 3 years later when I accessed another computer, and it was a Timex/Sinclair 1000 that I built from a $99 kit. It had a whopping 2K of RAM. That was followed by a Commodore 64 and ultimately a PC (286). Shortly after getting the PC, I loaded Windows 3.1. Once I got to Windows, it seemed nearly all my interaction with computers was with the GUI. The command line interface (CLI) was only used for troubleshooting. Then a colleague introduced me to Linux. Since then, I have found the CLI far more useful. I remember talking about Linux with the local SBE Certification Chair when I was taking my CBTE exam. He wasn’t too excited about it, referring to it as the OS du jour. That was 10 years ago.

Since then, I have used *nix almost daily. While I have tried several of the Xwindows interfaces, I have found the *nix command line interface far more useful. Now that Linux is commonly found as the embedded operating system in a variety of equipment, practical knowledge of Linux is job security. If you have not tried it, I heartily recommend it. If you have an old computer lying around there are plenty of versions available for free or low cost. Many offer ‘Live CDs’ that allow you to boot an existing computer into Linux running from the CD without overwriting your hard drive. This is an easy way to take several versions for test drives. I have also installed Cygwin in every non-*nix machine I use. The Cygwin interface provides a command line *nix interface on Windows machines that truly provides the best of both worlds.

The CLI really shines when I need to do scripting. I find a lot of operations are repetitive and can be scripted. Operations such as specific file backups, log rotation and creation of files for metrics all lend themselves to scripting. For BroadcastBuyerGuide.com, I have several housekeeping scripts that run daily. One cleans out unneeded info from the database. Another does a full backup of the database, while a third copies the database to a development machine. A fourth script (on the dev. machine) rotates and deletes the databases so I always have 5 or more recent database backups but do not fill the hard drive with copies of old databases. In this manner, I have a disaster recovery plan that is simple, automatic and fairly foolproof.

The CLI also provides a way to look around the ‘insides’ of many of today’s devices. It also helps to have a root level password. However, root-level access gives you complete control of the system. Having that control means using it responsibly. Don’t change files without making a backup. Use delete with extreme caution – I prefer renaming files and deleting them days or weeks later when I know they won’t cause problems. Keep good notes. Keep changes to a minimum until you develop an understanding of potential effects.

On the GUI side, many of today’s systems just would not be the same without one. No, I wouldn’t want to go back to a CLI-only interface. Whether it is graphics functions, games, or even web browsing, a GUI, or touch-screen is the only way to go. But just like those that still prefer driving a stick over an automatic transmission, each interface offers advantages. Both will be with us for a long time, and those that are proficient in both have the advantage.

Posted in Basics, Control, General | Tagged , , , , | Leave a comment

It’s down; do you know where the logs are?

Posted on June 28, 2011 by SJE

In the past, when something went down, there were indicator lights, telltale sounds and, unfortunately, smells that often led you towards the problem. If that did not do it, a VOM or O-scope could go a long way fast. When was the last time you used an oscilloscope on a piece of gear? Much of today’s equipment is based on an operating system, and when it goes down, it is often a result of a failure that involves a logical element rather than a physical element. Short of decoding logical states on AND and OR gates (when was the last time you did that?), oscilloscopes and VOMs are of little help. Decoding these ‘logical’ errors is often done best by looking at the logs.

Depending on the OS, various logs can be found in a variety of locations. In Windows, the Event Viewer is a good place to start, often the Application section can be quite revealing. Depending on the applications running (IIS or SQL), you may find their logs in other locations. IIS logs may be found in C:\Windows\System32\LogFiles\W3SVC1. Linux often makes use of the /var/log folder for a variety of application logs. I have also seen them located deep inside the user’s home directory inside a log folder. Any easy way to search for them is to use the following:
“find / -name *log*“

Realize that to use the above command effectively, you may need to be logged in as root, or as a user with additional permissions. Other devices allow you to monitor the logs in realtime by telnetting into the device on a variety of non-standard ports.

Regardless of how you get there, it is a good idea to get familiar with the logs. Know how to get to them and know what they normally contain when things are working well. Get a copy of a ‘good’ log when things are working well so you have something to compare it to. One of my coworkers is very good at grabbing screen shots and saving long strings of command line queries after working on a device. Those files have saved us more than once.

Posted in Basics | Tagged , | Leave a comment

IPv6 – A Looming Internet Revolution

Posted on May 31, 2011 by Glenn_Davies

Since 1981, IPv4 has been the predominant Internet Protocol (IP) architecture and it is currently the foundation for most internet communications. However, the exponential growth of the internet has created the need for many more IP addresses than IPv4 is capable of providing.  As a result, IPv6 infrastructure is about to become a very hot topic as it solves the internet address shortage and delivers other benefits to broadcasters.

Internet address allocation is managed by the Internet Assigned Numbers Authority (IANA) and earlier this year they allocated the last remaining IPv4 addresses to Regional Internet Registration (RIRs) authorities around the world. These RIRs allocate addresses to Internet Service Providers (ISPs), who in turn allocate them to their customers.

IPv4 Address Exhaustion and IPv6 Integration
The first RIRs have already started to run out of IPv4 addresses and once they are totally exhausted, this finite resource will officially become a commodity which current owners will need to maintain and manage as IPv6 infrastructure becomes more prevalent.

IPv6 will deliver many billions of new addresses and even though IPv4 will essentially be legacy technology, it will not be going away anytime soon. While this is good news for all IPv4 compatible devices, the bad news is that the IPv4 and IPv6 internet infrastructures will not just seamlessly work together.

Although they both use the same physical network, they are for all intents and purposes different internets and an IPv4 only device will not talk to an IPv6 only device. As for the question of how long support for IPv4 will remain, this is completely unknown and depends entirely upon how long it is commercially viable for suppliers and users to maintain both infrastructures.

During the transition period it will be necessary for IP codecs and other IP devices to connect over both IPv4 and IPv6 infrastructure, or they will not be able to connect seamlessly across the entire internet. This can be achieved with ‘Dual Stack’ IPv4/v6 compatibility, whereby a device is able to connect to and use both IPv4 and IPv6 networks at the same time.

The Benefits of IPv6 for Broadcasters
IPv6 delivers simpler networking, enhanced security and almost unlimited numbers of IP addresses. These advantages will eventually revolutionize broadcasting over the internet using IP.

From a networking perspective, the design of IPv6 infrastructure potentially allows all IP addresses to be public. How visible each node is to the internet is at a network administrator’s discretion. This provides the ability to create end-to-end IP connections without the need for network address translation (NAT). Whereas with IPv4, NAT is required to connect devices with private IP addresses on private local area networks (LANs) to other devices on public networks like the internet.

IPv6 has inbuilt mobility provisions which will facilitate the expansion and support of ‘roaming’ IP devices like audio codecs. This means it won’t matter where in the world a device goes, it can be contacted using the same global IP address.
IPv6 will therefore make it extremely easy to establish codec connections and removes the need for NAT routing workarounds, which have often taken up significant IT administrator support time and costs within organizations.

IPv6 also has Quality of Service (QoS) support built into it. Whereas IPv4 generally delivers ‘best effort’ IP packet delivery across networks, IPv6 has a traffic-class field within packet headers allowing users to prioritize data packets based on their importance. This has obvious benefits for broadcasters who rely on uninterrupted data flows to maintain continuity of audio and video.

Multicasting in IPv6 is performed differently compared to IPv4. In IPv4 specific multicast routers are required to send multicast IP packets over IP networks. In IPv6 the addressing scheme inherently caters for multicast packet routing at different levels – from local multicast links through to global. This is facilitated by embedding rendezvous point addresses in an IPv6 multicast group address, which simplifies the deployment of inter-domain solutions. As a result, multicasting will become increasingly useful as a scalable, localized method of disseminating audio streams without the bandwidth restrictions of multiple -unicast transmissions.

From a security perspective, unique IPv6 addresses allow more finely tuned IP security without NAT traversal issues, as well as end-to-end authentication and identification of IP devices. Currently security features like firewalls are generally managed at the network level and we may see a greater focus on security at the node, or individual device level, as end-to-end IPv6 connections become more prevalent.

Summary
With IPv4 addresses nearing exhaustion and the world moving inexorably towards IPv6 becoming the dominant internet infrastructure, IP audio codecs and other devices must adapt to operate in both IPv4 and IPv6 worlds. Over time IP audio codecs in particular will require connectivity to a wide array of IPv6 endpoints. These endpoints will include local, national and international media contributors and syndicated stations.

Perhaps the biggest driver in the expansion of IPv6 infrastructure will be the proliferation of new wireless devices over the next few years and their use of IPv6 addresses. This will ensure IPv6 infrastructure spreads rapidly to support burgeoning numbers of new devices. Broadcasters will need to keep pace with these changes to support interconnections to both IPv4 and IPv6 hardware. Tieline Bridge-IT and the upcoming Genie STL and distribution codecs are the first to support both architectures.

 

Posted in Basics | Tagged , , , | Leave a comment

Unicast vs. Multicast

Posted on May 24, 2011 by SJE
screen shot from a WireShark capture

Here is a screen shot from a WireShark capture. The different colors relate to different types of packets.

In the IP world, there are two main ways of communicating: Unicast and Multicast. Unicast is essentially what travels on typical business and personal LANs. Unicast is two-way communication between two (and only two) devices. Multicast is one-way communication initiated by one device and ‘received’ by 0 or more devices. Many multicast-emitting devices will output multicast even if there are no listeners. Be aware, that to listen to multicast, a device must request a ‘join.’ More on that later.

Back to unicast. Unicast is communication between two devices, often a client and a server. The client issues a request for somethng (say a web page) and a server fills the request. Both the request and its fulfillment are transmitted as a series of packets. Like any conversation, the number and size of the packets varies with ‘topic’ being discussed. Pings can be very fast bursts of small packets whereas file transfers may be ongoing transfers of very large packets. With unicast, information is confirmed by the
receiver. If any packets are missing, or corrupt, replacement packets will be requested and placed in the proper sequence.

If you have never looked at the communications that takes place in the background of a network, I encourage you to do so. The amount of information transferred, even when the devices are at rest, is staggering. An easy way to monitor this is with a piece of software such as Ethereal or WireShark. WireShark is open source and available as a free download here.

WireShark will let you look at all packets entering and leaving the PC it is running on. Some of the trick here is monitoring conversations that your PC is not part of, for instance you might need to troubleshoot the connection between an encoder and a digital microwave. If you have a switch inline between the devices, it may be possible to mirror a port. This is needed because switches operate in a manner that allows them to track which MAC addresses are connected to which ports. If the conversation is taking place between ports 2 and 5, you will not be able to see it if you are plugged into port 3. Potentially, you can mirror port 2 or 5 to port 3 and monitor the packet traffic. Short of that, you can insert a hub in the line. Hubs, unlike switches place all traffic on all ports. This allows you to monitor all traffic going through the hub from any connected port. Watching traffic move along a network is invaluable when troubleshooting connection issues, especially as you move into routers and firewalls.

Now, let’s look at multicast. Multicast moves between the originator, and any device that has requested it. It also has been compared to a flood. Multicast, when unintentionally let loose on a network, can take down a network as it goes everywhere once it hits a switch. Think of it like RF, if you do not contain it, it will get into everything. Like RF, you need to treat multicast on your network with respect, as it will create all sorts of headaches if you are not careful, So, why use it? Multicast has some real advantages when used properly. Namely, it allows one server to supply media to an almost unlimited number of clients. This is done through replication in the network. In a properly configured network, multicast will flow to the ends by request. To keep response times short, the multicast is often ‘parked’ near the consumer so that the request to join does not have to go to far back into the network to find it. It is possible that the request could traverse the network all the way back to the source. As long as each device along the way was capable of passing the network, the multicast would flow all the way back to the requestor.

Because multicast is one-way communication, there is no real opportunity for dropped or mangled packets to be replaced. This can result in errors at the receiver that are uncorrectable. If the content of the multicast stream is audio or video, this can mean disruptions in the signal. In my experience, a single dropped packet is audible or visible. Like a dropout during tape playback, a trained eye will spot it, but the average viewer will not. However, multiple dropouts, say one every few seconds will become extremely noticeable and annoying quickly. When that happens, viewers are likely to find something else to watch, somthing that is never good.

Posted in Audio, Basics, Video | Leave a comment

Fiber

Posted on May 14, 2011 by SJE

Most broadcast engineers are familiar with the physical characteristics and limitations of copper cabling. Fiber is a different matter. Fiber is available in two basic types; single-mode (SM) and multimode (MM). Single-mode fiber utilizes a smaller core than multimode and will carry a particular wavelength further. Electronics associated with single-mode fiber are usually costlier than those for multimode fiber. Multimode fiber will carry a wider range of wavelengths than single-mode, but over a shorter distance. While not 100% universal, yellow jackets are commonly used with single mode fiber, and multimode uses an orange jacket.

Management of fibers is critical. Today’s fibers are more robust than those made years ago, but they are still based on glass and can be broken. Additionally, unless you have decided to make your own, breaking a fiber means running a new one. Due to the allowable lengths, running a new fiber through your facility may be quite challenging.

Cleanliness is extremely important when working with fibers. Due to the small sizes involved, it only takes a speck of dust in the light path to impact the light received at the destination. It is always a good idea to clean connectors before inserting them into equipment. The last thing you need is to introduce dirt into the equipment side of a fiber connection. The equipment side is very difficult to clean whereas the fiber end of the connection is generally easy to clean with alcohol and a lint-free cloth.

Posted in Basics | Leave a comment

Delving into the Layers

Posted on April 25, 2011 by SJE

If we are going to discuss IP in a broadcast environment, we have to at least mention the Open Systems Interconnection (OSI) 7 layer model. Remember, this is only a model. The seven layers are:

  • Application (layer 7)
  • Presentation (layer 6)
  • Session (layer 5)
  • Transport (layer 4)
  • Network (layer 3)
  • Data Link (layer 2)
  • Physical (layer 1)

While all the layers are important, the Physical, Data Link and Network layers are the most relevant in the broadcast infrastructure environment. The other layers come into play for those writing software applications. Most tutorials start at the Application Layer, however, we will start at the physical layer, as it literally is the easiest to get your hands (and head) around.

There are 2 primary physical interconnects: copper and fiber. I typically see copper interconnects for 100M and 1G (short runs) and fiber interconnects for 1G and 10G. Yes, we run a lot of 10G interconnects. Regardless of your experience and budget, every facility needs to consider whether it is cost effective to purchase the tools and build their own cables/fibers, or to simply purchase all cabling/fibers in standard lengths.

Cable management takes on added importance if you choose standard lengths. Invariably, standard interconnect cables are always just a bit too short to lace in properly. You might be able to get a particular cable in 3 and 6 foot lengths, but what you need is 4 foot. You are faced with either shortcutting the run, or managing the extra 2 feet of cable.

Whether you buy or build your cables, consider handheld test equipment that allows you to ring out a network cable or fiber to at least 1G. Without that, you may waste considerable time troubleshooting bad cables. You wouldn’t run a video facility without a waveform monitor and vectorscope, don’t try to run an IP network without some form of analysis device capable of determining whether or not a cable or fiber is physically capable of the needed bandwidth. You can find a variety of Test Equipment manufacturers here.

Posted in Basics | Tagged , , , | Leave a comment

Welcome to BBG’s New Feature

Posted on April 15, 2011 by SJE

It has become apparent that many broadcast engineers are having a hard time with IP-based systems. This is nothing new. Many engineers found the transition from tubes to transistors difficult, others had difficulty transitioning from transistors to ICs. The same can be said of every new technology wave.

At NAB 2011, I talked to many vendors and they agreed that help was needed in this area. I go through NAB with a press pass rather than an attendee badge, and see a slightly different show than most attendess. The Saturday and Sunday before NAB are full of press conferences. Year after year, the scene and faces are similar. This year I found myself thinking about Larry Bloomfield and his “Taste of NAB” road show. Larry passed away in November and it was obvious to me that he filled a unique niche and was appreciated by many. I can’t go on the road, but would like to fill some of that void. My goal is to help educate broadcast engineers on the value of IP-based systems, not only for control but also for audio and video (media) delivery and transport.

Why me? Why not? While I have not spent time on the coasts or at the big networks, I bring a unique perspective to the subject. Consider this:

  • I started in radio at KSIW in Woodward Oklahoma in 1978. My first television job was at KTVH (now KWCH) in Wichita in 1981.
  • Ampex 2″, 1″ and Sony U-matics were all part of my early training. Component level repair on RCA TK-47s, GVG switchers and countless B&W monitors were day-to-day activities, as was running tape and master control.
  • I have been an operator as well as Chief Engineer and Assistant Chief at both independent and network affiliated stations. 
  • SBE certified (CPBE). Also held one of the first CBNTs, but was so disappointed with the out of date requirements that I did not renew my CBNT. Member of SBE since about 1993.
  • Technical Editor of both Broadcast Engineering and Video Systems magazines for seven years. I also did several of their Buyers Guides around 1999 and 2000.
  • Technical Editor of numerous Sam’s publications centered around Linux.
  • Editor/Owner of BroadcastBuyersGuide.com for the last seven years. Started the site from scratch, wrote all the code and structured the databases. Today, BroadcastBuyersGuide.com receives upwards of 35,000 page views from more than 5,000 unique visitors each month. We also have a monthly newsletter that goes to more than 10,000 unique addresses.
  • Senior IPTV Services Engineer at CenturyLink for the last four years. I am one member of a team of  7 engineers that has taken the CenturyLink Prism product from a single market (Columbia, MO) with only a handful of friendly customers, to a product that covers 8 markets and upwards of 33,000 customers. CenturyLink’s Prism product offers IP delivery of hundreds of SD and HD channels using unicast and multicast packets over xDSL circuits. It is based on Microsoft’s Mediaroom platform and is comparable to the AT&T Uverse product. While we have RF-based systems, Prism uses only networking technology.
  • Finally, this is real world experience. I don’t hide behind a mask, nor do I spend all day at a desk. I work on this daily and want to extend that knowledge to those that are interested.

Needless to say, I understand IP from several perspectives. I want to help you move your facility towards the future. Don’t get me wrong, I am not advocating replacing current systems wholesale.  Analog audio and video as well as digital systems have their place. Networks using IP are not simple, and few things are as simple as a microphone, amplifier and speaker. The right technology needs to be used in each scenario. The best way to do that is to understand the pros and cons of each so you can take the best advantage of the available technologies.

I welcome (and encourage) your input. Without it, it is difficult to ensure this is going in the right direction. Thank you.

Posted in General | Tagged , , , , | Leave a comment