www.gcn.com/print/27_8/46117-1.html

Interesting quotes --

“We have achieved the promises of Moore’s Law,”

“Much more pervasive now is the problem with software.”

“Software is getting bigger and more complex,"

"The Windows Vista operating system is so much bigger than its
predecessors, that it is not any faster even though processing speeds
have increased.”

= = = ==================================

DOD wants apps up to speed

Despite hardware advances, complex code and heavy traffic put a drag
on systems Bloated operating systems and applications are preventing
military organizations from getting sufficient speed from their
information technology systems, according to several speakers at a
recent Navy IT Day in Washington.

“We have achieved the promises of Moore’s Law,” the decades-old axiom
that processing power would roughly double every 18 to 24 months, said
Chris Miller, the Navy’s domain lead for command, control,
communications, computers and intelligence (C4I).

“Much more pervasive now is the problem with software.”

“Software is getting bigger and more complex,” Miller said. “The
Windows Vista operating system is so much bigger than its
predecessors, [but] it is not any faster, even though processing
speeds have increased.”

Elizabeth Sedlacek, director of information systems and infrastructure
at the Marine Corps Systems Command, echoed Miller’s complaint.
“Windows 95 required 50M of hard drive space,” she said. “Vista
requires 15G.”

Part of the problem is that Moore’s Law isn’t the only one in the IT
universe.

Sedlacek said increased resource requirements from the multiplication
of software code illustrate an adaptation of Parkinson’s Law: software
will expand to fill the resources available to it. The original
Parkinson’s Law states that work would expand to fill the time
available. A corollary to Parkinson’s Law states that software
eventually reaches a coefficient of inefficiency, meaning that it gets
so large that it no longer processes data effectively.

Sedlacek summarized her conundrum by citing yet another law. “Wirth’s
Law states that software gets faster slower than hardware gets
faster,” she said. According to Wirth’s law, then, software will
always lag behind processing capacity.

But it wasn’t always so. “In the 1970s and 1980s, hardware processing
power was wanting, and programmers had to code effectively and
efficiently in order to get done what we needed to get done,” Sedlacek
said. “Now that capacity has increased and the software industry is
much larger, developers want to put lots of features on software and
to do it quickly in order to gain a competitive advantage. Efficiency
of coding is no longer a priority.”

A problem the Marines face, for example, is that they rarely operate
in a resource-rich environment.

Marines are on expedition-like missions when they deploy, Sedlacek
said, and they typically operate with a minimal footprint in areas of
limited bandwidth. They rely on small handheld devices for information
and communications.

She challenged industry to help solve the problem.

Aside from software coding, agencies could address the problem through
more efficient data management.

Miller suggested that the Navy needs a data strategy for how it
expands applications. Richard Hull, chief scientist at Modus Operandi,
agreed in an interview with GCN that getting smarter about collecting
and processing data will help software work more efficiently.

“Software gets slower because the data operating over a network is
increasing faster than computer processing rates,” Hull said.

Some satellites generate several gigabytes of data per second, Hull
said. “The next generation may be terabytes of information per
second,” he said. “If a computer has to deal with 100 times or 1,000
times the amount of data today than it did yesterday, it’s going to be
swamped.”

Hull suggested two strategies to cope with the glut of data. One
involves prioritizing so that only the data most relevant to the
mission is actually processed.

“A weather information system may have collected temperature once per
hour, yielding 24 readings per day,” he said. “Then a new technology
comes along allowing you to collect a new temperature reading every
second. That’s 600 times more information than you had before.

But that doesn’t mean you need to analyze it all in depth. You’re
really just interested in changes or anomalies.”

Using semantic architectures to analyze and filter data sets up
hierarchies of data and processing that can help ensure that only the
most interesting data climbs the ladder for in-depth analysis. “You
might have a network of 64 computers filtering the data and passing up
relevant data to a level consisting of 16 computers and then to eight
computers,” Hull said. “This can filter out a lot of junk and provides
a higher degree of fidelity in information collecting and analysis.”

Another possible solution is to use cloud computing schemes, he said.
Cloud computing refers to the ability to construct ad hoc networks of
computers that can share resources to tackle tough computing
challenges.

An organization might have 10,000 computers at its disposal. Cloud
computing provides a management structure by which, for example, 1,000
of those machines might be aggregated to solve a particular problem.

“It could take a year to build a network of

1,000 computers,” Hull said, “but the cloud computing architecture
allows this to be done quickly.”

Another potential solution comes in the form of muticore processing,
essentially assigning pieces of the puzzle to different processors
running simultaneously on a single device. There are limitations to
this approach, as there are with cloud computing, because most
applications are single-threaded, Sedlacek said. Muticore central
processing units do not increase computing power when the applications
can’t be divvied up into discrete tasks.

The premise of multicore computing is that the computing capacity of
microchips is leveling off and that the computing power inherent in
existing machines must be maximized and optimized. Making that happen
requires programmers to accomplish two things, said Joey Sevin, Navy
programs manager at Mercury Federal Systems. They must develop a
greater understanding of computer hardware, and they must do something
about how they write software.

“It requires people to think differently about applications and how to
write them,” Sevin said.

“Programmers are encouraged to throw off code quickly, but in the end
this is very inefficient when the application is single-threaded.”

Sevin said the solution is to use middleware that can coordinate
messaging among multiple processors. “What needs to happen is the
adoption of a standard” for a message passing interface, he said.

MPIs would allow existing computers to distribute tasks across their
existing processors and boost their processing power. The effect of
distributing computing assignments across multiple processors also has
the effect of making the software less complex, Sevin said.

Mercury is working on developing multiprocessor solutions for
processing sensor data.

Because data collection platforms are getting smaller and more
complex, Mercury wants to pool processing power to support multiple
missions.

“The idea is to create an environment adaptive to different
situations,” Sevin said. An unmanned aerial vehicle “may go out on a
mission.

When it finishes its job and transmits its data, the computing asset
may be reallocated to some other mission in another location and with
a different type of sensor.”

This type of system is designed to handle two problems inherent in the
collection and transmission of sensor data: latency and throughput.

Latency refers to the need for computing to function in real time.
Throughput problems arise when the volume of data overwhelms
processors and causes delays.

What sort of solution would the Marine Corps be most interested in?
Sedlacek leaned toward simpler and leaner software. She urged industry
to adopt open, modular and scalable software designs and to avoid
“featuritis.” She also suggested that the Marine Corps might develop
incentives for lean software design, and she urged software developers
to adopt the YAGNI principle: You Ain’t Gonna Need It, so don’t code
it.

= = = ==================================

www.gcn.com/print/27_8/46117-1.html