Feeds:
Posts
Comments

Archive for July, 2008

This morning I attended a two-hour presentation by Ankita Garg of IBM, Bangalore. The event was organized by ACM Bangalore at the premises of Computer Society of India (CSI), Bangalore Chapter on Infantry Road. It was about making Linux into an enterprise real-time OS. Here I present a summary of the talk. If you are more curious, you can download the complete presentation.

Definition

How does one define a real-time system? It’s all about guarantees made on latency and response times. Guarantees are made about an upper bound on the response time. For this to be possible the run-time behaviour of the system must be optimized by design. This leads to deterministic response times.

We have all heard of soft and hard real time systems. The difference between them is that the former is tolerant to occasional lapse in the guarantees while the latter is not. A hard real-time that doesn’t meet its deadline is said to have failed. If a system can meet its deadline 100% of the time then it can be formally called a hard real-time system.

Problems with Linux

Linux was not designed for real-time behaviour. For example, when a system call is made, kernel code is executed. Response time cannot be guaranteed because during its execution an interrupt could occur. This introduces non-determinism to response times.

The scheduling in Linux tries to achieve fairness while considering the priority of tasks. This is the case with priority based Round Robin scheduling. Scheduling is unpredictable because priorities are not always strict. A lower priority process could be running at times until the scheduler gets a chance to reschedule a higher priority process. Kernel is non-pre-emptive. When kernel is executing critical sections interrupts are disabled. One more problem is the resolution of timer which is at best 4 ms and usually 10 ms.

Solutions in the Real-Time Branch

A branch of development has been forked from the main branch. This is called CONFIG_PREEMPT_RT. This contains enhancements to support real-time requirements. Some of these enhancements have been ported to the main branch as well.

One important change is on spin locks. These are more like semaphores. Interrupts are not disabled so that these spin locks are pre-emptive. However, spin locks can be used in the old way as well. It all depends if the APIs are called for spinlock_t or raw_spinlock_t.

The sched_yield has a different behaviour too. A task that calls this is added back to the runnable queue but not at the end of the queue. Instead it is added to its right level of priority. This means that a lower priority process can face starvation. If such a thing does happen, it is only because design is faulty. Users need to consider setting correct priorities to their tasks. There is still the problem of priority inversion which is usually overcome using priority inheritance.

There is also the concept of push and pull. In a multiprocessor system, decision has to be made about the CPU where a task will run. A task waiting in the runnable queue of a particular CPU can be pushed or pulled to another CPU depending on tasks just completed.

Another area of change is IRQ. IRQ is kept simple while the processing is moved to an IRQ handler. There was some talk on soft IRQ, top half and bottom half, something I didn’t understand. I suppose these will be familiar to those who have worked on interrupt code on Linux.

In plain Linux, timers are based on the OS timer tick. This does not give high resolution. High resolution is achieved by using programmable interrupt timers, which requires support from hardware. Thus timers are separated from the OS timer ticks.

Futex is a new type of mutex that is fast if uncontested. It happens in the user space. Only if the mutex is busy it goes to kernel space and it takes the slower route.

In IBM, the speaker mentioned the tools she had used to tune the system for real-time: SystemTap, ftrace, oprofile, tuna

Proprietary Solutions

Other than what’s been discussed above, other solutions are available – RTLinux, L4Linux, Dual OS/Dual Core and using Virtual Logic, timesys… There was not a lot of discussion about these implementations.

Enterprise Real-Time

Why is real-time behaviour important for enterprises? This is because enterprises make guarantees through Service Level Agreements (SLA). They guarantee certain maximum delays which can only be achieved on an RTOS. The greater issue here is that such delays are not limited to the OS. Delays are as perceived by users. This means that delays at the application layer have to be considered too. It is easy to see that designers have to first address issues of real-time at the OS level before considering the same at the application layer.

The presenter gave application examples based on Java. Java, rather than C or C++, is more common for enterprise solutions these days than perhaps a decade ago. The problem with Java is that there are factors that introduce non-determinism:

  • Garbage collection: runs when system is low on free memory

  • Dynamic class loading: loads when the class is first accessed

  • Dynamic compilation: compiled once when required

Solutions exist for all these. For example, the garbage collector is made to run periodically when the application task is inactive. This makes response times more deterministic. Static class loading can be performed in advance. Instead of just-in-time (JIT) compilation, ahead-of-time compilation can be done – this replaces the usual *.jar files with *.jxe files. Some of these are part of IBM’s solution named WebSphere Real-Time.

There is wider community that is looking at RTSJ – Real-Time Specifications for Java.

Conclusion

Real-time guarantee is not just about the software. It is for the system as a whole. Hardware may provide certain functionality to enable real-time, as we have seen for the case of higher resolution of timers. Since real-time behaviour is about response times, in some cases performance may be compromised. Certain tasks may be slower but this is necessarily so because they there far more important tasks that need a time guarantee. There is indeed a trade-off between performance and real-time requirement. On average, real-time systems may not have much better response times than normal systems. However, building a real-time system is not about averages. It is about an absolute guarantee that is far difficult to meet on a non-real-time system.

Read Full Post »

Earlier today I attended the Wireless Test World 2008 at the Le Meridien, Bangalore, a day-long seminar presented by Agilent Technologies. My particular interest was in learning about the test solutions they had in place for WiMAX and LTE standards. The former is fairly mature in both its flavours – Fixed and Mobile. The latter is not only new but also incomplete.

Lots of items in LTE standardization are still for further study (FFS). As can be expected, Agilent’s solution for LTE is an initial offering to test early PHY layer implementations. A full-fledged solution that incorporates a validated Conformance Test suite for full stack testing is still sometime away. Core standards are getting ready right now. We can expect the first test specifications later this year. Something concrete can be expected on this front from Agilent at about the same time since they are involved closely in the standardization process. Building upon their existing partnership with Anite for the conformance of GSM/UMTS implementations, LTE conformance solution from Agilent will take a similar route.

The interest on the day was greater for WiMAX, arguably because more companies in India are working on it than on LTE. The immediate future may be more promising for WiMAX, but LTE stands an equal chance from 2011 and beyond.

The seminar was primarily presentations about established and emerging technologies, and the test capabilities Agilent offers for these. There was sufficient time in between to look at Agilent’s test solutions and see live demonstrations of their equipment. The keynote address by Mr Bhaktha Keshavachar was about the challenges faced in integrating wireless connectivity into mobile devices. In particular, the future is about bringing different radio standards into the laptop. WiFi and Bluetooth are already standard on almost all laptops. We expect the same with GPS, 3G, WiMAX and LTE in the coming years. Well, some of these models are already out in the market. We are not talking about external plugin modules but about MiniCards fully integrated into the laptop. Apparently, MiniCard are standardized and they have an extremely small form factor. Key challenges are the co-existence of multiple radio standards on the same device (interference), platform noise, high peak currents, overheating, inter-working, system performance, battery life… let’s be assured that there may challenges that we may not yet be aware of.

When it comes to WiMAX, Agilent has an impressive line-up of equipment to meet all needs of a WiMAX programme – R&D, Design Verification, Pre-Conformance, Conformance, Manufacturing, Network Deployment, Service Assurance. An OFDM signal analyzer was available as early as 2004 and a signal generator in 2005. A one-box solution was available in 2007 which today has Wave 2 and MIMO functionalities.

Agilent WiMAX Test Equipment

Agilent WiMAX Test Equipment

There are many hardware models with accompanying software packages which are sold as licensed options. These support standard WiMAX test requirements – signal generation, signal analysis, modulation analysis, constellation diagrams, power measurements, peak-to-average metrics, spectral flatness, ACLR measurement, CCDF measurement, SEM measurement. This includes support for OFDM, OFDMA and MIMO.

Small companies with limited budget would have to make choices. The availability of similar equipment under different model numbers can make it difficult to choose the right one. The best option is to talk to the sales team and get as much information as possible. It’s about knowing if a particular choice meets one’s requirement. It’s also about knowing if we are buying more than what we really need.

Based on my understanding, I have put together a subset of WiMAX test equipment from Agilent. This covers only equipment specific to WiMAX. Of course, there are lots of complementary equipment that can be used for any radio standard – power supplies, logic analyzers, oscilloscopes, battery drain analysis equipment and others.

Model Number

Name

Remarks

N5181A MXG

Vector signal generator

  • Upto 6GHz.

N5182A MXG

Vector signal generator

  • Upto 6GHz.

  • Has capability to be used with N7615B.

E4438C ESG

Vector signal generator

  • Has capability to be used with N7615B.

E8267D PSG

Vector signal generator

  • Has capability to be used with N7615B.

N7615B

Signal Studio for 802.16 WiMAX

  • Software that can be used with vector signal generators.

  • Enables application specific signal generation without having to spend time in signal creation.

N9010A EXA

Signal Analyzer

  • Option 507 enables operation upto 7 GHz. Higher options are available.

  • Better value for money than MXA series.

  • Sophisticated user interface with colour coding of channels.

  • Provides enhanced spectrum analysis.

  • Provides support for measurement applications as optional extra – N9075A is for WiMAX.

  • Generally comes with 89600 series vector signal analysis software. Examples are 89601A and 89601X.

N9020A MXA

Signal Analyzer

  • Higher specs of N9010A. For example, has WiFi testing capability which its EXA counterpart doesn’t have.
89601M

Vector signal analysis measurement application

  • Can be used with N9010A EXA.

89601X

VXA signal analyzer measurement application

  • Can be used with N9010A EXA.

N9075A

WiMAX measurement application

  • Can be used with signal analyzers N9010A and N9020A.

  • Enables WiMAX specific signal analysis.

N8300A

Wireless Networking Test Set

  • One box solution with signal generator and analyzer.

  • Only for Mobile WiMAX.

  • Generally preferred over E6651A for manufacturing.

  • Used with N6301A.

N6301A

WiMAX measurement application

  • Used for WiMAX transmitter testing.

  • Used with N8300A.

E6651A

Mobile WiMAX Test Set

  • One box solution with signal generator and analyzer.

  • Only for Mobile WiMAX.

  • For R&D, pre-conformance and conformance testing.

  • For conformance testing, used with N6430A.

  • Used for Radiated Performance Test (RPT) by ETS-Lindgren.

N6430A

WiMAX IEEE 802.16-2004/Cor2 D3 PCT

  • For Protocol Conformance Test (PCT).

  • Based on E6651A.

  • In partnership with Anite supplied software.

  • TTCN-3 runtime environment and interfaces from Testing Technologies.

N6422C

WiMAX Wireless Test Manager

  • Software with ready-to-use tests.

  • Simplifies automated testing but not as formal as TTCN-3 based testing.

  • Can be used for pre-conformance testing.

  • Can be used with E6651A.

  • Can be used with E4438C ESG or N5182A MXG with N7615A/B license.

Note: It’s easy to find information about WiMAX on Agilent’s website. Go to URL http://www.agilent.com/find/wimax

Read Full Post »