FDPW Volume Technical Issues of RealTime Network Simulation in Linux Andrei V Gurtov Department of Computer Science University of Helsinki Department of Computer Science UniversityofPetrozavo dsk POBoxTeollisuuskatu FIN University of Helsinki Finland Email gurtovcshelsinkifi Abstract Realtime network simulation requires dealing with miscella neous technical problems to achieve a correct and timely execution Ignoring those issues can render a valid mo del useless b ecause its implementation would pro duce erroneous results This pap er iden ties and discusses the problems sp ecic for a Linux op erating sys tem on the x architecture A problem of accurate eventschedul ing in a simulation pro cess without disturbing other pro cesses is the most imp ortant and is considered in detail Several solutions to this problem are evaluated by measurements The results show that no single solution ts all criteria but the most appropriate metho d can b e selected according to the goals of a simulation study c Andrei V Gurtov Andrei V Gurtov If youre trying to solve realtime sort of problems you aredealing with some fairly thorny technical issues B Gallmeister a vicechar of POSIX Intro duction Studying the b ehavior of Internet proto cols over a real data link or net work is often costly or if a system is only in a development stage imp os sible An alternativeway is to build a mo del that emulates the network of interest and then using this mo del to measure the p erformance of real networking applications An understandable desire 100 of any mo deler is to concen trate the eort on developing 80 a conceptual mo del of the system under study and to the computer as a p er treat 60 fect implementation to ol that accurately follows the event 40 schedule Unfortunately this Actual line rate (kbps) do es not work as most othe p ersonal computers and shelf 20 UNIXlike op erating systems not designed for realtime are 0 0 20 40 60 80 100 use have coarse timer resolu Requested line rate (kbps) tion and are prone to delays Figure Actual versus requested caused by the hardware a disk line rate Measured with WINES or network access and by the simulator using byte packets op erating system Esp ecially Sleeps are p erformed using a stan in amultipro cess environment dard Linux system call keeping a realtime schedule can be hard b ecause a simu lation pro cess has to comp ete with other pro cesses for system resources Consider Figure for example It presents p erformance results from the rst version of the Wireless Network Simulator Wines a to ol for studying the b ehavior of network proto cols over GSM develop ed at the Department of Computer Science University of Helsinki Wines emulates RealTime Network Simulation in Linux a slow wireless link by delaying data packets and the actual line rate maintained by the simulator is exp ected to b e the same as requested in a conguration le In practice as can b e seen from the gure the actual line rate is lower than the requested line rate The error is pro duced b ecause the simulator relies on a standard Linux system call to p erform accurate delays Appropriate services of an op erating system for realtime applications is an active research area An imp ortant landmark is POSIX sp eci cations for p ortable realtime programming However many related issues are highly sp ecic for a particular hardware and op erating system In this pap er we discuss technical issues of realtime network simula tion on a Linux op erating system run on a PC A problem of accurate event scheduling in a simulation pro cess without disturbing other pro cesses is the most imp ortant and is considered in detail Most related work is concentrated only on achieving the highest p ossible accuracy but ignoring practical factors that are sometimes decisive for the usage of a metho d In this pap er we take into consideration such issues as the amount of mo dications needed in the Linux kernel and transparency of a metho d for applications Several solutions to the problem of accurate delay are evaluated by measurements The results show that no single solution ts all criteria but the most appropriate metho d can b e selected according to the goals of a simulation study Other problems are outlined and p ossible solutions to them are suggested but an extensiveevaluation is the sub ject of future work Details not presentin this pap er due to the lackof space can be found in Seawind realtime simulator A Software Emulator for Analyzing Wireless Network Data transfers Sea wind is develop ed as a to ol for exploring the behavior of real Internet proto cols mostly TCP over wireless datalink services provided by GSM GPRS and HSCSD It may be classied as a realtime distributed functional simulator The simulation system consists of several simu We use the term PC to refer to any p ersonal computer based on i and its successors Andrei V Gurtov lation pro cesses connected in a pip eline so that every simulation pro cess corresp onds to some subsystem of the mo deled network Simulation pro cesses can be distributed on several computers and exchange messages using unmo died TCP or UDP proto cols The simulation pro cess is designed based on the Mowser library that among other to ols includes a generic event dispatcher mev A Mowser client can register event handlers for a numb er of sp ecic events a descriptor is ready for writing or reading an alarm go es o a pro cess receives a signal etc Unfortunately mev was not initially designed to b e a realtime scheduler and was never used in this way Exp erience with Seawind will show the existing problems and appropriate enhancements could b e made to mev in the future Several simulation pro cesses are managed with a control to ol via a graphical user interface The client and the server are normal Internet hosts that run a networking application over the Seawind system that tunnels packets p ossibly delaying mo difying or dropping them The back ground load can b e emulated either articially or explicitly with external load generators The conguration of the simulation pro cess is read b efore starting a test and is not a problem but logging may happ en during an exp eriment run and can cause undesired delays Two factors imply that it is not wise to demand the usage of a mo died Linux kernel for all exp eriments First as a rule every simulation pro cess should b e run on a separate PC Second the Seawind simulator is used in several organizations and they may not have resources to install a mo died Linux system In this pap er we outline the cases in whichthe kernel mo dication is a must and cases where the required accuracy can be achieved by suggested metho ds in the user software The problem of an accurate sleep time Denition of the problem The standard Linux kernel on PC provides a pro cess sleep time resolution of ms with a minimum of approximately ms As a rule the actual sleep time is ms more than requested In the later sections we will see reasons for such coarse b ehavior but rst we consider the implications of these facts to our realtime network simulator RealTime Network Simulation in Linux 200 Figure shows the 25−byte packets y per packet to dela 180 200−byte packets 1000−byte packet emulate a slow link of a 160 given line rate The de 140 lay value is determined 120 by the line rate and 100 by the packet size To limitations demonstrate 80 of the standard Linux Slow down delay per packet (ms) 60 sleep metho d let us 40 consider mo deling a 20 GPRS data link Con 0 three main ceptually 0 20 40 60 80 100 120 140 160 180 200 Line rate (kbps) levels of mo del granu larity can be identied Figure The computed delay per packet the IP packet layer versus requested line rate typical packet size of bytes LLC typical packet size of bytes and RLC typical packet size of bytes Taking into account the accuracy of sleeps and observing Figure we see that in standard Linux mo deling of RLC is out of question LLC can b e mo deled with meaningful results up to kbps and only the IPlevel seems to b e manageable for higher line rates In practice even IPlevel mo deling would give inaccurate results b ecause sleeps are always greater than requested and the accumulated delaywould result in the line rate of the emulated link to b e lower than requested In mo deling a data link some amountofvariation of delay p er packet is acceptable and sometimes even natural b ecause it is also presentonthe real link However the errors in individual sleeps should not accumulate or otherwise the results would b e biased Events for downlink and uplink channels of the Seawind simulation pro cess are scheduled concurrently Because of this an average sleep re quest would b e half of that is given in Figure Note also that it only accounts for slow down sleeps so if a pro cess is interrupted during the sleep to pro cess some event for example background load packet arrival and then go es to sleep again the error maybemuch larger We assume kbps is bps but Kbyte is bytes Andrei V Gurtov Formalization of the problem In this section wegivea numberofnumerical parameters that can b e used in the comparison of dierent metho ds of accurate sleep All sleep requests can b e roughly divided into two groups The rst group consists of one o ccurrence sleeps that are not dep endentoneach other An example is a random delay mo deling the eect of some rare event for instance a cell change The accuracy of such sleeps is more dicult to improve but on the other hand such sleeps tend to be rare and large in value thus the relative error for such