Author: Neftaly Malatjie

The following are factors that affect LAN response time;

 

1. Bandwidth of transmission line

A network has a finite amount of bandwidth, and if there are too many devices or applications connected to the network, they compete for the available bandwidth, resulting in slow data speeds and overall poor performance. Many routers offer dual-band or tri-band technology, which frees up bandwidth by offering multiple channels for spreading the workload. The more people in an office utilizing a LAN network at the same time, the more bandwidth is needed. 

2. Queuing at notes or hosts

Network congestion in data networking and queuing theory is the reduced quality of service that occurs when a network node is carrying more data than it can handle. Typical effects include queuing delay, packet loss or the blocking of new connections. A consequence of congestion is that an incremental increase in offered load leads either only to a small increase or even a decrease in network throughput.

Network protocols that use aggressive retransmissions to compensate for packet loss due to congestion can increase congestion, even after the initial load has been reduced to a level that would not normally have induced network congestion. Such networks exhibit two stable states under the same level of load. The stable state with low throughput is known as congestive collapse.

All the links on a network are joined together by routers. These forward packets arriving on incoming links to the appropriate outgoing links, to ensure that the packet is routed to its intended destination. Figure 1 shows the basic architecture of a router.

The router is connected to   incoming links and   outgoing links.   and   may be different, although   usually equals  . In most situations, input and output links are paired to form either a full-duplex channel where data can flow in both directions simultaneously, or a half-duplex channel where data can flow in only one direction at a time.

Incoming packets are buffered in the input buffers. Once in the buffer, they are selected by the Packet Selection Function to be passed to the Routing Function. The Routing Function determines on to which outgoing link a packet must be placed for it to get closer to its destination: this is done with a routing table which, as described earlier, is semi-static. When the correct link for the packet is found, the Routing Function passes the packet to the Packet Dropping Function for queuing on the output buffer for the link. When the packet reaches the other end of the queue, it is transmitted over the link to the next router, or to the final destination.

The Packet Selection Function can choose any of the packets queued in the input buffers for routing by the Routing Function. Normally this would be done in a First-In First-Out method, but other selection methods may be useful in a congested environment.

There are two fundamental bottlenecks in the given router architecture. Firstly, there is a minimum time needed for the router to decode the network header of the

Packet, determine the route for the packet, and pass the packet to an outgoing link for transmission. There is also a delay for the packet to be transmitted on the outgoing link: this may just be the packet’s transmission time for a full-duplex link, or there may be an extra delay for the link to become clear on a half-duplex link. These delays form one bottleneck.

The second bottleneck indicates that the router must be prepared to buffer output packets, to prevent them from being lost while the router waits for an outgoing link to become clear. The two bottlenecks together indicate that the router must buffer incoming packets, to prevent them from being lost if they arrive too quickly for the router to process.

By definition, the router’s input and output buffers are finite. If a buffer becomes full, then no more packets can be queued in the buffer, and the router has no choice but to discard them. This causes data loss in the data flow between a source and destination, and usually causes the source to retransmit the data.

Although a router cannot queue a packet if the corresponding output buffer is full, it can choose either to discard the unqueued packet, or to discard a packet already in the output queue, and then queue the unqueued packet. This choice is performed by the Packet Dropping Function. This cannot be done for the input buffers, as the packet has not been placed in the router’s internal memory until it has been queued in the input buffers. Thus, packets may be lost on input, and the router has no control over which packets are lost.

Finally, the router’s buffers may share a common memory space, or they may have individual memory spaces. With the former, no buffer can become full until the router’s entire memory space is allocated to buffers, at which point all buffers become full. With the latter, any buffer’s utilisation has no influence on any other buffer’s utilisation.

When LANs had only a few users, performance was usually very good. Today, however, when most computers in an organization are on LANs, performance can be a problem. Performance is usually expressed in terms of throughput (the total amount of user data transmitted in a given time period). In this section, we discuss how to improve throughput. We focus on dedicated-server networks because they are the most commonly used type of LANs, but many of these concepts also apply to peer-to-peer networks.

To improve performance, you must locate the bottleneck, the part of the network that is restricting the data flow. Generally speaking, the bottleneck will lie in one of two places. The first is the network server. In this case, the client computers have no difficulty sending requests to the network server, but the server lacks sufficient capacity to process all the requests it receives in a timely manner. The second location is the network circuit, connecting the LAN to the corporate BN. In this case, the server can easily process all the client requests it receives, but the circuit lacks enough capacity to transmit all the requests to the server. It is also possible that the bottleneck could lie in the client computers themselves (e.g., they are receiving data too fast for them to process it), but this is extremely unlikely—unless, of course, you are still using old computers!

The first step in improving performance, therefore, is to identify whether the bottleneck lies in the circuit or the server. To do so, you simply watch the utilization of the server during periods of poor performance. If the server utilization is high (e.g., 60 to 100 percent), then the bottleneck is the server; it cannot process all the requests it receives in a timely manner. If the server utilization is low during periods of poor performance (e.g., 10 to 40 percent), then the problem lies with the network circuit; the circuit cannot transmit requests to the server as quickly as necessary. Things become more difficult if utilization is in the midrange (e.g., 40 to 60 percent). This suggests that the bottleneck may shift between the server and the circuit depending on the type of request, and it suggests that both should be upgraded to provide the best performance.

On completion of this section you will be able to explain local area computer network performance issues. 

1. The explanation describes a range of factors that affects response times on a LAN. 
2. The explanation outlines the need to analyse data and identify problems. 
3. The explanation outlines how diagnostic tools are used to collect data. 
4. The explanation outlines and compares methods for improving the performance with respect to their effect on performance. 

User audit trails can usually log:

     –    All commands directly initiated by the user;

     –    All identification and authentication attempts; and

     –    Files and resources accessed.

It is most useful if options and parameters are also recorded from commands.  It is much more useful to know that a user tried to delete a log file (e.g., to hide unauthorized actions) than to know the user merely issued the delete command, possibly for a personal data file.

System-level audit trails may not be able to track and log events within applications, or may not be able to provide the level of detail needed by application or data owners, the system administrator, or the computer security manager.  In general, application-level audit trails monitor and log user activities, including data files opened and closed, specific actions, such as reading, editing, and deleting records or fields, and printing reports.  Some applications may be sensitive enough from a data availability, confidentiality, and/or integrity perspective that a “before” and “after” picture of each modified record (or the data element(s) changed within a record) should be captured by the audit trail.