Workload Characterization of NetWare Clients and Servers Using a Protocol Analyzer
Articles and Tips: article
Senior Consultant
Systems Research Department
01 Jul 1991
This AppNote introduces two LANalyzer applications you can use to characterize workloads associated with NetWare clients, servers, and segments that support NetWare traffic exclusively. Although the instructions are specifically for Novell's LANalyzer, you can adapt them for other protocol analyzers.
- Introduction
- Characterizing Workload with a Protocol Analyzer
- Client and Server Workload Applications
- Creating and Running WC_NCPC
- Creating and Running WC_NCPS
- Characterizing NetWare Segments Using WC_NCPS
- Converting the Data
Introduction
The transparency of network traffic, or workload, has always created challenges for anyone tackling network design and optimization projects. As discussed in "An Introduction to Workload Characterization" (May 1991 NetWare Application Notes), workload characterization is the one toolkit that has the potential to eliminate much of the guesswork you've been accustomed to. Once you characterize the workloads related to specific servers, clients, and network segments, decisions regarding network design and optimization strategies can become amazingly simple.
This AppNote introduces two LANalyzer applications tailored to characterizing workloads associated with NetWare clients, servers, and segments that support NetWare traffic exclusively.
The WC_NCPC application characterizes the traffic associated withan individual NetWare client. A client can represent a person using a network workstation, or an application (such as a report generator) that runs unabated without user intervention.
The WC_NCPS application characterizes the traffic associated with a NetWare server. It can also be used to characterize workloads created by muliple servers and their associated clients on a single network segment.
I'll also discuss briefly how you can use the workload characterization results provided by these tools.
Characterizing Workload with a Protocol Analyzer
Ideally, there are many points at which you need to measure workload in order to paint a complete picture of what's happening on the network. The ability to measure every point, however, may be limited by the tools available to you. This AppNote focuses on only one of those tools - the protocol analyzer, specifically Novell's LANalyzer.
On the Wire Versus Inside the Box
To form a complete picture of workload, you need to understand how each component within a LAN or workgroup is being used. In a small workgroup network with one server and three workstations, for example, you'd have to take measurements in five general locations:
inside the shared server
inside each of the three client workstations
inside the shared network cable plant
Protocol analyzers are designed to capture and analyze network traffic as it is propogated through a network cable plant. However, they also allow you to gather a surprising number of client and server workload statistics without ever looking inside either the file server or the workstations. By focusing your analysis on the network cable plant, you can characterize not only the shared network media traffic but also the request and response workload produced by the network's servers and clients.
The only missing piece is the effect of workload on shared resources other than the wire - how the resources of the servers and clients are being utilized or affected by the request and response workload on the wire. For example, using a protocol analyzer, there is no way of measuring server disk channel utilization or client CPU utilization. Tools for measuring workload and resource utilization in those devices will be the subject of future AppNotes.
Levels of Characterization
"An Introduction to Workload Characterization" introduced three levels of characterization: physical, logical, and functional. These levels provide a means of classifying and simplifying the mountain of data produced by a protocol analyzer.
The Physical Level
Within the physical level, workload is made up of a continuous stream of bytes and packets. By analyzing activity at this level, you can determine whether a particular network component is under- or over-utilized, what level of fairness (or access) is available to a specific client, and what type of error conditions exist.
Using the filtering tools provided by protocol analyzers, you can focus your view on one or more clients, on specific servers, or even on an entire network segment. For example, by filtering network traffic on a specific node address and isolating both request and response traffic, you can get an accurate picture of that node's workload volume, intensity, and patterns. Both the client and server characterization applications introduced in this AppNote use filtering to focus on specific devices. Removing the address filters from the WC_NCPS application allows you to characterize an entire segment.
Filters for Requests and Responses. It's easy to determine which packets are requests and which are responses by creating one filter for packets transmitted by a client (service requests) and another filter for packets received by a client (service responses). Of course, when analyzing a server, it's the other way around - transmissions are service responses, and receptions are service requests. So, by including two seperate filters, you can capture statistics including:
total bytes received
total bytes transmitted
total packets received
total packets transmitted
client-server utilization of the media
peak bytes per second
peak packets per second
After tracking these figures over a long period of time, you can make more informed decisions when the need arises. For example, you might find that, on the average, one server is processing 8.28MB of raw data per hour while another is processing 277.22MB per hour. With data like this, it's not hard to determine which server should be the focus of your attention.
The Logical Level
Within the logical level, workload is made up of request and response packets coded in Novell's NetWare Core Protocol (NCP). These, together with a variety of housekeeping packets, make up the entire workload viewed within the physical level.
Six Prominent NCPs. Tracking NCPs is a bit trickier than just watching request and response packets, though. Novell now has over 300 NCPs defined, any of which may occur on the wire. In a joint research project involving Engineering and Systems Research staff, we isolated six NCPs that make up the majority of all traffic in a production environment. They are:
Read From A File
Write To A File
Open A File
Close A File
File Search Initialize
File Search Continue
These six NCPs can represent up to 98 percent of a client's or server's workload, or as little as 76 percent, depending upon the application set. (The means for calculating these percentages for your network components is included in the applications introduced below.) With few exceptions, none of the remaining NCPs individually make up more than 1 percent of the total client/server workload being measured, whether the measured object is a client, a server, or a segment.
The percentage of workload represented by these NCPs, both individually and in combination, is an important part of the workload puzzle. Some of the statistics you can derive from the NCP counts gathered by your protocol analyzer include:
the total number of Read From A File requests;
the percentage of Read From A File requests over total requests;
the ratio of Read From A File requests to Write To A File requests.
These workload percentages and ratios are particularly useful in network optimization strategies. For example, suppose that after some analysis you find that the ratio of reads to writes in a large database server is 12:1. Your optimization recommendation would be much different than if the ratio was just the opposite or even a different number altogether.
Housekeeping Traffic. Once you account for the percentage of workload created by the six file-service NCPs above, the remaining workload is largely housekeeping functions. Depending on your customized set of applications and network operations, some of those functions may include:
Get Bindery Access Level
Create Service Connection
End of Job
Get File Server Date and Time
Close File and Start A Queue Job
Lock Physical Record Set
The percentage of housekeeping traffic can vary from 2 percent to as high as 20 percent. Both extremes tell you a great deal about how the network is being used by the clients and applications.
The Functional Level
The functional level of data analysis focuses on transactions made up of multiple NCPs, the ordering of the NCPs within transactions, and the order and response times of transactions. However, until protocol analyzers mature somewhat and allow you to build additional logic into your filters, this level of analysis can quickly become a laborious process of searching through trace files by hand. The most commonly used technique for analysis at this level is usually performed by the programmer who codes performance meters directly into the application program.
Our discussion of the two enclosed applications will focus on the physical and logical levels of workload characterization, leaving the functional level analysis using protocol analyzers to a future AppNote.
Client and Server Workload Applications
This AppNote explains how to create and use two LANalyzer applications to gather workload characterization data for network clients and servers. The name for the first application, WC_NCPC, stands for "workload characterization of NetWare Core Protocol traffic at a client." The second application, WC_NCPS, is similar but for the server. Instructions for setting up and running these applications are included at the end of the AppNote. Although the instructions are specifically for Novell's LANalyzer, you can adapt them for other protocol analyzers.
Once you gather workload characterization data and convert it to spreadsheet-compatible files, your analysis options are endless. To give you an idea of the types of results you can obtain, Figures 1 and 2 show sample graph and spreadsheet printouts of WC_NCPC data that I produced with Borland's Quattro Pro. Figures 3 and 4 are sample graph and spreadsheet printouts of NC_NCPS data that I produced with Quattro Pro.
Figure 1: Graph of client workload characterization data obtained from WC_NCPC.
Figure 2: Spreadsheet report of client workload characterization data from WC_NCPC.
Client: Novell
Location: Provo
Description: Workload Characterization - Physical Layer
Server: LEGAL
Client ID: LEGAL Test Type: WC_NCPC SERVER, USER
Date: 3/5/91 Test Name: LEGAL1
Period: 8am-12am Location: F:\USERS\RLEE\WC\LAURA\
Elapsed Time: 4 Hours
-------- Test Summary --------
Start Date Start Time End Date End Time Time Interval (Secs) Number of Samples
03/05/91 08:08:23 03/05/91 12:07:52 6 7138
-------- Channel Summary --------
Number Name Total Bytes Total Packets Avg. Util. Peak Util. Peak Pkts/s
1 Reads 1105612 16259 6.9E-05 0.007773 17
2 Writes 910694 2898 5.1E-05 0.027272 69
3 FsearchC 453884 6615 2.8E-05 0.005239 8
4 FsearchI 72988 1034 5E-06 0.000606 1
5 Opens 43442 545 3E-06 0.000723 1
6 Closes 26752 418 2E-06 0.00051 0
7 Xmit 2820976 30705 0.00017 0.027301 69
8 Thrput 16830694 61410 0.000961 0.104222 139
9 Recv 14009718 30705
10 HOOKI21 182530
-------- Total Workload Statistics --------
Total Workload (MB) 16.05 Average Packet Length (Bytes) - Recv 456.27
Average Workload (MB/hr) 4.01 Average Packet Length (Bytes) - Xmit 91.87
Total Net Access Time (Min) 19.2 Average Packet Length (Bytes) - Thrput 274.07
-------- Workload Character Statistics --------
Six Request Packets % of Xmi 0.9
Six Request Bytes % of Xmit 0.93
Reads / Writes Ratio (RPCs) 5.61 to 1 1
Figure 3: Graph of server workload characterization data gathered with WC_NCPS.
Figure 4: Spreadsheet report of server workload characterization data from WC_NCPS.
Client: Novell
Location: Provo
Description: Workload Characterization - NetWare Server
Server: NSD
Client ID: PRV-SRS Test Type: WC_NCPS
Date: 3/13/91 Test Name: SRS0313
Period: 8am-12am Location: F:\USERS\RLEE\WC\STS\
Elapsed Time: 4 Hours
-------- Test Summary --------
Start Date Start Time End Date End Time Time Interval (Secs) Number of Samples
03/12/91 18:33:30 03/13/91 18:00:00 6 7202
-------- Channel Summary --------
Number Name Total Bytes Total Packets Avg. Util. Peak Util. Peak Pkts/s Peak KB/s
1 Reads 580056942 8527407 0.012006 0.038803 673 44
2 Writes 140363940 272701 0.002639 0.058356 152 85
3 Fsearch 1494996 21644 3.1E-05 0.01264 269 17
4 OpnCls 14232914 186374 0.000291 0.002738 91 6
5 Delays 22336 349 0 0.000173 7 0
6 SapRip 1349692 9714 2.6E-05 0.002685 35 6
7 Recv 751700797 9234525 0.015289 0.076653 689 104
8 Thrput 4780529270 18467182 0.091282 0.314578 1378 388
Xmit 4028828473 9232657
-------- Total Workload Statistics --------
Total Workload (MB) 4559.07 Average Connection Count 132
Average Workload (MB/hr) 379.92 Average Workload Per Connection (MB) 34.54
Total Net Access Time (Min) 720 Average Workload Per Connection (MB/hr) 2.88
Total Net Access Time (%) 100.00%
-------- Workload Character Statistics --------
Six Request Packets % of Xmi 98.00% Average Packet Length (Bytes) - Recv 436.37
Six Request Bytes % of Xmit 98.00% Average Packet Length (Bytes) - Xmit 81.4
Reads / Writes Ratio (RPCs) 31.27 to 1 Average Packet Length (Bytes) - Thrput 258.87
Recv / Xmit Ratio (Bytes) 5.36 to 1
SapRip Bytes % of Thrput 0.03%
Delays % of Thrput (RPCs) 0.00%2
I've found the three most useful numbers in the spreadsheet reports to be:
Average Utilization of the Thrput channel
Peak Utilization of the Thrput channel
Reads / Writes Ratio (RPCs)
The following sections suggest just a few ways you can use these workload statistics in real-life network design, optimization, and management.
Understanding the True Workload of NetWare Clients
Networks are very good at hiding the complexity of protocols, routers, bridges, tokens, and so forth. As a result, technical and non-technical people alike sometimes have incorrect perceptions about how much workload one individual or group of individuals place on a network. These misconceptions can create confusion, especially when response times go into the red zone, or when additional design or optimization decisions come up.
In "An Introduction to Workload Characterization," we looked at the sample case of Laura Maxwell, a legal secretary running WordPerfect 5.1 from within Microsoft Windows. The graph in Figure 1 represents the overall network utilization by Laura's workstation as sampled on March 5, 1991. With her legal responsibilities, Laura uses her word processor more heavily than most other types of users would. Yet her workstation's use of the network is very light. Why? Due to the design of WordPerfect, most of the processing takes place in the workstation. Only file import, export, and search activity uses the server's resources.
Looking at the corresponding numbers in Figure 2, however, you get quite a different picture of the workload. During the sampling period, Laura's workstation sent 30,705 requests to the server and received 30,705 responses, for a total of 61,410 packets. That represents just over 16MB of raw data in four hours!
As you can see, WC_NCPC results give you some hard data regarding average workload, peak periods, and trends that affect your design and optimization decisions. The resulting mental images of workload on the network are often quite different from previous misconceived notions.
Comparing Server Workloads
Server workloads are misunderstood and miscalculated just as often as those of individual users. As an example, consider three seperate servers serving three different environments - a workgroup, a department, and a division.
Figure 5 represents the workgroup server used by Laura Maxwell and the legal staff that works with her - an average of eight users throughout the day.
Figure 5: Workload graph for a small workgroup server.
Figure 6 represents a departmental server used by an accounting department in a $500M company, servicing an average of 50 users.
Figure 6: Workload graph for a departmental server.
Figure 7 represents a large server with 4GB of disk space and a mission critical database with over 200 users.
Figure 7: Workload graph for a division server.
With just one quick glance at these three figures, it's easy to see why early versions of NetWare running on XTs were sufficient for most user workloads created by fewer than 50 users. With much of the workload distributed to the workstation, the volume and intensity of service requests aimed at the server are fairly low given that number of users. When we move to several hundred users, as in Figure 7, workloads begin to inch up towards a more efficient use of the media and network components.
Hopefully, the workload characterization data provided by WC_NCPC and WC_NCPS will provide both technical and non-technical decision makers with a correct perception of how much their network resources are being utilized.
Creating and Running WC_NCPC
As explained earlier, the application name "WC_NCPC" stands for "workload characterization of NetWare Core Protocol traffic at a client." WC_NCPC is a LANalyzer application that uses the LANalyzer's enhanced filter mode, start and stop triggers, all eight receive channels, and 16 patterns. If you own a LANalyzer, you can easily create WC_NCPC using the following specifications. (See your Novell LANalyzer Reference Manual for instructions on creating, editing, and saving applications.)
Specifications
Receive Channels. The following specifications describe the parameters for eight receive channels, which are:
Reads
Writes
FsearchC
FsearchI
Opens
Closes
Xmit
Thrput
The first six channels compute statistics regarding the six most prevelant NCPs mentioned earlier. Since transmitted packets represent client requests, these six channels are designed to track only packets being transmitted by the target client.
The Xmit channel gathers statistics regarding the total packet stream transmitted by the client. The Thrput channel gathers statistics regarding both packets transmitted and received. With this design, it's easy to compute the Rcv traffic by subtracting the Xmit totals from the Thrput totals. Refer to Figure 8 as you set up these channels.
Since the majority of NetWare clients do not normally participate in RIP or SAP communications, there is no need to track that traffic with this application. However, you will want to track RIP and SAP traffic with the server application.
Filter Pattern Template. The NetWare template used with all of the filter patterns is supplied with the LANalyzer software.
|
Template Search Path:
|
C:\XLN\LANZ\TEMPLATE
|
|
|
Pattern |
Template |
Overriding Offset |
|
rcv |
NetWare |
None |
|
xmit |
NetWare |
None |
|
open |
NetWare |
None |
|
opennew |
NetWare |
None |
|
close |
NetWare |
None |
|
read |
NetWare |
None |
|
write |
NetWare |
None |
|
fsearchc |
NetWare |
None |
|
fsearchi |
NetWare |
None |
Figure 8: Channel settings for the WC_NCPC application.
Channel 1 Channel 5 Name: Reads Name: Opens Active: Yes Active: Yes Size Range From/To: Min/Max Size Range From/To: Min/Max Packets Allowed: Good Packets Packets Allowed: Good Packets Collect Stats.: Yes Collect Stats.: Yes Start Count: Off Start Count: Off Stop Count: Off Start Count: Off Filter patterns: (xmit) AND (read) Filter patterns: (xmit) AND (open or opennew) Channel 2 Channel 6 Name: Writes Name: Closes Active: Yes Active: Yes Size Range From/To: Min/Max Size Range From/To: Min/Max Packets Allowed: Good Packets Packets Allowed: Good Packets Collect Stats.: Yes Collect Stats.: Yes Start Count: Off Start Count: Off Stop Count: Off Stop Count: Off Filter patterns: (xmit) AND (write) Filter patterns: (mxit) AND (close) Channel 3 Channel 7 Name: FsearchC Name: Xmit Active: Yes Active: Yes Size Range From/To: Min/Max Size Range From/To: Min/Max Packets Allowed: Good Packets Packets Allowed: Good Packets Collect Stats.: Yes Collect Stats.: Yes Start Count: Off Start Count: Off Stop Count: Off Stop Count: Off Filter patterns: (xmit) AND (fsearchc) Filter patterns: (xmit) Channel 4 Channel 8 Name: FsearchI Name: Thrput Active: Yes Active: Yes Size Range From/To: Min/Max Size Range From/To: Min/Max Packets Allowed: Good Packets Packets Allowed: Good Packets Collect Stats.: Yes Collect Stats.: Yes Start Count: Off Start Count: Off Stop Count: Off Stop Count: Off Filter patterns: (xmit) AND (fsearchi) Filter patterns: (xmit or rcv)
Filter Patterns. In the pattern descriptions shown in Figure 9, I've used a workstation with the Ethernet address NOVELL30EB7F as an example target workstation. Before running WC_NCPC on your network, you'll have to fill in a new target address.
The word "None" means the same thing as "Don't care" in the LANalyzer Reference Manual. "Req Type" and "Function Code" refer to fields within the filter pattern template.
Figure 9: Filter patterns for the WC_NCPC application.
|
Pattern Name: |
rcv |
|
Station: |
XX XX XX XX XX XX -> NOVELL30EB7F |
|
Type: |
None |
|
Data: |
None |
|
Pattern Name: |
xmit |
|
Station: |
NOVELL30EB7F -> XX XX XX XX XX XX |
|
Type: |
None |
|
Data: |
None |
|
Pattern Name: |
read |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 72 |
|
Pattern Name: |
write |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 73 |
|
Pattern Name: |
fsearchc |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 63 |
|
Pattern Name: |
fsearchi |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 62 |
|
Pattern Name: |
open |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 65 |
|
Pattern Name: |
opennew |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 76 |
|
Pattern Name: |
close |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 66 |
Operating Instructions
Trigger Setup. For comparative purposes based on time of day and length of test, you should always run WC_NCPC with triggers. The most useful test periods for my analysis purposes have been one hour, four hours, ten hours, and twelve hours. My recent favorite is the ten hour test, from 7:30am to 5:30pm. Because the test has to be reset each night, the 5:30pm stop trigger allows me to reset the test for the next day and still leave early enough to get home at a reasonable hour.
LANalyzer users will recognize the following lines from the LANalyzer's trigger parameters screen:
Start collecting at 07:30:00 hrs. or no other trigger.
Fire stop trigger at 17:30:00 hrs. or no other trigger.
Once stop trigger has fired, collect an additional 0 packets.
When the trace buffer is full, overwrite old packets.
Data Collection Setup. Due to the extended length of most workload characterization tests, the resulting mountain of information presents some interesting storage and analysis problems.
At the LANalyzer's default compilation rate of once per second, a ten hour test would create 32,000 records. Since I use Borland's Quattro Pro as my analysis tool, I can only process up to 7,200 records at one time. I assume most AppNote readers will use a similar tool.
The solution to this problem is to decrease the rate at which the LANalyzer samples the board and compiles statistical data records. This effectively reduces the statistical data to a more useable form while maintaining a sufficient level of accuracy. The spreadsheet I've designed to process the WC_NCPC data is built around a 7,200 record data model. This fits easily into any spreadsheet and is obtainable at any test period length that is divisable by two. For example:
|
Test Period |
Sampling Rate |
Record count |
|
2 hr. |
every 1 sec. |
7,200 |
|
4 hr. |
every 2 sec. |
7,200 |
|
10 hr. |
every 5 sec. |
7,200 |
|
12 hr. |
every 6 sec. |
7,200 |
|
24 hr. |
every 12 sec. |
7,200 |
As an example, I used the following LANalyzer data collection settings for a ten hour test period of Laura Maxwell's workstation on June 6th. No trace file is necessary, since the resulting data would quickly fill the disk capacity of the LANalyzer.
Collection Performance: Normal
Trace Slice: Offset: 0 Length: Max
Trace File:
Statistics File: C:\STAT\LAUR0610
Save statistics to file every 5 second(s).
Print screen every 0 minute(s).
Collect transmit statistics: No
With a 7,200 record count, each test created 12 statistics files with the extension .ST1 through .STD (using the hexadecimal numbering system). Processing the LANalyzer data with the LANZSTAT utility resulted in an additional 12 files, for a total of approximately 6MB of disk storage.
Target Addressing. To filter on a single client workstation, determine the workstation's node address and place it in the "rcv" and "xmit" filter patterns described above. For example:
|
Pattern Name: |
rcv |
|
Station: |
XX XX XX XX XX XX -> NOVELL30EB7F |
|
Pattern Name: |
xmit |
|
Station: |
NOVELL30EB7F -> XX XX XX XX XX XX |
Running WC_NCPC. Once you have finished setting triggers, data collection parameters, and target addresses, you're ready to start the application. Because of the way the LANalyzer's triggers operate, you can set up the LANalyzer and start the application up to 24 hours before the start trigger is set to fire. This should allow plenty of time for setup.
Creating and Running WC_NCPS
The application name WC_NCPS stands for "workload characterization of NetWare Core Protocol traffic at a NetWare server." However, WC_NCPS can also be used to characterize entire network segments, a technique covered in the next section of this AppNote.
WC_NCPS is a LANalyzer application that uses the LANalyzer's enhanced filter mode, start and stop triggers, all eight receive channels, and 16 patterns. If you own a LANalyzer, WC_NCPS can easily be created using the following specifications. (See your Novell LANalyzer Reference Manual for instructions on creating, editing, and saving applications.)
Specifications
Receive Channels. The following specifications describe the parameters for eight receive channels, including:
Reads
Writes
Fsearch
OpnCls
Delays
SapRip
Recv
Thrput
The first four channels compute statistics regarding the six most prevelant NCPs mentioned earlier. (This is different than in WC_NCPC because we need to use some of the channels for additional workload types not encountered by workstations.) Since received packets represent service requests, these four channels are designed to track only packets being received by the target server.
The Delays channel records statistics regarding an NCP response packet from server to client called Request Being Processed. The server returns this response to the client when the server receives a duplicate request. This condition usually occurs when the server encounters peak utilization of some sort and must therefore delay processing the client's request. If the delay is long enough, the client's timer can expire and cause the client to send a duplicate request. This resend process is built into the IPX protocol to safeguard against a rare condition in which the initial packet is lost. Most of the time the packet is not lost; it is still being processed by the serverChence the Request Being Processed reply. Tracking these replies along with the other workload statistics is helpful in understanding the frequency and causes of such delays. (For more information, see "Resolving Performance Problems on a NetWare Network," March 1991 NetWare Application Notes.)
The SapRip channel captures statistics regarding all Service Advertising Protocol (SAP) traffic and Router Information Protocol (RIP) traffic both received and transmitted by the server. (For more information, see "NetWare Communications Processes," September 1990 NetWare Application Notes.)
The Recv channel gathers statistics regarding the total packet stream received by the server. The Thrput channel gathers statistics regarding both packets transmitted and received. With these two channels, it's easy to compute the Xmit traffic by subtracting the Xmit totals from the Thrput totals. I use this design because the service request workload is the primary focus on the server. Of course, if I had more channels to work with, I'd probably have a Xmit channel as well as several others. Refer to Figure 10 to set up the channels.
Figure 10: Channel settings for the WC_NCPS application.
Channel 1 Channel 5
Name: Reads Name: Delays
Active: Yes Active: Yes
Size Range From/To: Min/Max Size Range From/To: Min/Max
Packets Allowed: Good Packets Packets Allowed: Good Packets
Collect Stats.: Yes Collect Stats.: Yes
Start Count: Off Start Count: Off
Stop Count: Off Stop Count: Off
Filter patterns: (rcv) AND (read) Filter patterns: (xmit) AND (delays)
Channel 2 Channel 6
Name: Writes Name: SapRip
Active: Yes Active: Yes
Size Range From/To: Min/Max Size Range From/To: Min/Max
Packets Allowed: Good Packets Packets Allowed: Good Packets
Collect Stats.: Yes Collect Stats.: Yes
Start Count: Off Start Count: Off
Stop Count: Off Stop Count: Off
Filter patterns: (rcv) AND (write) Filter patterns: (rcv or xmit) AND
(Skt452 or Skt453)
Channel 3 Channel 7
Name: Fsearch Name: Recv
Active: Yes Active: Yes
Size Range From/To: Min/Max Size Range From/To: Min/Max
Packets Allowed: Good Packets Packets Allowed: Good Packets
Collect Stats.: Yes Collect Stats.: Yes
Start Count: Off Start Count: Off
Stop Count: Off Stop Count: Off
Filter patterns: (rcv) AND (fsearchc Filter patterns: (rcv)
or fsearchi)
Channel 4 Channel 8
Name: OpnCls Name: Thrput
Active: Yes Active: Yes
Size Range From/To: Min/Max Size Range From/To: Min/Max
Packets Allowed: Good Packets Packets Allowed: Good Packets
Collect Stats.: Yes Collect Stats.: Yes
Start Count: Off Start Count: Off
Stop Count: Off Stop Count: Off
Filter patterns: (rcv) AND (open Filter patterns: (xmit or rcv)
or opennew or close)
Filter Pattern Template. The NetWare template used with all of the filter patterns is supplied with the LANalyzer software.
|
Template Search Path: |
C:\XLN\LANZ\TEMPLATE |
|
|
Pattern |
Template |
Overriding Offset |
|
rcv |
NetWare |
None |
|
xmit |
NetWare |
None |
|
open |
NetWare |
None |
|
opennew |
NetWare |
None |
|
close |
NetWare |
None |
|
read |
NetWare |
None |
|
write |
NetWare |
None |
|
fsearchc |
NetWare |
None |
|
fsearchi |
NetWare |
None |
|
delays |
NetWare |
None |
|
Skt452 |
NetWare |
None |
|
Skt453 |
NetWare |
None |
Filter Patterns. In the pattern descriptions shown in Figure 11, I've used the Ethernet address NOVELL30EB7F as an example target address. Before running WC_NCPS on your network, you'll have to fill in a new target address.
The word "None" means the same thing as "Don't care" in the LANalyzer Reference Manual. "Req Type" and "Function Code" refer to fields within the filter pattern template.
Figure 11: Filter patterns for the WC_NCPS application.
|
Pattern Name: |
rcv |
|
Station: |
XX XX XX XX XX XX -> NOVELL30EB7F |
|
Type: |
None |
|
Data: |
None |
|
Pattern Name: |
xmit |
|
Station: |
NOVELL30EB7F -> XX XX XX XX XX XX |
|
Type: |
None |
|
Data: |
None |
|
Pattern Name: |
read |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 72 |
|
Pattern Name: |
write |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 73 |
|
Pattern Name: |
fsearchc |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 63 |
|
Pattern Name: |
fsearchi |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 62 |
|
Pattern Name: |
open |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 65 |
|
Pattern Name: |
opennew |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 76 |
|
Pattern Name: |
close |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:2222Function Code: 66 |
|
Pattern Name: |
delays |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Req Type:9999 |
|
Pattern Name: |
Skt452 |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Dest Socket:0452 |
|
Pattern Name: |
Skt453 |
|
Station: |
None |
|
Type: |
None |
|
Data: |
Dest Socket: 0453 |
Operating Instructions
Trigger Setup. For comparative purposes based on time of day and length of test, you should always run WC_NCPS with triggers. LANalyzer users will recognize the following lines from the LANalyzer's trigger parameters screen. These settings use for an example a test period of 12 hours, from 6am to 6pm.
Start collecting at 06:00:00 hrs. or no other trigger.
Fire stop trigger at 18:00:00 hrs. or no other trigger.
Once stop trigger has fired, collect an additional 0 packets.
When the trace buffer is full, overwrite old packets.
Data Collection Setup. Due to the extended length of most workload characterization tests, the resulting mountain of information presents some interesting storage and analysis problems.
The LANalyzer's default rate of statistical compilation is once per second. At this rate, a ten hour test would create 32,000 records. Since I use Borland's Quattro Pro as my analysis tool, I can only process up to 7,200 records at one time. I assume that most AppNote readers will use a similar tool.
The solution to this problem is to decrease the rate at which the LANalyzer samples the board and compiles statistical data records. This effectively reduces the statistical data to a more useable form while keeping a sufficient level of accuracy. The spreadsheet I've designed to process the WC_NCPS data is built around a 7,200 record data model. This fits easily into any spreadsheet and is obtainable at any test period length that is divisable by two. For example:
|
Test Period |
Sampling Rate |
Record count |
|
2 hr. |
every 1 sec. |
7,200 |
|
4 hr. |
every 2 sec. |
7,200 |
|
10 hr. |
every 5 sec. |
7,200 |
|
12 hr. |
every 6 sec. |
7,200 |
|
24 hr. |
every 12 sec. |
7,200 |
The following LANalyzer data collection settings are for a twelve hour test period of the LEGAL server on June 6th. No trace file is necessary, since the resulting data would quickly fill the disk capacity of the LANalyzer.
Collection Performance: Normal
Trace Slice: Offset: 0 Length: Max
Trace File:
Statistics File: C:\STAT\LGL0610
Save statistics to file every 6 second(s).
Print screen every 0 minute(s).
Collect transmit statistics: No
With a 7,200 record count, each test will create 12 statistics files with the extension .ST1 through .STD (using the hexadecimal numbering system). Processing the LANalyzer data with the LANZSTAT utility results in an additional 12 files, making a total of approximately 6MB of disk storage.
Target Addressing. To filter on a single server, determine the server's node address and place it in the "rcv" and "xmit" filter patterns described above.
|
Pattern Name: |
rcv |
|
Station: |
XX XX XX XX XX XX -> NOVELL30EB7F |
|
Pattern Name: |
xmit |
|
Station: |
NOVELL30EB7F -> XX XX XX XX XX XX |
Running WC_NCPS. Once you have finished setting triggers, data collection parameters, and target addresses, you're ready to start the application. Because of the way the LANalyzer's triggers operate, you can set up the LANalyzer and start the application up to 24 hours before the start trigger is set to fire. This should allow plenty of time for setup.
Characterizing NetWare Segments Using WC_NCPS
Using WC_NCPS to characterize entire network segments is easy to do. The benefits of segment characterization include:
the ability to track segment workload averages, peaks, and growth trends for capacity planning purposes; and
the ability to locate under utilized segments that can be consolidated with other segments, thereby simplifying network management processes.
Operating Instructions
Set up WC_NCPS using the directions given above, except clear the target server addresses to eliminate all address-related filtering. Then run WC_NCPS using the instructions above. Your data will reflect the total workload on the attached segment rather than that of an isolated server.
Converting the Data
Before you can effectively analyze your LANalyzer statistical data, you must convert it into a useable form. LANZSTAT.EXE is a utility program provided with the LANalyzer software that converts LANalyzer statistics files into spreadsheet-compatible files. LANZSTAT creates the following files:
OUTPUT.TSU Test summary statistics
OUTPUT.GSU Global counter summary
OUTPUT.CSU Channel counter summary
OUTPUT.SMP Sample numbers and timestamps
OUTPUT.CH1 Channel 1 counters
OUTPUT.CH2 Channel 2 counters
OUTPUT.CH3 Channel 3 counters
OUTPUT.CH4 Channel 4 counters
OUTPUT.CH5 Channel 5 counters
OUTPUT.CH6 Channel 6 counters
OUTPUT.CH7 Channel 7 counters
OUTPUT.CH8 Channel 8 counters
OUTPUT.TRX Transmit counters
STATNAME.TXT Primary name of the output files
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.