In recent years the rapid increase in processing power of the personal computer has made it a significant competitor to high-end workstations for accelerator control and experimental physics applications. When the decreasing price of the PC and the availability of inexpensive commercial software is also considered, NT becomes a very attractive alternative to traditional UNIX systems. In order to simplify the integration of Personal Computers into our operating environment, we have ported the Control Device (CDEV) Interface to Windows NT. By supporting CDEV on this platform, we can provide routine access to our existing control system. Additionally, CDEV allows us to create an interface from our UNIX workstations to Windows NT applications (such as databases) that are significantly less expensive on the PC. This paper details the pitfalls we encountered during the software migration and will provide a direct comparison between the performance of CDEV applications on UNIX and NT. P articular attention is paid to network performance, which represents most of the overhead of this transition

Akers, W

Chen, J

Watson, C

Akers, W.

Chen, J.

Watson, C.

UNT Digital Library

CDEV-NT: PORTING THE CONTROL DEVICE INTERFACE TOWINDOWS NTW. Akers, TJNAF; J. Chen, TJNAF; C. Watson, TJNAFAbstractIn recent years the rapid increase in processing powerof the personal computer has made it a significantcompetitor to high-end workstations for acceleratorcontrol and experimental physics applications.  When thedecreasing price of the PC and the availability ofinexpensive commercial software is also considered, NTbecomes a very attractive alternative to traditional UNIXsystems.  In order to simplify the integration of PersonalComputers into our operating environment, we haveported the Control Device (CDEV) Interface to WindowsNT. By supporting CDEV on this platform, we canprovide routine access to our existing control system.Additionally, CDEV allows us to create an interface fromour UNIX workstations to Windows NT applications(such as databases) that are significantly less expensive onthe PC. This paper details the pitfalls that we encounteredduring the software migration and will provide a directcomparison between the performance of CDEVapplications on UNIX and NT.  Particular attention is paidto network performance, which represents most of theoverhead of this transition.1 MOTIVATIONS1.1 A Common InterfaceOne of our primary goals at Jefferson Lab has been todevelop and use a consistent programming interfacewhenever possible. CDEV is one of the products of thiseffort.  The CDEV core provides a standard interface thatcan be wrapped around any control system device makingit accessible through a standard API. CDEV extensionsprovide a set of network interface classes that simplify thedevelopment of client/server applications to extend thecontrol system.As Windows NT machines become more prominent inthe control room, concerns have been raised that theymight fragment our software development efforts andcreate unnecessary distinctions between programmerswho are developing similar products on differentplatforms.  The extension of CDEV to Windows NT isaimed at reducing this problem by providing a commoninterface to the control system on both platforms.1.2 Portable ApplicationsIn addition to making the transition between platformseasier for software developers, another goal is to make thesoftware as portable as possible.  Much of theincompatibility between platforms exists in the internalrepresentation of data and the techniques used to move thedata between machines. CDEV provides an API thatconceals communications details from the application,making it possible to write client/server programs that canbe compiled and run on either platform withoutmodification.2 THE DEVELOPMENTENVIRONMENT2.1 Compiler/Linker SelectionOne of the first considerations in porting CDEV toWindows NT was to determine which compiler should beused.  We examined the venerable GNU C++ compiler,which offered the benefit of having command lineparameters that would be consistent betweenarchitectures. Several factors dissuaded us from thisdecision.When porting CDEV to different UNIX architectureswe have traditionally used the native compiler for thatplatform and have provided the GNU compilation as analternative.  Additionally, the cost of compilers and goodquality development tools for Windows NT is relativelylow, making the use of GNU tools atypical on thisplatform. For these reasons, we opted to use the VisualC++ environment for software development.2.2 Selecting the Build EnvironmentThe selection of the build environment was a moredifficult decision than the selection of the compiler.GNU’s gmake is commonly used on most UNIXplatforms and has been the standard for building theCDEV distribution from the first release. However,building and installing gmake under Windows NT provedto be an annoyance and led us to consider usingMicrosoft’s build utilities.When performing a build under Windows NT, adeveloper has the option of using the Visual C++’s systemof project files or using Microsoft’s nmake.   We foundthat the project files used to perform a build in VisualC++ had many built in restrictions that limited our abilityto use our existing directory hierarchy.  Many of these“default options” could not be readily overridden, and weabandoned the project files in favor of performing thebuild with Microsoft’s nmake.The syntax of commands used by nmake is verydifferent from that used by gmake.  These differencesInternational Conference on Accelerator and Large Experimental Physics Control Systems603International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italyrequired us to create a separate makefile for WindowsNT. A consolidated Makefile is still present for all of theUNIX platforms, and a new Nmakefile has been added toperform the build for Windows.3 PITFALLS OF PORTING3.1 Dynamic Link Libraries vs. UNIX SharedLibrariesCDEV is designed to associate a device/message pairwith a control system object and then dynamically load alibrary (the cdevService) that acts as the interface betweenCDEV and the control system. In UNIX these are calledshared objects, in Windows NT they are called DynamicLink Libraries or DLLs. The most difficult part of portingfrom UNIX to Windows NT was in discovering thevaguely documented differences between UNIX sharedobjects and Windows NT’s DLLs.Our first and most significant discovery was that DLLsand Windows applications do not share file descriptors.This made it impossible to directly pass file pointers thatwere created in the application into a CDEV libraryfunction for I/O processing. One solution to this problemwas to convert any file descriptor to an osfHandle prior topassing it to the DLL and then have the DLL convert it toa file descriptor before using it. Besides being aninelegant solution, this approach produced source codethat was bafflingly complex and non-portable.After further discussions with Microsoft, we learnedthat we could link our applications and libraries with theshared version of the C standard libraries.  This wouldprovide file and memory operations to both theapplications and CDEV libraries from a common source,allowing file descriptors and certain memory blocks to beexchanged seamlessly.  While this approach will fail if theapplication and library are linked with different versionsof the C standard library, it provided the most efficientand portable solution to this problem.3.2 NetworkingThe socket API in Windows NT is remarkably similarto that used in UNIX and much of the code was reusedwithout modification. Many of the incompatibilities thatexisted were caused by function name differencesbetween the two platforms. To create a map betweenfunction names in Windows NT and similar functions onUNIX, a single file, cdevPlatforms.h, was added to theCDEV Generic Server distribution.  This file also mapserror codes returned by socket operations in Windows NTto the enumerated values that are commonly used inUNIX.The use of pipes in CDEV posed a more difficultproblem. In the UNIX environment, a pipe is functionallythe same as a file descriptor or a socket. In Windows NT,however, a pipe is a software entity created by theapplication that emulates a file descriptor.  Because ofthis, pipes that are generated by Windows NT cannot bepassed to the select system call. We addressed thisproblem by writing a new pipe function that creates twoUDP sockets and connects them to one another.  Thesetwo file descriptors are then returned to the caller as asocket pair.The select system call proved to have otherinconsistencies that had to be addressed.  When the usertells CDEV to pend for a specific time interval, thecdevSystem object will collect all of the file descriptorsfrom the underlying services and will select on them forthe specified interval. In UNIX, if no file descriptors arereturned by the services, the select function will sleepuntil the time interval expires.  Conversely, the WindowsNT implementation of select is designed to fail and returnimmediately if no file descriptors are specified.  In orderto make the behavior consistent between the twoplatforms, we added a cdevSelect function that detectsthis condition on Windows NT and explicitly calls sleep.3.3 Portable Data InterchangeAll of the data interchange in CDEV is performed usingSun’s External Data Representation (XDR).  XDR is usedto encode all data prior to transmission and to decode datathat is received. Because XDR libraries are not providedwith Windows NT, we have included Sun’s External DataRepresentation source code with our distribution.  Thesemodules are conditionally compiled when performing abuild on Windows NT.4 PERFORMANCE BENCHMARKS4.1 PlatformsIn order to make the comparison between the Windowand Unix versions of CDEV as fair as possible, wedecided to perform our benchmarks on the same twosystems.  The client system is a 133 MHz IBM ThinkPadand the server is a 450 MHz DELL Dimension. Bothsystems are configurable to run either Windows NT orRed Hat Linux and are connected using 10 Mbit Ethernet.4.2  Performance Test ApplicationThe test application measures the performance ofcommunications between a CDEV Generic Server andClient running on separate hosts.  The application used forthis test is provided with the CDEV distribution in the/extensions/cdevGenericServer/tests/Performancedirectory.Because most CDEV services are developed using theclient/server framework, our test focuses on throughputbetween a client and server.  The test begins bytransmitting very small (44 byte) packets between theclient and server, and calculating the time required to604complete a round trip.  The size of each packet isgradually increased until the packet size is one megabyte.As illustrated by the chart, the performance between thesame systems running Linux and Windows NT versions ofCDEV is consistent. For packets whose size is at the veryhigh and very low end of the scale, Windows NToutperforms Linux slightly. However, Linux showssignificantly better performance in the transmission ofmid-range packets.The dip that is seen when transmitting packets that are64 kilobytes is related to the buffering scheme that is usedby the CDEV Generic Server. One goal of the design is toensure that a server is not adversely impacted by amisbehaving or slow client. This is done by bufferingsmall packets and automatically forcing flushes when thedata transmission size reaches a certain threshold.  Futurereleases of the CDEV Generic Server will use a non-eventdriven scheme that will result in more consistentperformance at higher packet sizes.5 CONCLUSIONSThe performance difference between CDEVapplications compiled on Windows NT and Linux isnegligible and should not impact the decision of whichplatform to use.  The greatest benefit provided byWindows NT is the reasonable price and availability ofgood quality commercial software.  The developer can useCDEV to collect information from the control system andthen plug this information into products such as MicrosoftExcel or Access for analysis and reporting. Using theCDEV interface, developers will be able to write macrosfor these commercially available spreadsheets anddatabases that allow them to collect and analyze data inreal-time.6 FUTURE DIRECTIONSJefferson Lab in association with CERN is developingan extended CDEV interface that is written entirely inJava.  CDEV Java currently accesses the control systemthrough the CDEV Gateway and native Java method calls,and provides mechanisms for attaching to JDBCcompliant databases directly.CDEV extensions, such as the CDEV Generic Serverand CDEV Gateway, are continuing to be refined toimprove performance and reliability.  Upcomingdevelopment on these products will attempt to improvenetwork throughput and connection management byreplacing the current select-driven, socket managementmodel with a thread oriented approach.Version 1.7 of the CDEV distribution can be obtainedfrom the CDEV web page at http:\\www.jlab.org\cdev.REFERENCES[1] ‘An Object-Oriented Class Library for DevelopingDevice Control Applications’, J. Chen, W. Akers, G.Heyes, D. Wu, C. Watson, ICALEPCS 1995Proceedings.[2] ‘The CDEV Generic Server’, W. Akers, J. Chen, C.Watson, S. Witherspoon, J. Van Zeijts,  B. Bowling,ICALEPCS 1997 Proceedings.[3] ‘A Portable Accelerator Control Toolkit’, C. Watson,Particle Accelerator Conference 1997 Proceedings.010000002000000300000040000005000000600000070000008000000900000044 72 332 1100 4172 16460 32844 65612 131148 262220 1048652Packet SizeBits/SecondWINNT (Bits/Sec) LINUX (Bits/Sec)605

CDEV-NT: Porting the Control Device Interface to Windows NT

Abstract

Similar works

Full text

Available Versions

UNT Digital Library

CERN Document Server