home *** CD-ROM | disk | FTP | other *** search
/ Troubleshooting Netware Systems / CSTRIAL0196.BIN / attach / pcc / v08n03 / netwrk.exe / LANBENCH.ZIP / LANBENCH < prev    next >
Text File  |  1987-12-28  |  14KB  |  328 lines

  1. Title: Benchmarks for LAN Performance Evaluation
  2.  
  3. Author:
  4.  
  5.      Larry Press
  6.      Professor, Computer Information Systems
  7.      California State University, Dominguez Hills
  8.      10726 Esther Avenue
  9.      Los Angeles, CA 90064
  10.      (213) 475-6515
  11.      (213) 516-3579
  12.      ARPA: LPRESS@VENERA.ISI.EDU
  13.  
  14. Abstract:
  15.  
  16.      After a brief discussion of analytic models and simulation, 
  17.      this paper describes the benchmarks developed for a 
  18.      comparative study of eighteen local area network (LAN) 
  19.      hardware/software configurations.  Benchmark tasks were run 
  20.      on a foreground workstation while varying numbers of 
  21.      background workstations simulated contending activity.  Two 
  22.      background-activity programs, appropriate for different 
  23.      environments, are presented along with an example of their 
  24.      application.  The programs are available upon request.
  25.  
  26. Keywords:
  27.  
  28.      Local area network, performance evaluation, benchmarking
  29.  
  30. Acknowledgment:
  31.  
  32.      This work was done for Apple Computer in conjunction with 
  33.      the Seybold Group.
  34.  
  35. -----
  36.  
  37.      This paper is confined to LAN performance evaluation.  
  38. Performance is just one of many factors including hardware and 
  39. software compatibility, ease of installation and maintenance, 
  40. file and record locking, security, reliability, bridge and 
  41. gateway availability, and user interface quality, which should be 
  42. considered in LAN evaluation.  Discussion and checklists of such 
  43. general considerations may be found in books such as [1].
  44.  
  45.      After a brief discussion of analytic modeling and 
  46. simulation, our benchmarking approach and activity simulation 
  47. programs are described, along with an example of their 
  48. application.
  49.  
  50. I. Evaluation Alternatives
  51.  
  52.      Analytic modeling, simulation and benchmarking are three 
  53. performance evaluation alternatives.
  54.  
  55.      Analytic models have been developed for the low-level 
  56. physical and data-link layers of LANs.  They predict relative 
  57. efficiency of different network topologies (bus, star, and ring), 
  58. transmission media (twisted pair, broadband and baseband coaxial 
  59. cable and optical fiber), and access-control protocols (CSMA and 
  60. token passing).  Alternatives and analytic model results at this 
  61. level are reviewed in [2].  Analytic models of complete network 
  62. systems, including the characteristics of actual hardware and 
  63. software that implement low-level protocols, file and other 
  64. services, and applications have not been developed because of the 
  65. level of complexity and the variety of configurations.
  66.  
  67.      Simulation might be valuable for modeling a network file 
  68. system and its file-server hardware and software in addition to 
  69. low-level protocols.  Simulation models could go beyond analytic 
  70. studies, taking into account factors like disk directory 
  71. structures, seek-sequencing algorithms, server and workstation 
  72. buffer capacities and management algorithms, packet assembly 
  73. time, and error check time as they interact with the access 
  74. protocol and media.  Simulation would require a detailed 
  75. knowledge of the hardware and software being modeled, and would 
  76. probably be of most value to a LAN manufacturer.  
  77.  
  78.      Benchmarking is a third general alternative, which can 
  79. account for system-level complexity with relatively little 
  80. effort.  The remainder of this paper discusses the benchmarking 
  81. approach taken in a comparison of eighteen commercial LAN 
  82. configurations.
  83.  
  84. II. Benchmarks
  85.  
  86.      In our tests we used eleven IBM PC-XT personal computers as 
  87. workstations which could be connected using various media and 
  88. network interface cards.  We also varied the file server hardware 
  89. and network control program.
  90.  
  91.      For each configuration tested, one workstation was used as 
  92. the benchmark station, and the others were to simulate background 
  93. activity.  A suite of foreground tasks was run and timed on the 
  94. benchmark station while the number of background workstations was 
  95. varied from zero to as many as ten.
  96.  
  97.      Programs were written to simulate both constant and 
  98. intermittent background activity (figures 1 and 2).  
  99.  
  100.      The main loop of the constant-activity program (lines 60-
  101. 200) writes then reads a fixed length record and displays the 
  102. cumulative mean and standard deviation of the times between 
  103. transactions.  Reading then writing a fixed length record is a 
  104. simple example of network activity, and you could easily modify 
  105. the program for different activity, for instance to open/close a 
  106. file (as in Figure 2) or to force a seek to a randomly located 
  107. record.  
  108.  
  109.      In addition to generating background activity for the 
  110. benchmark tests, the mean and standard deviation of time between 
  111. transactions are computed.  The standard deviation is interesting 
  112. as a measure of the likely variability of response times when the 
  113. network becomes heavily loaded.  We were surprised to observe 
  114. that the means were not always constant from one background 
  115. station to the next.  In some configurations certain workstations 
  116. got more attention than others, presumably due to variation in 
  117. the characteristics of the network interface cards.
  118.  
  119.      The constant-activity program simulates performance when one 
  120. or more users access the network at the same time as the 
  121. foreground station.  Such contention might be heavy at certain 
  122. times during the day (for example in the morning when people were 
  123. reading mail and starting applications) or during software 
  124. development when several programmers were running compilers.  In 
  125. interpreting the importance of degradation due to such 
  126. contention, you would have to consider the likely distribution of 
  127. simultaneous access requests in your environment.
  128.  
  129.      The intermittent-activity benchmark is meant to simulate a 
  130. transaction-processing environment.  The time between network 
  131. transactions is normally distributed, with the mean and standard 
  132. deviation specified by the user.  The mean and standard deviation 
  133. would be chosen to represent your environment, and again the 
  134. transaction activity subroutine (lines 190-260) could be tailored 
  135. to reflect the nature of your transactions.  For instance, a 
  136. typical transaction might require two seeks and reads and writes 
  137. of specified-length records.
  138.  
  139. III.  Sample Run
  140.  
  141.      Figure 3 shows the results of running word processing and 
  142. file management foreground tasks while the constant-activity 
  143. program was executing on background workstations.  The files used 
  144. in the benchmark tasks were a 50 KB word processing document and 
  145. a 500 record dBase file.  Both files were artificial, generated 
  146. for these tests.  
  147.  
  148.      The results are not in elapsed time, but are normalized in 
  149. terms of the time to run the same task on a stand-alone PC-XT.  
  150. For example, loading the word processing program when no 
  151. background workstations were running took the same amount of time 
  152. as loading it from the hard disk of a stand-alone PC-XT, while 
  153. loading it when there was one background workstation running the 
  154. constant-activity program took 1.1 times as long as the stand-
  155. alone XT.  Note that some tasks, for example loading or saving 
  156. the word processing document, are faster on the network when 
  157. there is limited background activity than on a stand-alone XT.  
  158. That is due to the superior speed of the file-server disk drive 
  159. and the high network data rate.
  160.  
  161. IV. Conclusion
  162.  
  163.      This paper presents a straightforward approach to 
  164. benchmarking LAN performance along with two background-activity 
  165. programs.  The background-activity programs simulate constant 
  166. contention which would be encountered at load times in an office-
  167. automation or software-development environment and intermittent 
  168. contention which would be found in a transaction-processing 
  169. environment.  The tests are simple to setup, quickly run and 
  170. repeatable.  If you would like a copy of the programs (source and 
  171. object code), send me a formatted MS-DOS disk and a self-
  172. addressed, stamped mailer.
  173.  
  174. ------
  175.  
  176. References:
  177.  
  178.  
  179. 1. Archer, Rowland, The Practical Guide to Local Area Networks, 
  180.    Osborne McGraw-Hill, Berkeley, CA, 1986.
  181.  
  182. 2. Stallings, William, Local Networks, ACM Computing Surveys, ?? 
  183.    1984.
  184.  
  185. 3. Latour, Alain, Polar Normal Distribution, Byte, August, 1986.
  186.  
  187. -----
  188.  
  189. 10 REM CONST.BAS generates constant LAN activity, reporting
  190. 20 REM the variance of the time between transactions.
  191. 30 REM  -------------------------------------------------------------
  192. 40 GOSUB 220'  initialization subroutine
  193. 50 REM  -------------------------------------------------------------
  194. 60 REM Main loop
  195. 70 REM    TN       transaction number
  196. 80 REM    DELT     time since previous transaction
  197. 90 REM    SX       sum of the times between transactions
  198. 100 REM   SSX      sum of the squares of the times between transactions
  199. 110 REM   VAR      variance of the time between transactions
  200. 120 REM -------------------------------------------------------------
  201. 130 TN=TN+1
  202. 140 DELT=TIMER-PREV: PREV=TIMER
  203. 150 SX=DELT+SX: SSX=SSX+DELT^2
  204. 160 VAR = (TN*SSX-SX^2)/(TN*(TN-1))'     computer variance
  205. 170 PRINT "transaction:"; TN; " mean:"; SX/TN; " variance"; VAR
  206. 180 PUT #1, 1
  207. 190 GET #1, 1
  208. 200 GOTO 130
  209. 210 REM  -------------------------------------------------------------
  210. 220 REM Initialization of:
  211. 230 REM    N        length of the noise record
  212. 240 REM    D$       server "drive" for scratch file
  213. 250 REM    FLNM$    name of scratch file on server
  214. 260 REM    PREV     time of previous transaction
  215. 270 REM    QQ$      pad string to be written to disk
  216. 280 REM  -------------------------------------------------------------
  217. 290 KEY (1) ON
  218. 300 ON KEY (1) GOSUB 420'     stop execution
  219. 310 REM initialize file to be read
  220. 320 INPUT "enter record length: ", N
  221. 330 INPUT "enter drive identifier, without the colon: ", D$
  222. 340 PRINT "hit F1 to stop"
  223. 350 FLNM$ = D$ + ":junk"
  224. 360 OPEN "r", 1, FLNM$, N
  225. 370 FIELD #1, N AS Q$
  226. 380 QQ$=STRING$ (N, "q")
  227. 390 LSET Q$ = QQ$
  228. 400 PREV=TIMER'               initialize for statistics
  229. 410 RETURN
  230. 420 END'                      operator hits F1 to stop execution 
  231.  
  232. Figure 1.  A program for generating constant background activity 
  233. during LAN benchmarking.
  234. -----
  235.  
  236. 10 REM NORM.BAS generates normally distributed LAN noise.
  237. 20 REM  ---------------------------------------------------------------
  238. 30 GOSUB 500'                 initialization subroutine
  239. 40 REM  ---------------------------------------------------------------
  240. 50 REM main program
  241. 60 REM    DEL        time until next net event
  242. 70 REM    NXT        time of next event
  243. 80 REM    TN         transaction number
  244. 90 REM  ---------------------------------------------------------------
  245. 100 GOSUB 310'                 get random variable in Z
  246. 110 DEL = M + SD*Z
  247. 120 NXT = TIMER+DEL
  248. 130 TN = TN+1
  249. 140 PRINT "Transaction"; TN; "in"; DEL; " seconds."
  250. 150 IF TIMER < NXT THEN 150
  251. 160 GOSUB 200'                 fire off some network activity
  252. 170 GOTO 100
  253. 180 REM  -------------------------------------------------------------
  254. 190 REM Subroutine with side effect of network activity.
  255. 200 OPEN "r", 1, FLNM$, N
  256. 210 FIELD #1, N AS Q$
  257. 220 LSET Q$ = QQ$
  258. 230 PUT #1, 1
  259. 240 GET #1, 1
  260. 250 CLOSE #1
  261. 260 RETURN
  262. 270 REM  -------------------------------------------------------------
  263. 280 REM This subroutine returns a standard normal random variable
  264. 290 REM in Z, but it has lots of side effects (TOGGLE, Z2, S, R1, R2).
  265. 300 REM See Byte Magazine, 8/86, for a discussion of the algorithm.
  266. 310 IF TOGGLE = 1 THEN Z=Z2: TOGGLE=0 : RETURN
  267. 320 TOGGLE=1: S=1
  268. 330 WHILE (S>=1)
  269. 340   R1=2*RND-1
  270. 350   R2=2*RND-1
  271. 360   S=R1^2 + R2^2
  272. 370 WEND
  273. 380 S=SQR(-2*LOG(S)/S)
  274. 390 Z=S*R1: Z2=S*R2
  275. 400 RETURN
  276. 410 REM  -------------------------------------------------------------
  277. 420 REM Initialization of:
  278. 430 REM    M        mean time between network events
  279. 440 REM    SD       standard deviation of time between events
  280. 450 REM    N        length of pad record
  281. 460 REM    D$       server "drive" for scratch file
  282. 470 REM    FLNM$    name of scratch file on the server  
  283. 480 REM    QQ$      pad string to be written over the network
  284. 490 REM  -------------------------------------------------------------
  285. 500 KEY (1) ON
  286. 510 ON KEY (1) GOSUB 630'   stop execution
  287. 520 REM initialize the distribution
  288. 530 RANDOMIZE TIMER
  289. 540 INPUT "enter mean time between network activity: ", M
  290. 550 INPUT "enter the standard deviation: ",SD
  291. 560 REM initialize the file to be read
  292. 570 INPUT "enter record length: ", N
  293. 580 INPUT "enter drive identifier, without the colon: ", D$
  294. 590 FLNM$ = D$ + ":junk"
  295. 600 QQ$=STRING$ (N, "q")
  296. 610 PRINT: PRINT "Hit F1 to stop."
  297. 620 RETURN
  298. 630 END'                     operator hits F1 to stop execution
  299.  
  300. Figure 2.  A program for generating normally distributed 
  301. background activity during LAN benchmarking [3].  This would be 
  302. appropriate for simulating transaction-processing environments.  
  303.  
  304. -----
  305. Server: 3Com 3server
  306. Network interface card: 3Com, short ethernet board
  307. Cable: thin ethernet
  308. Network control program: 3Com Ether Series
  309.  
  310.                                    NUMBER OF BACKGROUND WORKSTATIONS
  311.  
  312.  TASK                                 0      1      3      5     10
  313.  
  314.     Word Processing (50 KB)
  315.        load program                  1.0    1.1    1.5    1.8    6.1
  316.        load document                 0.7    0.7    0.9    1.3    2.3
  317.        save document                 0.5    0.6    0.7    0.9    2.8
  318.  
  319.     File Management (500 record)
  320.        load program                  1.1    1.3    1.9    2.3    9.6
  321.        serial search                 1.0    1.0    1.1    1.4    2.7
  322.        sort                          1.0    1.0    1.2    1.4    3.7
  323.        index                         0.9    1.0    1.0    1.3    3.3
  324.  
  325.  
  326. Figure 3.  This is a typical test run.  The results are 
  327. normalized to the times of a stand-alone IBM PC-XT executing the 
  328. tasks from its local hard disk.