 |
» |
|
|
|
This section gives the system manager some tips for creating a valid network configuration file that will work well in your environment. The topics in this section include: Entering IP addresses correctly Setting appropriate poll intervals Using I/O timing effectively
Entering a numeric IP address correctly | |
For each network printer you are configuring, you must enter in the NPCONFIG file the printer's TCP/IP network domain name or its IP address in the form aaa.bbb.ccc.ddd. If you enter the IP address, each field must have a value that is less than or equal to decimal 255. The numeric base of each field in the IP address is then determined individually as follows: If the field begins with "0x", the remainder of the field is (case-insensitive) hexadecimal. If the field begins with a leading zero followed by 0 through 7 inclusive, the remainder of the field is octal. A field beginning with "0<anything else>" is an error. If the field begins with [1-9], the entire field is treated as decimal. To specify a decimal IP address, do not use leading zeros.
Listed below is one valid IP address expressed in many possible forms:
10.13.194.150 all decimal
012.015.0302.0226 all octal
0xA.0xd.0xC2.0x96 all (case-insensitive) hex
10.015.0xc2.150 mixed
|
These are invalid IP address specifications:
10.13 Only two fields, four required
abc.def.ghi.jkl Non-numeric, may be a domain name
10.018.194.150 "8" is not an octal digit
10.0b.194.150 "0b" is also an invalid octal spec
10.0xUsoft.194.150 "Usoft" is not valid hex
10.0xDEC.194.150 Valid hex, but > 255 decimal
10.def.ghi.jkl Can't mix IP address, domain name
|
Setting appropriate poll intervals | |
At a given time, only one host can be connected to a network printer and others must wait until the printer is available. If the spooler has a spool file to print, and either the network or the printer are unavailable, it may need to attempt connecting to the printer many times before it finally succeeds. You may configure the length of time between retries by defining values for the poll_interval and poll_interval_max items. You must decide whether the default value for poll_interval (10 seconds) gives the host an unfair advantage or disadvantage over other competing host systems and, if so, specify a more appropriate value. For example, if poll_interval is long compared with other hosts, then those hosts stand a better chance of attaching the printer than this host. If the interval is comparatively short, other hosts may not be able to gain access to a network printer. However, if the interval is too short, this host may consume excessive CPU time doing the polling. The spooler uses the combination of values set by poll_interval and poll_interval_max to determine the polling cycle on an unavailable network printer. For example, if poll_interval = 10 while the absolute value of poll_interval_max is 60, a sequence of unsuccessful connection attempts would wait 10, 12.5, 15.6, 19.5, ... 59.6, 60, 60, 60... seconds between each successive attempt. Once the connection has been made, the next failed connection starts at poll_interval once more. If poll_interval_max is less than 0, a message is displayed to the console whenever this limit is reached. If it is greater than or equal to 0, no message is displayed. At first glance this behavior may seem counter-intuitive. If a network connection fails using a short interval, its chances of success appear to decrease as the interval increases. This is, in fact, the case, but there are situations for which this may be desirable. One example might be a network connection which must pass through many routers or other interfaces, any of which can fail. Or the network itself may be down. Repeatedly trying to establish a connection using a small poll_interval under these conditions wastes
local resources as well as unnecessarily increasing network traffic. If situations like this do not arise in your environment, you may omit poll_interval_max. Successive connection attempts are then all separated by poll_interval seconds. Using I/O timing effectively | |
Four I/O timing items that you may enter into the NPCONFIG file control the frequency of status checking for network printers. They are: The default values for these items are suitable for text-based reports
sent to a printer such as the LaserJet 4Si, which is separated from the HP 3000 by a small number of network devices (routers, bridges, etc.). If the printer is located at a remote site, or the data is more complex, you may want to enter a larger value to avoid excessive checking cycles. A low value (more frequent checking) causes any problem to be detected sooner, but substantially increases the use of CPU and network resources if normal I/O has not completed within that interval. The remainder of this section describes two scenarios to suggest how you might set the I/O timing items to best manage some typical network printing problems. In this scenario, suppose that each I/O requires 15 seconds to complete. Assume that none of the I/O timing items are specified in NPCONFIG, which means that all default values are used. For reference, those values are: data_timeout = 10 seconds
- Condition
Result - Output is printer bound
The data_timeout, which is set for 10 seconds, expires and the spooler issues an SNMP request to verify that the printer is on line. The SNMP request completes before snmp_timeout expires, and reports that the printer is online. The spooler therefore, restarts the data_timeout interval. The I/O completes five seconds later, 15 seconds from when it started. This scenario requires one SNMP request per data I/O request, and is therefore very wasteful of CPU and network bandwidth. For better efficiency, data_timeout should be reconfigured to a higher value, perhaps 20 seconds. - The printer is offline
The data_timeout timer expires and the ensuing SNMP request completes normally. No SNMP retries are required, so a "device offline" message is displayed. Because message_interval = 0, this message is not repeated, although the spooler continues to cycle through data_timeout and SNMP requests until the printer is placed online again. Suppose that after displaying the "device offline" message, a subsequent SNMP request times out three times. This is a different condition than "device offline", and so an appropriate message is displayed for it. Again, the second message is only displayed once because message_interval = 0. However, if subsequent SNMP requests complete normally, the "device offline" message is different from the SNMP timeout message, and so is displayed again, once. - The network is slow
Suppose that the first cycle completes: data_timeout expires and snmp_timeout expires. On the second cycle, data_timeout expires, but this time the SNMP request completes properly and verifies that the printer is on line. Since the spooler did not retry the required three times, the retry counter is reset and no message is displayed. If, instead, the network does not respond, the third snmp_timeout expires and an appropriate "network problem" message is displayed once. With the above item values, the message appears 45 seconds after the write operation to the printer (3 * (10 + 5)).
In this scenario, suppose that each I/O requires 15 seconds to complete, and that the I/O timing items have been set to the following values in NPCONFIG: data_timeout = 20 seconds
- Condition
Result - Output is printer bound
Since the I/O completes within the required 20 seconds, no further checking is performed. - The printer is offline
The data_timeout expires. The ensuing SNMP request completes normally, reporting the offline condition. An appropriate message is displayed and another data_timeout cycle begins. When it expires, the SNMP request is repeated. Twenty seconds have elapsed since the last message, which exceeds message_interval, so the offline message is displayed again, and continues to be displayed every 20 seconds as long as the offline condition persists. - The network does not respond
The spooler cycles continuously between data_timeout and snmp_timeout but displays no message, because the network problem appears as a non-response to the SNMP request and snmp_max_retries is 0.
|
