Opinion Piece: On Real-Time Processing in Networks

Written by: Steven J Searle, TRONWeb

About 20 years ago at the start of the TRON Project, an American computer science professor at a famous university in the U.S. stated on a USNET forum that he went out of his way to make sure that he knew nothing about the project, and, moreover, that he didn’t like the TRON Project’s understanding of the concept of “real time.” (Yeah, I know, it’s a little flaky to say you go out of your way to know nothing about TRON and then claim you know what the TRON Project’s concept of real time is, but computer scientists are paid to deal in computer logic, not necessarily logic that humans can understand.) Anyway, here we are today in the middle of the age of the global Internet, an age based on American developed network technology, and the TRON goal of real-time networks, i.e., networks in which real-time performance can be guaranteed, is further away than ever.

Some of the reasons for this were never foreseen by the TRON Project. It’s no secret that the Internet is slowed down by billions of unsolicited e-mail messages (kept going by fools who make purchases from the junk e-mailers), gargantuan amounts of pornography, and massive blocks of audio and visual data moving to and fro. The only solution to date has been to increase bandwidth, but that has its limits. The author, for example, has a broadband Internet connection that theoretically provides 10 Mbps upload and 30 Mbps download service, but when he downloads the BBC computer news television program “Click,” he has difficulty maintaining a 100 Kbps stream between himself and the BBC server. For those of you too young to remember, that’s only 50 percent faster than an ISDN circuit, which was laughed off as being passé even before it came into widespread existence. On top of that, the picture quality is horrible, being worse than early television standards.

The reason for this mess, of course, is that there has never been top down design in networks. Sun Microsystems Inc. used to correctly point out that the “network is the computer,” but who ever designed a network the way a microprocessor is developed, for example? In reality, computer networks have been developed in the same helter skelter fashion the Los Angeles freeway system was developed; and just as making Los Angeles freeways wider did nothing more than make room for more cars, making the Internet’s pipes wider is just going to allow larger amounts of the same data to be accommodated. (The pornography producers, for example, are said to be preparing high-definition videos, which have forced their actresses to go in for cosmetic surgery tuneups due to the higher resolution making their imperfections visible!) Accordingly, even if we could give everyone in the world a connection with 100 Mbps download service, someone would just figure out ways to jam it up with new types of high-volume data.

What is required to realize real-time networks is actually quite simple – network capacity utilization that does not exceed the maximum bandwidth of the network in question. That is to say, the network would normally operate at no more than about 75 percent of its capacity, so that it could accommodate surges that moved utilization up near 95 percent of capacity. This, of course, would require the number of users/embedded devices in the network to be strictly limited, bandwidth utilization to be monitored and utilization patterns recorded, and even frequently downloaded high-volume audiovisual (AV) content to be prepared in advance for nodes that regularly request it. There would also have to be priorities set in advance, just as in a real-time embedded system, as to what what nodes and which applications would have priority when network capacity utilization started to reach or exceed maximum capacity. I can already hear you saying it to yourself – the network administrator in this case would be like a systems designer doing top down design. Correct.

Although it was never implemented, the TRON Project originally proposed a separate operating system for managing networks called Macro TRON (MTRON). MTRON would have handled the functions listed above, plus lots of others. I hope that one day this will finally be developed on top of T-Engine, where it could also take advantage of eTRON security. For large-scale local area networks, such as a large office building or industrial site, it would probably be best to make it a fault tolerant system based on multiple processors with data duplication. Such a system also could be easily developed on top of T-Engine using SMP-compatible T-Kernel, which is currently under development. The most important thing is to never forget for a moment that networks are only useful to the extent that they deliver and process data on time, in real time, since networks themselves are computer systems of distributed computer systems. This is particularly the case where factory automation is installed, but it also applies to the timely delivery of AV data, stock buy/sell orders, etc.

As for the Internet at large, I have already mentioned before in a previous opinion piece elsewhere on the Web that one information superhighway is not enough. However, it doesn’t look like we can expect anything parallel to the current Internet in the near future. In the meantime, I would like to propose that a set of guidelines be drawn up for making Web pages real-time processing compliant. Such Web pages would be bare bones and leave off all the Java and Flash animation and sound, or at least offer a real-time compliant version of themselves as an option. Only by de-enhancing the viewing experience will be able to speed up processing and allow Web page viewers to get at the really important information, which is usually alphanumeric in nature. That’s right, take away the alphanumeric data on most Web pages, and all you’re left with is a bunch of annoying AV effects. Sadly, Web site designers don’t even follow guidelines to allow access by the disabled, so it is highly unlike that they would follow guidelines to enable wide area network processing in real time.

If anyone believes the author underestimates the importance of AV content on the current Internet, please think again. There are many excellent Web sites whose audiovisual presentations are extremely important is presenting historical and current affairs information that punch holes in official government stories based on omission of facts, half-truths, and even outright falsehoods. All he is proposing is that these presentations get to where they are requested on time, in real time. Perhaps the best way to insure this would be a temporarily established, point-to-point connection between the source server and the target server. In TRON terms, this would require the MTRON operating system on one LAN’s server to contact the MTRON operating system on another’s LAN’s server to secure an alternative high-capacity connection (e.g., a satellite channel), and then transfer the high-volume data, for which the end user would be charged a premium. If the end user didn’t wish to pay the premium, then he/she could wait for the existing Internet to transfer the data in a manner that is not real-time based.

There are a lot of possibilities. I remember Prof. Ken Sakamura, the TRON Project Leader, saying on more than one occasion that there are probably network applications we don’t know about at present but will discover as we build a highly networked society. This is something I hope the T-Engine development community will keep in mind as they develop their applications. By all means, put the requirements of your customers first, but always keep in the back of your mind that there are possibilities and functionalities that have yet to be discovered when it comes to the creation of ubiquitous computing networks. The Bill Gates and Steve Jobs of the embedded systems world have yet to emerge, so let’s hope they emerge from the T-Engine development community.

Steven J. Searle is the Web master of TRON Web, which is one of the largest collections of English-language information on the TRON and T-Engine projects on the World Wide Web. He wrote the above opinion piece in a private capacity, and his opinions do not necessarily reflect those of the TRON Association, the T-Engine Forum, or any members of those organizations.