Experimental Evaluation of SunOS IPC and TCP/IP Protocol
Implementation 1
Computer and Communications Research Center
Department of Computer Science
Washington University St. Louis MO 63130-4899
Gurudatta M. Parulkar
guru@https://www.doczj.com/doc/287497342.html, (314) 935-4621
Christos Papadopoulos
christos@https://www.doczj.com/doc/287497342.html,
(314) 935-4163
net segment via the AMD Am7990LANCE Ethernet Con-troller.Occasionally two Sparcstation 2workstations running SunOS 4.1were also used in the experiments.However,only SunOS 4.0.3IPC could be studied in depth due to the lack of source code for SunOS 4.1.
2. Unix Inter-Process Communication (IPC)
In 4.3BSD Unix,IPC is organized into 3layers.The ?rst layer,the socket layer,is the IPC interface to applica-tions and supports different types of sockets each type pro-viding different communication semantics (for example,STREAM or DATAGRAM sockets).The second layer is the protocol layer,which contains protocols supporting the dif-ferent types of sockets.These protocols are grouped in
domains,for example the TCP and IP protocols are part of the Internet domain.The third layer is the network interface layer,which contains the hardware device drivers (for example the Ethernet device driver).Each socket has bounded send and receive buffers associated with it,which are used to hold data for transmission to,or data received from another process.These buffers reside in kernel space,and for ?exibility and performance reasons they are not contiguous.The special requirements of interprocess com-munication and network protocols require fast allocation and deallocation of both ?xed and variable size memory blocks.Therefore,IPC in BSD 4.3uses a memory manage-ment scheme based on data structures called MBUFs (Memory BUFfers).Mbufs are ?xed size memory blocks 128bytes long that can store up to 112bytes of data.A vari-ant mbuf,called a cluster mbuf is also available,in which data is stored externally in a page 1024bytes long,associ-
copied from user space into mbufs,which are linked together if necessary to form a chain.All further protocol processing is performed on mbufs.
2.1 Queueing Model
Figure 1shows the data distribution into mbufs at the sending side.In the beginning,data resides in application space in contiguous buffer space.Then data is copied into mbufs in response to a user send request,and queued in the socket buffer until the protocol is ready to transmit it.In the case of TCP or any other protocol providing reliable deliv-ery,data is queued in this buffer until acknowledged.The protocol retrieves data equal to the size of available buffer-ing minus the unacknowledged data,breaks the data in packets,and after adding the appropriate headers passes packets to the network interface for transmission.Packets in the network interface are queued until the driver is able to transmit them.On the receiving side,after packets arrive at the network interface,the Ethernet header is stripped and the remaining packet is appended to the protocol receive queue.The protocol,noti?ed via a software interrupt,wakes up and processes packets,passing them to higher layer protocols if necessary.The top layer protocol after processing the packets,appends them to the receive socket queue and wakes up the application.The four queueing points identi?ed above are depicted in Figure 2.A more comprehensive discussion of IPC and the queueing model
can be found in [8].
3. Probe Design
To monitor the activity of each queue,probes were inserted in the SunOS Unix network code at the locations shown in Figure2.A probe is a small code segment placed at strategic locations in the kernel.Each probe when acti-vated records a timestamp and the amount of data passing through its checkpoint.It also?lls a?eld to identify itself. The information recorded is minimal,but can nevertheless provide valuable insight into queue behavior.For example, the timestamp differentials can provide queue delay,queue length,arrival rate and departure rate.The data length can provide throughput measurements,and help identify where and how data is fragmented into packets.
At the sending side,probes1and2monitor the sending activity at the socket layer.The records produced by probe 2alone,show how data is broken up into transmission requests.The records produced by probes1and2together, can be used to plot queue delay and queue length graphs for the socket queue.Probe3monitors the rate packets reach the interface queue.This rate is essentially the rate packets are processed by the protocol.Probe3monitors the win-dowing and congestion avoidance mechanisms by record-ing the bursts of packets produced by the protocol.The protocol processing delay can be obtained by the inter-packet gap during a burst.The interface queue delay is given as the difference in timestamps between probes3and 4.The queue length can also be obtained from probes3and 4, as the difference in packets logged by each probe.
At the receiving side,probes5and6monitor the IP queue,measuring queue delay and length.The rate at which packets are removed from this queue is a measure of how fast the protocol layer can process packets.The rate packets arrive from the Ethernet,is strongly dependent on Ethernet load,can be determined using probe5.The differ-ence in timestamps between probes6and7give the proto-col processing delay.Probes7and8monitor the socket queue delay and length.Packets arrive in this queue after the protocol has processed them and depart from the queue as they are copied to the application space.
The probes can also monitor acknowledgments.If the data?ow is in one direction,the packets received by the sender of data will be acknowledgments.Each application has all8probes running,monitoring both incoming and outgoing packets.Therefore,in one-way communication probes at the lower layers record acknowledgments.
3.1 Probe Overhead
An issue of vital importance is that probes incur as little overhead as possible.There are three sources of potential overhead:(1)due to probe execution time;(2)due to the recording of measurements;and(3)due to probe activation (i.e. deciding when to log).
To address the?rst source of overhead,any kind of pro-cessing in the probes besides logging a few important parameters was precluded.To address the second source,it was decided that probes should store records in the kernel virtual space in a static circular list of linked records,ini-tialized during system start-up.The records are accessed via global head and tail pointers.A user program extracts the data and resets the list pointers at the end of each exper-iment.The third source of overhead,probe activation,was addressed by introducing a new socket option that the socket and protocol layer probes can readily examine.For the network layer probes,a bit in the“tos”(type of service)?eld of the IP header in the outgoing packets was set.The network layer is able to access this?eld easily because the IP header is always contained in the?rst mbuf of the chain either handed down by the protocol,or up by the driver. This is a non-standard approach,and it does violate layer-ing,but it has the advantage of incurring minimum over-head and is straightforward to incorporate.
4. Performance of IPC
This section presents some experiments aimed at char-acterizing performance of various components of IPC, including the underlying TCP/IP protocols.To minimize interference from users and the network,the experiments were performed with one user on the machines(but still in multi-user mode),and the Ethernet was monitored using either Sun’s traf?c or xenetload,which are tools capable of displaying the Ethernet utilization.With the aid of these tools it was ensured that background Ethernet traf?c was low(less than5%)during the experiments.Moreover,the experiments were repeated several times in order to reduce the degree of randomness inherent to experiments of this nature.
4.1 Experiment 1: Throughput
This experiment has two parts.In the?rst,the effect of the socket buffer size on throughput is measured when set-ting up a unidirectional connection and sending a large amount of data(about10Mbytes or more)over the Ether-net.The results show that throughput increases as socket buffers are increased,with rates up to7.5Mbps achievable when the buffers are set to their maximum size(approxi-mately51kilobytes).This suggests that it is bene?cial to increase the default socket buffer size(which is4kilobytes) for applications running on the Ethernet,and by extrapola-
tion,for applications that will be running on faster net-works in the future.The largest increase in throughput was achieved by quadrupling the socket buffers(to16kilo-bytes),followed by some smaller subsequent improve-ments as the buffer got larger.
In the second part of the experiment,the results of the ?rst part are compared to the results obtained when the two processes exchanging data reside on the same machine. This setup bypasses completely the network layer,with packets from the protocol output looped back to the proto-col input queue.Despite the fact that a single machine han-dles both transmission and reception,the best observed local IPC throughput was close to9Mbps,suggesting that the mechanism is capable of exceeding the Ethernet rate. However,as the previous part showed,the best observed throughput across the Ethernet was only7.5Mbps,which is only75%of the theoretical Ethernet throughput.The bottleneck was traced to the network driver which could not sustain rates higher than7.5Mbps.The actual results of this experiment can be found in [8].
Increasing the socket buffer size can be bene?cial in other ways too:the minimum of the socket buffer size is the maximum window TCP can use.Therefore,with the default size the window cannot exceed4096bytes(which corresponds to4packets).On the receiving end the proto-col can receive only four packets with every window which leads to a kind of stop-and-wait protocol2with four seg-ments.Another potential problem is that the use of small buffers leads to a signi?cant increase in acknowledgment traf?c,since at least one acknowledgment for every win-dow is required.The number of acknowledgments gener-ated with4K buffers was measured using the probes,and was found to be roughly double the number with maximum size buffers.Thus,more protocol processing is required to process the extra acknowledgments,possibly contributing to the lower performance obtained with the default socket buffer size.In light of the above observations,all subse-quent experiments were performed with the maximum allowable socket buffer size.
4.2 Experiment 2: Investigating IPC with Probes
For this experiment the developed probing mechanism is used to get a better understanding of the behavior of IPC. The experiment has two parts:the?rst consists of setting up a connection and sending data as fast as possible in one direction.The data size used was256KB.In the second part,a unidirectional connection is set up again,but now
sure the packet delay at each layer.
For the?rst part,the graphs presented were selected to show patterns that were consistent during the measure-ments.Only experiments during which there were no retransmissions were considered,in order to study the pro-tocols at their best.The results are presented in four sets of graphs:the?rst is a packet trace of the connection;the sec-ond is the length of the four queues vs.elapsed time;the third is the delay in the queues vs.elapsed time;and the last is the protocol processing delay.
The graphs in Figure3show the packet traces as given by probes3,4,7and8.Probes3and4are on the sending side.The?rst probe monitors the protocol output to the net-work interface and the second monitors the network driver output to the Ethernet.Probes7and8are on the receiving side and monitor the receiving socket input and output respectively.The graphs show elapsed time on the x-axis and the packet number on the y-axis.The packet number can also be thought as a measure of the packet sequence number since for this experiment all packets carried1kilo-byte of data.Each packet is represented by a vertical bar to provide a visual indication of packet activity.For the sender the clock starts ticking when the?rst SYN packet is trans-mitted,and for the receiver when this SYN packet is received.The offset introduced is less than1ms and does not affect the results in a signi?cant manner.
data and waits for an acknowledgment before sending the next packet.
Examining the?rst graph(protocol output)in the set reveals the transmission burstiness introduced by the win-dowing mechanism.The blank areas in the graph represent periods the protocol is idle awaiting acknowledgment of outstanding data.The dark areas represent the period the protocol is sending out a new window of data(the dark areas contain a much higher concentration of packets).The last two isolated packets are the FIN and FIN_ACK packets that close the connection.The second graph(interface out-put)is a trace of packets?owing to the Ethernet.It is imme-diately apparent that there is a degree of“smoothing”to the ?ow as packets move from the protocol out to the network. Even though the protocol produces bursts,when packets reach the Ethernet these bursts are dampened considerably, resulting in a much lower rate of packets on the Ethernet. The reason is that the protocol is able to produce packets faster than the network can transmit,which leads to queu-ing at the interface queue.
On the receiving side,the trace of packets into the receive socket buffer appears to be similar to the trace pro-duced by the sender,meaning that there is no signi?cant queueing delay introduced by the network or the IP queue. This also indicates that the receive side of the protocol is able to process packets at the rate they arrive,which is not surprising since this rate was reduced by the network(to approximately a packet every millisecond).This lower rate is possibly a key reason why the IP queue remains small. The output of the receive socket appears similar to the input to the socket buffer.Note however,that there is a noticeable idle period,which seems to propagate back to the other traces.The source for this is explained after examining the queue length graphs, next.
The set of graphs in Figure4shows the queue length at the various queues as a function of time(note the difference in scale of the y-axis).The queue length is shown as the number of bytes in the queue instead of packets for the sake of consistency,since in the socket layer at the sending side there is no real division of data into packets.Data is frag-mented into packets at the protocol layer.The sending socket queue length is shown to monotonically decrease as expected,but not at a constant rate since the draining of the queue is controlled by the reception of acknowledgments. Note that the point the queue appears to become empty is the point where the last chunk of data is copied into the socket buffer and not when all the data was actually trans-mitted.The data remain in the socket buffer until acknowl-edged.The interface queue shows the packet generation by the protocol.The burstiness in packet generation is imme-diately apparent and manifested as peaks in the queue length.The queue build-up suggested by the packet trace
with every new burst,indicating that each new burst con-tains more packets than the previous one.This is attributed to the slow start strategy of the congestion control mecha-nism[5].The third graph shows the IP receive queue,and con?rms the earlier hypothesis that the receive side of the protocol can comfortably process packets at the rate deliv-ered by the network.As the graph shows the queue practi-cally never builds up,each packet being removed and processed before the next one arrives.The graph for the receive socket queue shows some queueing activity.It appears that there are durations over which data accumu-lates in the socket buffer,followed by a complete drain of the buffer.During that time the transmitter does not send any data,since no acknowledgment is sent by the receiver. This queue build-up leads to gaps in packet transmission, as witnessed earlier by the packet trace plots.These gaps are a result of the receiver delaying the acknowledgment until data is removed from the socket buffer.
The next set of graphs in Figure5shows the packet delay at the four queues.The x-axis shows the elapsed time and the y-axis the delay.Each packet is again represented as a vertical bar.The position of the bar on the x-axis shows the time the packet entered the queue.The height of the bar shows the delay the packet experienced in the queue.As mentioned earlier,there are no packets in the?rst queue, therefore the?rst(socket queue)graph simply shows the time it takes for data in each write call to pass from the application layer down to the protocol layer.For this exper-iment,there is a single write call,so there is only one entry in the graph.The second graph shows the network interface queue delay.Packets entering an empty queue at the begin-
subsequent packets are queued and thus delayed.The delays range from a few hundred microseconds to several milliseconds.The third graph shows the IP queue delay, which is a measure of how fast the protocol layer can remove and process packets from its input queue.The delay of packets appears very small,with the majority of packets remaining in the queue for about100microseconds.Most of the packets are removed from the queue well before the 1ms interval that it takes for the next packet to arrive.The fourth graph shows the delay at the receive socket queue. Here the delays are much higher.This delay includes the time to copy data from mbufs to user space.Since the receiving process is constantly trying to read new data,this graph is an indication of how often the operating system allows the socket receive process which copies data to user space to run.The fact that there are occasions where data accumulates in the buffer,shows that the process runs at a frequency less than the data arrival.
The two histograms in Figure6show the protocol pro-cessing delay at the send and receive side respectively.For the sending side the delay is assumed to be the packet inter-spersing during a window burst.The reason is that since the protocol fragments transmission requests larger than the maximum protocol segment,there are no well-de?ned boundaries as to where the protocol processing begins for a packet and where it completes.Therefore,packet inter-spersing was deemed more fair to the protocol(the gaps introduced by the windowing mechanism were removed). This problem does not appear at the receiving end where the protocol receives and forwards
distinct packets to the socket layer.The x-axis in the graphs is divided into bins number of packets in each bin.Examining the graphs shows that the protocol delays are different at the two ends: at the sending end processing delay divides the packets into two distinct groups with the?rst,the larger one,requiring about250to400microseconds to process and the second about500-650microseconds.At the receiving end the packet delay is more evenly distributed,and processing takes about250-300microseconds for most packets,with some taking between300and400.Thus,the receiving side is able to process packets faster than the sending side.The average delays for protocol processing are370microsec-onds for the sending side and260microseconds for the receiving side.Thus the theoretical maximum TCP/IP can attain on Sparcstation1’s when the CPU is devoted to com-munication with no data copying(but including checksum) and without the network driver overhead is estimated to be about 22 Mbps.
In the second part of the experiment the delay experi-enced by a single packet moving through the IPC layers is isolated and measured.A problem with the previous mea-surements is that the individual contribution of each layer to the overall delay is hard to assess because layers have to share the CPU for their processing.Moreover,asynchro-nous interrupts due to packet reception or transmission may steal CPU cycles from higher layers.To isolate layer pro-cessing consecutive packets are sent after introducing some arti?cial delay between them.The idea is to give the IPC mechanism enough time to send the current packet and receive an acknowledgment before supplied with the next.
The experiment was set up as follows:the pair of Sparc-station1’s was used again for unidirectional communica-tion.The sending application was modi?ed to send one 1024byte packet and then sleep for one second to allow the packet to reach the destination and the acknowledgment to come back.To ensure that the packet was sent immediately, the TCP_NODELAY option was set.Moreover,both send-ing and receiving socket buffers were set to1kilobyte,thus
effectively reducing TCP to a stop-and-wait protocol.
The results of this experiment are summarized in Table 1,and are compared to the results obtained in the previous experiment,when250kilobytes of data were transmitted. The send socket queue delay shows that a delay of about 280μS is experienced by each packet before reaching the protocol.This includes data copy,which was measured to be about130μS.Therefore,the socket layer processing takes about150μS.This includes locking the buffer,mask-ing network device interrupts,performing various checks, allocating plain and cluster mbufs and calling the protocol. The delay for the sending side has increased by about73μS (443vs.370μS).This is due to the fact that the work required before calling the TCP output function with trans-mission request is replicated with each new packet.Earlier, the TCP output function was called with a large transmis-sion request,and entered a loop forming packets and trans-mitting them until the data was exhausted.The interface queue delay is very small:it takes about40μS for a packet to be removed from the interface queue by the Ethernet driver when the latter is idle.The IP queue delay is also quite small.The delay has not changed signi?cantly from the earlier experiment,when256kilobytes of data were transferred.The protocol layer processing at the receiving end has not changed much from the result obtained in the ?rst part.In this part the delay is253μS,while in part1it was260μS.The receive socket queue delay is about412μS,out of which130will be due to data copy.This means that the per packet overhead is about292μS which is about double the overhead at the sending side.The main source of this appears to be the application wake-up delay.4.3Experiment 3: Effect of Queueing on the
Protocol
The previous experiments have provided insight into the queueing behavior of the IPC mechanism.The experiments established that the TCP/IP layer in SunOS4.0.3running on a Sparcstation1has the potential of exceeding the Ethernet rate.As a result the queue length graphs show that noticeable queueing exists at the sending side(at the net-work interface queue)which limits the rate achieved by the protocol.At the receiving end,queueing at the IP queue is low compared to the other queues because the packet arrival rate is reduced by the Ethernet.However,queueing is observed at the socket layer,showing that packet arrival rate is higher than the rate packets are processed by IPC.In this experiment the effect of the receive socket queueing on the protocol was investigated.
Brie?y,the actions taken at the socket layer for receiving data are as follows:the receive function enters a loop tra-versing the mbuf chain and copying data to the application space.The loop exits when either there is no more data left or the application request is satis?ed.At the end of the copy-loop the protocol user request function is called so that protocol speci?c actions like sending an acknowledg-ment can take place.Thus any delay introduced at the socket queue will delay protocol actions.TCP sends acknowledgments during normal operation when the user removes data from the socket buffer.During normal data transfer(no retransmissions)an acknowledgment is sent if the socket buffer is emptied after removing at least2max-imum segments,or whenever a window update would advance the sender’s window by at least 35 percent3.
The TCP delayed acknowledgment mechanism may also generate acknowledgments.This mechanism works as follows:upon reception of a segment,TCP sets the?ag TF_DELACK in the transmission control block for that connection.Every200mS a timer process runs checking these?ags for all connections.For each connection that has the TF_DELACK?ag set,the timer routine changes it to TF_ACKNOW and the TCP output function is called to send an acknowledgment.TCP uses this mechanism in an effort to minimize both the network traf?c and the sender processing of acknowledgments.The mechanism achieves this by delaying the acknowledgment of received data in hope that the receiver will reply to the sender soon and the acknowledgment will be piggybacked onto the reply seg-ment back to the sender.
Table 1: Delay in IPC Components
b. measured using custom software
To summarize,if there are no retransmissions,TCP may acknowledge data in two ways:(1)whenever(enough)data are removed from the receive socket buffer and the TCP output function is called,and(2)when the delayed ack timer process runs.
To verify the above,the following experiment was per-formed:a unidirectional connection was set up again,but in order to isolate the protocol from the Ethernet the connec-tion was made between processes on a single machine(i.e. using local communication).The data size sent was set to1 Mbyte,and the probes were used to monitor the receive socket queue and the generated acknowledgments.The result is shown in Figure7,which shows the queue length v.s.elapsed time.The expansion of the congestion window can be seen very clearly with each new burst.Each window burst is exactly one segment larger than the previous one. Moreover,the socket queue grows by exactly the window size,and then it drops down to zero,where an acknowledg-ment is generated and a new window of data comes in shortly after.The peaks that appear in the graph are caused by the delayed acknowledgment timer process that runs every200mS.The effect of this timer is to send an acknowledgment before the data in the receive buffer is completely removed,causing more data to arrive before the buffer is emptied.However,during data transfer between different machines more acknowledgments would be gen-erated because the receive buffer becomes empty more often since the receive process is scheduled more often and has more CPU cycles to copy the data.
The experiment shows how processing at the socket layer may slow down the TCP by affecting the acknowl-edgment generation.For a bulk data transfer most acknowl-edgments are generated after the receive buffer becomes empty.If data arrives in fast bursts,or if the receiving machine is slow or loaded,data may accumulate in the socket buffer.If a window mechanism is employed for?ow control as in the case of TCP,the whole window burst may accumulate in the buffer.The window will not be acknowl-edged until the data is passed to the application.Until this happens,TCP will be idle awaiting the reception of new data,which will come only after the receive buffer is empty and the acknowledgment has gone back to the sender.So there may be gaps during data transfer which will be equal to the time to copy out the buffer plus one round trip delay for the acknowledgment and the new data to arrive.
4.4 Experiment 4: Effect of Background Load
The previous experiments have studied the IPC mecha-nism when the machines were solely devoted to communi-cation.However,it would be more useful to know how extra load present on the machine would affect the IPC mechanism.In a distributed environment(especially with single-processor machines),computation and communica-tion will affect each other.This experiment investigates the behavior of the various queues when the host machines are loaded with arti?cial load.The experiment is aimed at determining which parts of the IPC mechanism are affected and how when additional load is present on the machine. The results reported include the effect on throughput and graphs depicting how the various queues are affected by the extra workload during data transfer.
The experiment was performed by setting up a unidirec-tional connection,running the workload,and sending data from one Sparcstation to another.The main requirement for the arti?cial workload was that it be CPU intensive.The assumption is that if a task needs to be distributed,it will most likely be CPU intensive.The chosen workload con-sists of a program that forks a speci?ed number of pro-cesses that calculate prime numbers.For the purposes of this experiment the arti?cial workload level is de?ned to be the number of prime-number processes running at the same time.
Figure8shows the effect of the arti?cial workload on communication throughput when the workload is run on the server machine.The experiment was performed by?rst starting the arti?cial workload and then immediately per-forming a data transfer of5Mbytes.The graph shows that the throughput drops sharply as the number of background processes increases,which suggests that IPC requires a sig-ni?cant amount of CPU cycles.Although not actually mea-sured,the effect on computation also appears signi?cant. Thus when computation and communication compete for CPU cycles they both suffer,leading to poor overall perfor-mance.
Figure8shows the internal queues during data transfer
with a loaded server.For these graphs the data size was reduced to 1Mbyte to keep the size of the graphs reason-able.The workload level is 4,meaning that there were four prime-number processes running.The x-axis shows the elapsed time and the y-axis the queue length.Examining the receive socket queue plot shows that when data arrives at the queue is delayed signi?cantly.The bottleneck is clearly shown to be the application scheduling.The receiv-ing process has to compete for the CPU with the workload
processes,so it is forced to read the data at a lower rate.The extra load seems to affect the IP queue also.In previous experiments with no extra computation load,data would not accumulate in the IP queue.The accumulation however,is still very small compared to the other queues.The inter-face and socket queues on the sending side re?ect the effect introduced by the delay in acknowledging data by the receiver.Although not reported here,note that the effect of loading the client was similar to the effect of loading the server [8].
5. Conclusions
In general,the performance of SunOS 4.0.3IPC on Sparcstation 1over the Ethernet is very good.Experiment 1has shown that average throughput rates of up to 7.5Mbps are achievable.Further investigation has shown that this rate is not limited by the TCP/IP performance,but by the driver performance.Therefore,a better driver imple-mentation will increase throughput further.
Some improvements to the default IPC are still possible.Experiment 1has shown that increasing the default socket buffer size from 4to 16kilobytes or more,leads to a signif-icant improvement in throughput for large data transfers.Note however,that increasing the default socket buffer size necessitates an increase in the limit of the network interface queue size.The queue,shown in Figure 5,holds outgoing packets awaiting transmission.Currently its size is limited to 50packets and with the default buffers guarantees no over?ow for 12simultaneous connections (12connections with a maximum window of 4).If the default socket buffers are increased to 16kilobytes,then the number of connec-tions drops to 3.
The performance of IPC for local processes is estimated to be about 43%of the memory bandwidth.Copying 1kilo-byte takes about 130microseconds,meaning that memory-to-memory copy is about 63Mbps.Local IPC requires two copies and two checksums.Assuming that the checksum takes about half the cycles as memory copy (only reading the data is required),the maximum theoretical limit of local IPC is 63/3=21Mbps.The IPC performance measured was close to 9Mbps which is about 43%of the memory bandwidth.When processes running on different machines,the sending side of IPC is able to process packets faster than the Ethernet rate,which leads to queueing at the net-work interface queue.At the receiving side,the network and protocol layers are able to process packets as they arrive.At the socket layer however,packets are queued before delivered to the application.In both local and remote communication,the performance of TCP/IP is determined by protocol processing and checksum.Ignoring the data
Figure 8:Throughput v.s.server background
load
2
46
8
10
1.02.03.04.05.06.07.0t h r o u g h p u t (M b p s )
workload
3
Figure 9: Queue length v.s server
background load
012100200300
Send Socket Queue
012
310
20
3040l e n g t h (k i l o b y t e s )
Network Send Queue 0123
elapsed time (sec)
1
2
345IP Receive Queue
0123
20
40
60
Receive Socket Queue
copy,this was measured to be about22Mbps and is limited by the sending side.
While transferring large amounts of data,TCP relies on the socket layer for a noti?cation that the application received the data before sending acknowledgments.The socket layer noti?es TCP after all data has been removed from the socket buffer.This introduces a delay in receiving new data which is equal to the time to copy the data to application space plus one round trip time to send the acknowledgment and the new data to arrive.This is a small problem on the current implementation where the socket queues are small,but may be signi?cant in future high bandwidth-delay networks where queues may be very large.Experiments3and4show that queueing at the receive socket queue can grow to?ll the socket buffer, especially if the machine is loaded.This reduction in acknowledgments could degrade the performance of TCP especially during congestion window opening or after a packet loss.The situation will be exacerbated if the TCP large windows extension is implemented.The congestion window opens only after receiving acknowledgments, which may not be generated fast enough to open the win-dow quickly,resulting in the slow-start mechanism becom-ing too slow.
The interaction of computation and communication is signi?cant.Experiment4has shown that the additional load on the machine dramatically affects communication. The throughput graphs show a sharp decrease in through-put as CPU contention increases which means that IPC requires a major portion of the CPU cycles to sustain high Ethernet utilization.Even though machines with higher computational power are expected to become available in the future,network speeds are expected to scale even faster. Moreover,some of these cycles will not be easy to elimi-nate.For example TCP calculates the checksum twice for every packet,once at the sending and once at the receiving end of the protocol.The fact that in TCP the checksum resides in the header and not at the end of the packer means that this time consuming operation cannot be performed using hardware that calculates the checksum and appends it to the packet as data is sent to,or arrives from the net-work.Conversely,the presence of communication affects computation by stealing CPU cycles from computation. The policy of favoring short processes adopted by the Unix scheduling mechanism allows the communication pro-cesses to run at the expense of computation.This schedul-ing policy makes communication and computation performance unpredictable in the Unix environment.
Some areas of weakness have already been identi?ed with existing TCP for high speed networks,and extensions to TCP were proposed to address them[6].The extensions are:(1)use of larger windows(greater that TCP’s current maximum of65536bytes)to?ll a high speed pipe end-to-end;(2)ability to send selective acknowledgments to avoid retransmission of the entire window;(3)and inclusion of timestamps for better round trip time estimation[7].We and other groups are currently evaluating these options. However,one may question the suitability of TCP’s point-to-point100%reliable byte stream interface for multi par-ticipant collaborative applications with multimedia streams.Additionally,if more and more underlying net-works support statistical reservations for high bandwidth real time applications,TCP’s pessimistic congestion con-trol will have to be reconsidered.
References
[1] Beirsack, E.W. and Feldmeier, D. C., ‘‘A Timer-Based Con-
nection Management Protocol with Synchronized Clocks
and its Veri?cation,’’ Computer Networks and ISDN Sys-
tems, to appear.
[2] Chesson, Greg, ‘‘XTP/PE Design Considerations’’, IFIP
WG6.1/6.4 Workshop on Protocols for High Speed Net-
works, May 1989, reprinted as: Protocol Engines, Inc.,
PEI~90-4, Santa Barbara, Calif., 1990.
[3]Comer,Douglas,Internetworking with TCP/IP,Prentice Hall,
Inc., Englewood Cliffs, New Jersey, 1991.
[4] D. D. Clark, V. Jacobson, J. Romkey, and H. Salwen, “An
analysis of TCP processing overhead”, IEEE Communica-
tions Magazine, V ol. 27, No. 6, Jume, 1989, pp. 23-29. [5] Jackobson, Van, “Congestion Avoidance and Control”,Sig-
Comm ‘88, Symp., ACM, Aug. 1988, pp. 314-329.
[6] Jacobson, V., Braden, R.T. and Zhang, L., “TCP extensions
for high-speed paths”, RFC 1185, 1990.
[7] Nicholson, Andy, Golio, Joe, Borman, David, Young, Jeff,
Roiger,Wayne,“High Speed Networking at Cray Research,”
ACM SIGCOMM Computer Communication Review, V ol-ume 2, Number 1, pages: 99-110.
[8] Papadopoulos, Christos, “Remote Visualization on Campus
Network,” MS Thesis, Department of Computer Science,
Washington University in St. Louis, 1992.
[9] J. Postel, “Internet Protocol-DARPA Internet program proto-
col speci?cation”, Inform. Sci. Inst., Rep. RFC 791, Sept.
1981.
[10] J. Postel, “Transmission Control Protocol”, USC Inform.
Sci. Inst., Rep. RFC 793, Sept. 1981.
[11]Lef?er,Samuel J.,McKusick,Marshall K.,Karels,Michael
J.,and Quarterman,John S.,The Design and Implementation of the 4.3 BSD Unix Operating System, Addison-Wesley
Publishing Company, Inc., Redding, Massachusetts, 1989.
[12] Sterbenz, J.P.G., Parulkar, G.M., “Axon: A High Speed
Communication Architecture for Distributed Applications,”
Proceedings of the Ninth Annual Joint Conference of the
IEEE Computer and Communications Societies (INFO-
COM’90), June 1990, pages 415-425.
[13] Sterbenz, J.P.G., Parulkar, G.M., “Axon: Application-Ori-
ented Lightweight Transport Protocol Design,” Tenth Inter-national Conference on Computer Communication
(ICCC’90), Narosa Publishing House, India, Nov. 1990, pp 379-387.
Red hat linux常用操作命令汇总的一些命令： 1.查看硬件信息 # uname -a # 查看内核/操作系统/CPU信息 # head -n 1 /etc/issue # 查看操作系统版本 # cat /proc/cpuinfo # 查看CPU信息 # hostname # 查看计算机名 # lspci -tv # 列出所有PCI设备 # lsusb -tv # 列出所有USB设备 # lsmod # 列出加载的内核模块 # env # 查看环境变量资源 # free -m # 查看内存使用量和交换区使用量 # df -h # 查看各分区使用情况 # du -sh # 查看指定目录的大小 # grep MemTotal /proc/meminfo # 查看内存总量 # grep MemFree /proc/meminfo # 查看空闲内存量 # uptime # 查看系统运行时间、用户数、负载# cat /proc/loadavg # 查看系统负载磁盘和分区 # mount | column -t # 查看挂接的分区状态 # fdisk -l # 查看所有分区 # swapon -s # 查看所有交换分区 # hdparm -i /dev/hda # 查看磁盘参数(仅适用于IDE设备) # dmesg | grep IDE # 查看启动时IDE设备检测状况网络# ifconfig # 查看所有网络接口的属性 # iptables -L # 查看防火墙设置 # route -n # 查看路由表 # netstat -lntp # 查看所有监听端口 # netstat -antp # 查看所有已经建立的连接 # netstat -s # 查看网络统计信息进程
数据库文件及记录命令 ADD TABLE 在当前数据库中添加一个自由表 APPEND 在表的末尾添加一个或多个新记录 APPEND FROM ARRAY 由数组添加记录到表中 APPEND FROM 从一个文件中读入记录，追加到当前表的尾部 APPEND GENERAL 从文件中导入OLE对象并将其放入通用字段中 APPEND MEMO 将文本文件的内容复制到备注字段中 APPEND PROCEDURES 将文本文件中的存储过程追加到当前数据库中 A VERAGE 计算数值表达式或字段的算术平均值 BLANK 清除当前记录中所有字段的数据 BROWSE 打开浏览窗口，显示当前或选定表的记录 CALCULATE 对表中的字段或包含字段的表达式进行财务和统计操作CHANGE 显示要编辑的字段 CLOSE 关闭各种类型的文件 CLOSE MEMO 关闭一个或多个备注编辑窗口 COMPILE DATABASE 编译数据库中的存储过程 CONTINUE 继续执行先前的LOCATE命令 COPY MEMO 复制当前记录中的指定备注字段的内容到文本文件 COPY PROCEDURES 将当前数据库中’的存储过程复制到文本文件 COPY STRUCTURE 用当前选择的表结构创建一个新的空自由表 COPY STRUCTURE EXTENDED 创建新表，它的字段包含当前选定表的结构信息COPY TO ARRAY 将当前选定表中的数据复制到数组
COPY TO 用当前选定表的内容创建新文件 COUNT 统计表中记录数目 CREATE 生成一个新的VisualFoxPro表 CREATE CONNECTION 创建一个命名连接并把它存储在当前数据库中 CREATE DATABASE 创建并打开一个数据库 CREATE TRIGGER 创建表的删除、插入或更新触发器 CREATE VIEW 从VisualFoxPro环境创建视图文件 DELETE 给要删除的记录做标记 DELETE CONNECTION 从当前数据库中删除一个命名连接 DELETE DATABASE 从磁盘上删除数据库 DELETE TRIGGER 从当前数据库的表中删除“删除”、“插入”或“更新”触发器│ DELETE VIEW 从当前数据库中删除一个SQL视图 DISPLAY 在VisualFoxPro主窗口或用户自定义窗口中显示与当前表有关的信息DISPLAY CONNECTIONS 显示当前数据库中与命名连接有关的信息 DISPLAY DATABASE 显示有关当前数据库的信息，或当前数据库中的字段、命名连接、表或视图的信息 DISPLAY MEMORY 显示内存变量和数组的当前内容 DISPLAY PROCEDURES 显示当前数据库中存储过程的名称 DISPLAY STRUCTURE 显示一个表文件的结构 DISPLAY TABLES 显示包含在当前数据库中所有的表和表的信息 DISPLAY VIEWS 显示当前数据库中关于SQL视图的信息以及SQL视图是否基于本地或远程表的信息 DROP TABLE 把一个表从数据库中移出，并从磁盘中删除它 DROP VIEW 从当前数据库中删除指定的SQL视图
1 linux常用操作命令 linux系统中通过命令来提高自己的操作能力，下面由小编为大家整理了linux常用操作命令的相关知识，希望大家喜欢! linux常用操作命令一、常用指令 ls 显示文件或目录 -l 列出文件详细信息l(list) -a 列出当前目录下所有文件及目录，包括隐藏的a(all) mkdir 创建目录 -p 创建目录，若无父目录，则创建p(parent) cd 切换目录 touch 创建空文件 2 echo 创建带有内容的文件。
cat 查看文件内容 cp 拷贝 mv 移动或重命名 rm 删除文件 -r 递归删除，可删除子目录及文件 -f 强制删除 find 在文件系统中搜索某文件 wc 统计文本中行数、字数、字符数 grep 在文本文件中查找某个字符串rmdir 删除空目录 3 tree 树形结构显示目录，需要安装tree包
pwd 显示当前目录 ln 创建链接文件 more、less 分页显示文本文件内容head、tail 显示文件头、尾内容 ctrl+alt+F1 命令行全屏模式 linux常用操作命令二、系统管理命令 stat 显示指定文件的详细信息，比ls更详细who 显示在线登陆用户 whoami 显示当前操作用户 hostname 显示主机名 4 uname 显示系统信息
top 动态显示当前耗费资源最多进程信息 ps 显示瞬间进程状态ps -aux du 查看目录大小du -h /home带有单位显示目录信息 df 查看磁盘大小df -h 带有单位显示磁盘信息 ifconfig 查看网络情况 ping 测试网络连通 netstat 显示网络状态信息 man 命令不会用了，找男人如：man ls clear 清屏 alias 对命令重命名如：alias showmeit="ps -aux" ，另外解除使用unaliax showmeit 5 kill 杀死进程，可以先用ps 或top命令查看进程的id，然
DOS磁盘文件操作命令 一、实验目的 本章主要通过常用的DOS命令的练习，了解DOS的基本功能及其基本组成和DOS常用命令的使用方法。 二、实验条件要求 1.硬件：计算机 2.软件环境：Windows XP 三、实验基本知识点 1. DIR（Dir ectory） 功能：显示指定路径上所有文件或目录的信息 格式：dir [盘符：][路径][文件名] [参数] 参数： /w：宽屏显示，一排显示5个文件名，而不会显示修改时间，文件大小等信息；/p：分页显示，当屏幕无法将信息完全显示时，可使用其进行分页显示； /a：显示当前目录下的所有文件和文件夹； /s：显示当前目录及其子目录下所有的文件。 2. MD(M ake D irectory) 功能：创建新的子目录 格式：md <盘符:><路径名> <子目录名> 3. CD(C hange D irectory) 功能：改变当前目录 格式：cd <盘符:> <路径名> <子目录名> 注意： 根目录是驱动器的目录树状结构的顶层，要返回到根目录，在命令行输入：cd \ 如果想返回到上一层目录，在当前命令提示符下输入：cd.. 如果想进入下一层目录，在当前命令提示符下输入：cd 目录名 4. 全屏幕编辑命令：EDIT 格式：EDIT <文件名>
说明： （1）仅可编辑纯文本格式的文件 （2）指定文件存在时编辑该文件,不存在时新建该文件 5. 显示文件内容命令：TYPE 格式：TYPE <文件名> 说明： （1）可以正常显示纯文本格式文件的内容，而.COM、.EXE等显示出来是乱码。（2）一次只能显示一个文件内容，所以文件名不能使用通配符。 6. 文件复制命令：COPY 格式：COPY <源文件> [目标文件] 说明： （1）源文件指定想要复制的文件来自哪里——[盘符1:][路径1][文件名1] （2）目标文件指定文件拷贝到何方——[盘符2:][路径2][文件名2] （3）如缺省盘符则为当前盘符；路径若为当前目录可缺省路径。 （4）源文件名不能缺省，目标文件名缺省时表示拷贝后不改变文件名。 7. Tree 功能：显示指定驱动器上所有目录路径和这些目录下的所有文件名 格式：tree <盘符:> 8. 文件改名命令：REN 格式：REN <旧文件名> <新文件名> 说明： （1）改名后的文件仍在原目录中，不能对新文件名指定盘符和路径。 （2）可以使用通配符来实现批量改名。 9. 显示和修改文件属性命令：ATTRIB 格式：[盘符][路径] A TTRIB [文件名][+S/-S][+H/-H][+R/-R][+A/-A] 说明： （1）盘符和路径指出ATTRIB.EXE位置 （2）参数+S/-S:对指定文件设置或取消系统属性 （3）参数+H/-H:对指定文件设置或取消隐含属性 （4）参数+R/-R:对指定文件设置或取消只读属性 （5）参数+A/-A:对指定文件设置或取消归档属性
常用基本操作 1 常用工具栏的打开和关闭：工具栏上方点击右键进行选择 2 动态坐标的打开与关闭：在左下角坐标显示栏进行点击 3 对象捕捉内容的选择：A在对象捕捉按钮上右键点击（对象捕捉开关：F3） B 在极轴选择上可以更改极轴角度和极轴模式（绝对还是相对上一段线） 4 工具栏位置的变化：A锁定：右下角小锁；工具栏右键 B 锁定情况下的移动：Ctrl +鼠标移动 5 清楚屏幕（工具栏消失）：Ctrl + 0 6 隐藏命令行：Ctrl + 9 7 模型空间和布局空间的定义：模型空间：无限大三维空间 布局空间：图纸空间，尺寸可定义的二位空间 8 鼠标左键的选择操作：A 从左上向右下：窗围 B 从右下向左上：窗交 9 鼠标中键的使用：A双击，范围缩放，在绘图区域最大化显示图形 B 按住中键不放可以移动图形 10 鼠标右键的使用：A常用命令的调用 B 绘图中Ctrl + 右键调出捕捉快捷菜单和其它快速命令 11 命令的查看：A 常规查看：鼠标移于工具栏相应按钮上查看状态栏显示 B 命令别名（缩写）的查看：工具→自定义→编辑程序参数（acad.pgp） 12 绘图中确定命令的调用：A 鼠标右键 B ESC键（强制退出命令） C Enter键 D 空格键（输入名称时，空格不为确定） 13 重复调用上一个命令： A Enter键 B 空格键 C 方向键选择 14 图形输出命令：A wmfout（矢量图） B jpgout/bmpout（位图）应先选择输出范围 15 夹点的使用：A蓝色：冷夹点 B 绿色：预备编辑夹点 C红色：可编辑夹点 D 可通过右键选择夹点的编辑类型 E 选中一个夹点之后可以通过空格键依次改变夹点编辑的命令如延伸，移动或比例缩放（应注意夹点中的比例缩放是多重缩放，同一图形可在选中夹点连续进行多次不同比例缩放）
CentOS 丛书目录 — 系统管理 — 网络服务 — 应用部署 文件与目录操作命令 内容提要 1. 掌握常用的文件操作命令 2. 掌握常用的目录操作命令 目录操作命令 ls 功能说明: 显示文件和目录列表 命令格式: ls [参数] [<文件或目录> …] 常用参数: -a : 不隐藏任何以 . 字符开始的条目 -b : 用八进制形式显示非打印字符 -R : 递归列出所有子目录 -d : 当遇到目录时列出目录本身而非目录内的文件，并且不跟随符号链接 -F : 在条目后加上文件类型的指示符号 (*/=@| 其中一个) -l : 使用较长格式列出信息 -L : 当显示符号链接的文件信息时，显示符号链接所指示的对象而并非符号链接本身的信息-x : 逐行列出项目而不是逐栏列出 -1 : 每行只列出一个文件 -r : 依相反次序排列 -S : 根据文件大小排序 -X : 根据扩展名排序 -c : 根据状态改变时间（ctim e）排序 -t : 根据最后修改时间（m tim e）排序 -u : 根据最后访问时间（atim e）排序 使用举例: $ ls $ ls -a $ ls -F $ ls -l $ ls -R $ ls -Sl $ ls -rl $ ls -cl $ ls -tl $ ls -ul $ ls some/dir/file $ ls some/dir/ $ ls -d some/dir/
tree 功能说明: 显示文件和目录树 命令格式: tree [参数] [<目录>] 常用参数: -a : 不隐藏任何以 . 字符开始的条目 -d : 只显示目录不显示文件 -f : 每个文件都显示路径 -F : 在条目后加上文件类型的指示符号 (*/=@| 其中一个) -r : 依相反次序排列 -t : 根据最后修改时间（m tim e）排序 -L n : 只显示 n 层目录（n为数字） ––dirsfirst : 目录显示在前文件显示在后 使用举例: $ tree $ tree -d $ tree -F $ tree -L 3 $ tree /some/dir/ pwd 功能说明: 显示当前工作目录 命令格式: pwd [参数] 常用参数: -P : 若目录是一个符号链接，显示的是物理路径而不是符号链接使用举例: $ pwd $ pwd -P cd 功能说明: 切换目录 命令格式: cd [参数] [<目录>] 常用参数: -P : 若目录是一个符号链接，显示的是物理路径而不是符号链接使用举例: $ cd /some/dir/ $ cd -P Examples $ cd $ cd ~
实验一常用网络命令操作 （一）实验目的： 掌握PING/NET/NETSH路由跟踪命令等常用命令的使用方法， 从这些命令的响应来确定网络的状态和路径情况 （二）实验环境 PC机及互联网 （三）实验内容 1.ping命令的使用 ping命令的具体语法格式：ping目的地址[参数1][参数2] 主要参数有： a:解析主机地址 n:数据：发出数据包的个数，缺省为4 l:数值：所发出缓冲区大小 t:继续执行ping命令，直到用户按下CTRL+C键终止 https://www.doczj.com/doc/287497342.html,stat命令的使用 Netstat[-参数1][参数2] a:显示所有与该主机建立连接的端口信息 b:显示以太网的统计住处参数一般与S参数共同使用 n:以数字的格式显示地址和端口信息 s:显示每个协议的统计情况。 3.用VisualRouter跟踪路由信息，显示从源地址到目的地址 所经过的路由。
（四）实验结果分析： Ping命令： 我们使用ping命令ping百度的IP 202.108.22.5 使用-a参数来解析计算机NetBios名 使用-n 命令改变测试包的数量 使用-t 命令来一直执行ping命令直到键入CTRL+C
Netstat命令： 我们使用-a 命令来查看与我们主机机那里连接的端口信息 我们使用-e 命令显示以太网的统计住处该参数一般与S参数共同使用 我们使用-n 以数字的格式显示端口的地址信息：
我们使用-s显示每个协议的统计情况：
接下来我们使用VisualRouter来跟踪路由信息： 我们尝试着与193.168.110.52通信，并查看路由等信息 我们可以看见地区为：Luxumbourg 该IP属于德国卢森堡 网络为：Fondation RESTERA 防火墙信息：对ping命令不回应，对80端口的空请求不回应 还有一些数据包分析的信息。 从这张图中我还看到了路由的路径： 从 192.168.110.205->192.168.110.1->?->192.168.99.38->192.168.9 9.30->10.0.1.4->218.2.129.161->?->202.97.50.238->202.97.33.1 54->?->4.71.114.101->?->4.69.148.225->212.73.249.26->158.64. 16.189->193.168.110.52
C语言文件操作函数大全 clearerr（清除文件流的错误旗标） 相关函数 feof 表头文件 #include
常用指令操作汇总 1.常用指令 ?RLSBP/C （cro、pt、TO、T3212、ATT、TX、MAXRET、ACC、cb、cbq） / \ |cell...| RLSBP:CELL=+ +; |ALL | \ / / / \ | / / \\ |cell| | | |acc...|| RLSBC:CELL=+ + +[,CB=cb]|,ACC=+ +| |ALL | | | |CLEAR || \ / | \ \ // \ [,MAXRET=maxret][,TX=tx] [,ATT=att][,T3212=t3212] [,CBQ=cbq][,CRO=cro] [,TO=to][,PT=pt] \ | | [,ECSC=ecsc]+[,SLOW]; | | / ?RLSSP/C （nccperm、CHR、accmin、CCHPWR、rlinkt、DTXU、RLINKT、NECI、MBCR） / \ |cell...| RLSSP:CELL=+ +; |ALL | \ / / RLSSC:CELL=cell+[,ACCMIN=accmin][,CCHPWR=cchpwr][,CRH=crh] \ [,DTXU=dtxu][,NCCPERM=nccperm...] \ [,RLINKT=rlinkt][,NECI=neci][,MBCR=mbcr]+; / ?RLNRP/C （khyst、koffsetp/n、awoffset、bqoffset、CS、CAND） / \ | / \| | |cellr...|| |CELL=cell,CELLR=+ +| RLNRP:+ |ALL |+[,NODATA]; |CELL=ALL \ /| | | \ / / | RLNRC:CELL=cell,CELLR=cellr +[,CS=cs][,CAND=cand] | \ / / \\ | |KOFFSETP=koffsetp|| [,KHYST=khyst]|,+ +| | |KOFFSETN=koffsetn|| \ \ // / / \\ | |LOFFSETP=loffsetp|| [,LHYST=lhyst]|,+ +| | |LOFFSETN=loffsetn|| \ \ //
红帽linux常用操作命令 1.查看硬件信息 # uname -a # 查看内核/操作系统/CPU信息 # head -n 1 /etc/issue # 查看操作系统版本 # cat /proc/cpuinfo # 查看CPU信息 # hostname # 查看计算机名 # lspci -tv # 列出所有PCI设备 # lsusb -tv # 列出所有USB设备 # lsmod # 列出加载的内核模块 # env # 查看环境变量资源 # free -m # 查看内存使用量和交换区使用量# df -h # 查看各分区使用情况 # du -sh # 查看指定目录的大小 # grep MemTotal /proc/meminfo # 查看内存总量 # grep MemFree /proc/meminfo # 查看空闲内存量 # uptime # 查看系统运行时间、用户数、负载# cat /proc/loadavg # 查看系统负载磁盘和分区 # mount | column -t # 查看挂接的分区状态 # fdisk -l # 查看所有分区 # swapon -s # 查看所有交换分区 # hdparm -i /dev/hda # 查看磁盘参数(仅适用于IDE设备) # dmesg | grep IDE # 查看启动时IDE设备检测状况网络# ifconfig # 查看所有网络接口的属性 # iptables -L # 查看防火墙设置 # route -n # 查看路由表 # netstat -lntp # 查看所有监听端口 # netstat -antp # 查看所有已经建立的连接 # netstat -s # 查看网络统计信息进程
实验一：目录和文件操作命令 一、 root身份登录redhat，在/test目录下创建如下子树
二、完成以下操作： 1、将/test目录设置为所有人可读、可写、可执行；
2、新建用户user1,user2,user3,user4，并分别设置密码； 3、新建组workg1,workg2；
4、将user1、user2归属到workg1组中，将user3、user4归属到workg2组中； 5、查看四个用户信息(利用/etc/passwd文件)； 6、打开tty1，user1登录，在/test/owner/music下新建一文件：mymusic01.mp3，并将文件权限设置为除了本人，其他人都不能读、写、执行；
7、接上题，继续在/test/public/pubfile下新建一文件：user1file.txt，并将权限设置为所有人可读，可写，不可执行； 8、继续在/test/team/tefile下新建一文件：monday.txt，并将权限设置为自己、组员可读可写，其他人不可读不可写，所有人不可执行； 9、打开tty2，以user2身份登录，查看/test目录信息；
10、接上题，查看/test/owner/music/mynusic01.mp3,显示命令执行结果； 11、接上题，查看/test/public/pubfile/user1file.txt,显示命令执行结果； 12、接上题，查看/test/team/tefile/monday.txt, 显示命令执行结果； 13、打开tty3，以user3身份登录; 14、接上题，查看/test/owner/music/mynusic01.mp3,显示命令执
VFP常用的操作命令总结 <范围>子句 4种情况：ALL 操作对象为表中全部数据。 NEXT
③删除记录DELETE DELETE [<范围>] [FOR <条件>] GO 2 DELETE (逻辑删除第2条记录) DELETE ALL （逻辑删除全部记录） DELETE FOR 所在系=”中文”.and. .not. 性别 DELETE FOR 入学成绩<=470 恢复记录：RECALL RECALL [<范围>] [FOR <条件>] RECALL （只恢复当前一条记录）。 RECALL ALL （恢复所有打上删除标记的记录）。 物理删除命令：PACK、ZAP PACK （物理删除所有打上删除标记的记录，一旦执行，无法用RECALL 恢复）。 ZAP =DELETE ALL+PACK （等价于DELETE ALL 加上PACK，物理删除表中所有记录，只保留表结构，结果为一空表）。 ④插入新记录（用REPLACE命令填充一个新数据）看懂即可 APPEND BLANK (书上第26页) REPLACE 学号WITH “2006200”,姓名WITH “丁一”,性别WITH .T. ,出生时间WITH CTOD(“07/19/87”), 入学成绩WITH 508,所在系WITH “计算机”,系负责人WITH “程家吉” ⑤数据查询LOCATE LOCATE [<范围>] [FOR <条件>] 定位到范围中满足FOR条件的第1条记录。 LOCATE FOR YEAR(出生时间)=1986 (其中，出生日期为日期类型， 如果为字符串类型，可用RIGHT(出生日期,2)= "86"）
练习一： Shell 基础命令 （1）一、练习目的 1、 掌握目录和文件操作的常用命令。 二、练习内容1、 目录操作命令练习：在SHELL 终端中练习以下命令（并记录结果，回答所提问题）： 假设当前用户是zsc ，查看当前目录命令：pwd （问题：当前的路径是什么？绝对路径与相对路径区别是什么？命令提示符由哪几部分组成？）/home/zsc 命令提示符组成部分：用户名、z 主机名、当前路径[root@localhost ~] 查看目录内容命令：ls -al （问题：隐藏文件有何特点？显示文件属性的每一行信息各部分的含义是什么？，怎样查看目录自身属性信息？）隐藏文件名的前面有个小数点 每一条信息各部分含义分别是：文件类型、文件权限、硬链接文件个数、文件所有者、文件所属组、文件实际大小、最后修改时间、文件名称Ls – dl ·d wxr -x---- 16 root 4096 03-24 22:55（1）·- 一般文件·d 目录文件·l 符号链接文件·b 块设备文件·c 字符型设备文件 （2）r 表示读权限W 表示写权限x 表示执行权限、管路敷设技术通过管线敷设吊顶层配置不规范高中资料试卷问题，而且可保障各类管路习题到位。在管路敷设过程中，要加强看护关于管路高中资理高中资料试卷弯扁度固定盒位置保护层防腐跨接地线弯曲半径标高等，要求技术交底。管线敷设技术中包含线槽、管架等多项式，为解决高中语文电气课件中管壁薄、接口不严等问题，合理利用管线敷设技术。线缆敷设原则：在分线盒处，当不同电压回路交叉时，应采用金属隔板进行隔，强电回路须同时切断习题电源，线缆敷设完毕，要进行检查和检测处理。、电气课件中调试对全部高中资料试卷电气设备，在安装过程中以及安装结束后进行高中资料试卷调整试验；通电检查所互作用与相互关系，根据生产工艺对电气设备进行空载与带负荷下高中资料试卷调控试验；对设备进行调整使其在正常工况下与过度工作下都可以正常工作整核对定值，审核与校对图纸，编写复杂设备与装置高中资料试卷调试方案，编写重要设备高中资料试卷试验方案以及系统启动方案；对整套启动过程中高中资料试卷电气设备进行调试工作并且进行过关运行高中资料试卷技术指导。对于调试过程中高中资料试卷技术问题，作为调试人员，需料、设备制造厂家出具高中资料试卷试验报告与相关技术资料，并且了解现场设备高中资料试卷布置情况电气系统接线等情况，然后根据规范与规程规定，制定设备调试高中资料试卷方案。、电气设备调试高中资料试卷技术护装置调试技术，电力保护高中资料机组在进行继电保护高中资料试卷总体配置时，需要在最大限度内来确保机组高中资料试卷安全，并且尽可能地缩小故障高围，或者对某些异常高中资料试卷工况进行自动处理，尤其要避免错误高中资料试卷保护装置动作，并且拒绝动作，来避免不必要高中资料试卷突然停机。因此，电力高中资料试卷保护装置调试技术，要求电力保护装置做到准确灵活。对于差动保护装置高中资料试卷调试技术是指发电机一变时，需要进行外部电源高中资料试卷切除从而采用高中资料试卷主要保护装置。
SunOS 常用操作命令
1. 系统 # passwd：修改口令 # exit：退出系统 2. 文件 # cp：复制文件或目录，参数：-a递归目录，-i覆盖确认 # mv：改名移动 # rm：删除，参数：-r递归删除 3. 目录 # mkdir：创建目录 # rmdir：删除空目录 # cd：改变工作目录 # pwd：查看当前路径 # ls：列目录，参数：-a所有文件，-c按时间排序，-l详细信息--没有ll 4. 文本 # sort：排序 # uniq：删除重复行 5. 备份压缩 # tar：档案，参数：-c创建新档案，-r追加到末尾，-t列出档案内容，-u更新文件，-x释放文件，-f使用档案文件或设备，-M多卷，-v详细报告，-w每步确认。例tar cvf text.tar *.txt ++++++++++++++++++++++++++++++++ 在Linux 的环境里tar是新的，符合GUN，因此可以在tar的參數加上z 会自动呼叫gzip 但如果在某些unix 如sunos 其tar就无法呼叫gzip，因此如果同样一个 abc.tar.gz 压缩文档，要分二次解。 gzip -d abc.tar.gz 解开 .gz 会产生abc.tar 再执行 tar vxf abc.tar 就会再解开abc.tar全部了。 ++++++++++++++++++++++++++++++++ # gzip：压缩解压缩，参数：-d解压，-r递归压缩 # unzip：解压缩，参数：-d目录，-x解压缩 6. 权限 # chmod：改变权限，r可读，w可写，x可执行。0表示没有权限，1表示可执行权限，2表示可写权限，4表示可读权限，然后将其相加。例如，如果想让某个文件的属主有“读/写”二种权限，需要把4（可读）+2（可写）＝6（读/写）。# chgrp：改变所属用户组 # chown：改变属主 7. 管理 # wall：发送信息到全部登录用户
常用文件系统操作命令 一、Linux命令操作基础 1.文件通配符 Linux的命令中可以使用通配符来同时引用多个文件以方便操作。可以使用的通配符主要有“*”和“？”两种，结合使用“[]”、“-”和“！”字符可以扩充需要匹配的文件范围。（1）通配符“*” 通配符“*”代表任意长度（包括零个）的任何字符。但通配符“*”不能与“.”开头的文件名匹配。 （2）通配符“？” 通配符“？”代表任何单个字符。 （3）字符组通配符“[]”、“-”和“！” 用一对方括号“[]”括起来的字符串列表表示匹配字符串列表中的任意一个字符。其中的字符串列表可以由直接给出的若干个字符组成，也可以由起始字符、连接符“-”和终止字符组成。 例：myfile[abc] 表示myfile后面紧跟着a、b或c。 myfile[a-z] 表示myfile后面紧跟着一个小写字母。 Myfile[!a-e]表示myfile后面紧跟这一个不在a-e之间的字符。 Myfile[*?] 方括号中的星号和问号代表一个字符，不是通配符。 2.自动补全 所谓自动补全，是指用户在输入命令或文件名时不需要输入完整的名字，只需要输入前面几个字母，系统会自动补全该命令或文件名。若有不止一个，则显示出所有与输入字母相匹配的命令或文件名，以供用户选择。利用【tab】键可实现自动补全功能。 （1）自动补全命令 用户在输入Linux的命令时，只需要输入命令名的前几个字母，然后按【tab】键，如果系统只找到一个与输入相匹配的命令名，则自动补全；如果没有匹配的内容或有多个相匹配的名字，系统将发出警鸣声，再按【tab】键将列出所有相匹配的命令。 （2）自动补全文件或目录名 除了可以自动补全命令名外，还可以用相同的方法自动补全命令行中的文件或目录名。 3.命令历史 Linux系统中的灭个用户在自己的主目录下都有一个名为.bash_history的隐藏文件，它用来保存曾执行过的命令，这样当用户下次需要再次执行已执行过的命令时，不用再次输入，而可以直接调用。Bash默认最多保存1000个命令的历史记录。 调用历史命令的方法： （1）上下方向键 在命令行方式下按上方向键，命令提示符后将出现最近一次执行过的命令，再使用上下方向键，可以在已执行过的各条命令之间进行切换。直接按【enter】键就可以再次执行显示的命令，也可以对显示的命令行进行编辑修改。 （2）history和“！”命令 运用history命令可以查看命令的历史记录。 格式：history [数字] 如果不使用数字参数，则将查看所有命令的历史记录；如果使用数字参数，则将查看最近执行过指定个数的命令。显示的每条命令前面均有一个编号，反映其在历史记录列表中的序号。可以用“!”命令再次调用已执行过的历史记录，其格式为：
（一）UNIX常用命令和权限的使用 实验目的 1、熟悉UNIX系统的登录和退出。 2、了解UNIX的命令及使用格式。 3、熟悉UNIX/LINUX的常用基本命令。 实验内容 1、学习如何登录UNIX。 2、熟悉UNIX/LINUX的常用基本命令如ls、who、w、pwd、ps、pstree、top 等。 实验准备 预习附录一《UNIX/LINUX简介》 实验指导 一、UNIX的登录与退出 1、登录 由于LINUX是一个多用户操作系统，可以有多个用户同时使用一台计算机。运行各自的应用程序。为了区分各个用户，每个用户都拥有自己独立的用户帐号。用户在使用LINUX时都必须以自己的用户名进行登录。登录提示为：login： 在bash shell下“＃”为root用户的命令行提示符，“＄”为一般用户的命令行提示符。 （2）步骤 login：（输入username） password：（输入密码） 2、退出 在UNIX系统提示符$下，输入logout、exit或shutdown 或按CTRL+ALT+DEL退出系统。 例：$ logout 3、关闭系统 LINUX与WINDOWS9X相似，在不使用计算机时应该先关闭系统，再关机。关机一般由root用户进行。关机的方法：halt或shutdown。 二、UNIX命令格式 命令[选项] [处理对象] 例：ls -la mydir 注意：（1）命令一般是小写字串。注意大小写有别 （2）选项通常以减号（-）再加上一个或数个字符表示，用来选择一个命令的不同操作 （3）同一行可有数个命令，命令间应以分号隔开
（4）命令后加上&可使该命令后台（background）执行 1、man获取命令帮助 功能：查阅指定命令或资源联机手册。 语法：man 〈command〉 说明：man是帮助手册manul的缩写，它的命令格式是man后跟需获取帮助的命令，显示过程中随时可用q退出。 示例：man ls 2、用 - -help获取命令参数的说明 功能：查阅指定命令所用的参数。 语法：〈command〉--help 说明：使用命令后直接跟--help获取该命令所需参数的帮助。 示例：ls –help 三、常用命令 1、目录操作 和DOS相似，UNIX采用树型目录管理结构，由根目录（/）开始一层层将子目录建下去，各子目录以/ 隔开。用户login后，工作目录的位置称为home directory，由系统管理员设定。…~?符号代表自己的home directory，例如~/myfile 是指自己home目录下myfile这个文件。 UNIX的通配符有三种：?*? 和??? 用法与DOS相同，…-… 代表区间内的任一字符，如test[0-5]即代表test0，test1，……，test5的集合。 （1）显示目录文件ls 执行格式：ls [-atFlgR] [name] (name可为文件或目录名称) 例：ls 显示出当前目录下的文件 ls -a 显示出包含隐藏文件的所有文件 ls -t 按照文件最后修改时间显示文件 ls -F 显示出当前目录下的文件及其类型 ls -l 显示目录下所有文件的许可权、拥有者、文件大小、修改时间及名称 ls -lg 同上 ls -R 显示出该目录及其子目录下的文件 注:ls与其它命令搭配使用可以生出很多技巧(最简单的如"ls -l | more")，更多用法请输入ls --help查看，其它命令的更多用法请输入命令名 --help 查看. （2）建新目录mkdir 执行格式：mkdir directory-name 例：mkdir dir1(新建一名为dir1的目录) （3）删除目录rmdir 执行格式：rmdir directory-name 或rm directory-name 例：rmdir dir1 删除目录dir1，但它必须是空目录，否则无法删除
转载： https://www.doczj.com/doc/287497342.html,/jrckkyy/blog/item/982b15869490122966096ee6.html 调用文件系统(FS)Shell命令应使用 bin/hadoop fs
实验四：常用的目录和文件操作命令 一、实验准备知识：P37表3-2 1、当前工作目录 ?用户目前所处的目录 ?用户登录后进入的目录通常是自己的主目录 ?可用pwd 命令查看用户的当前目录 ?可用cd 命令来切换目录 ?一些特殊字符的特殊含义： ?“ .” 表示当前目录 ?“..” 表示当前目录的上一级目录（父目录） ?“-” 表示用cd 命令切换目录前所在的目录 ?“~” 表示用户主目录的绝对路径名 2、路径(path) ?路径是指文件或目录在文件系统中所处的位置 ?绝对路径 ?以斜线（/）开头 ?描述到文件位置的完整说明 ?任何时候你想指定文件名的时候都可以使用 ?相对路径 ?不以斜线（/）开头 ?指定相对于你的当前工作目录而言的位置 ?可以被用作指定文件名的简捷方式 二、实验过程： 1、目录命令： 1)ls命令： 功能：显示文件或目录信息 ?格式：ls [选项] [目录或是文件] ?说明： ?对于目录，该命令将列出其中的所有子目录与文件。 ?对于文件，ls 将输出其文件名以及所要求的其他信息。 ?默认情况下，输出条目按字母顺序排序。 ?当未给出目录名或文件名时，就显示当前目录的信息。 应用举例：
2)mkdir命令： 功能：创建目录 ?格式：mkdir [选项] [目录名件] ?选项说明： ?-m：对新建目录设置存取权限，在没有“-m”选项时。默认权限是755. ?-p：可以是一个路径名称，此时若路径中的某些目录尚不存在，加上此选项后，系统将自动创建那些尚不存在的目录，即一次可以建立多个目录。 应用举例： #mkdir /root/dir3 #mkdir dir4 //创建一个空目录 #mkdir -p dir5/dir6 //创建一个空目录树 #mkdir -p dir5/{abc,bcd}/htdocs //创建/srv/www/abc/htdocs和/srv/www/bcd/htdocs目录 #mkdir –p A B B/B1 3)pwd命令： 功能：显示当前工作目录 ?格式：pwd 4)cd命令：功能：切换目录 ?说明：工作目录路径可以使用绝对或相对路径名，绝对路径从/（根）开始，相对路 径从当前目录开始。 应用举例： #cd /etc //更改工作目录为etc #cd .. //改变目录位置至当前目录的父目录 #cd ~ //改变目录位置至用户登录时的工作目录。 #cd ~tong //改变目录位置至用户tong的宿主目录。 5)tree命令：功能：显示目录树 ?格式：tree