Peter Steenkiste. Analyzing Communication Latency using the Nectar Communication Processor. Proceedings of the SIGCOMM '92 Symposium on Communications Architectures and Protocols, ACM, Baltimore, August, 1992, pp. 199-209.  Home/Search   Document Details and Download   Summary   Related Articles   Check

.... throughput, protocol processing latency is significantly affected by the complex, protocol specific cache behavior of network protocols [16, 133] Finally, protocol stack execution performance is significantly affected by operating system overheads such as context switching and device interrupts [163]. The number of context switches incurred during protocol processing are a function of the protocol architecture employed [152] while the number of interrupts is a function of the design of the network adapter and the packet input mechanism adopted [151, 173] Further, since the communication ....

P. Steenkiste, "Analyzing communication latency using the Nectar communication processor," in Proc. of ACM SIGCOMM, pp. 199--209, August 1992.

.... et al. Cooper et al. developed the Nectar Communications Accelerator Board (CAB) a flexible communications architecture in which various transport and network layer protocols may execute off host on a general purpose RISC processor, supported by some proto 43 col independent custom hardware [11][43]. This protocol processor is but one component in the Nectar project, which aims to construct a local area network that can function as a multiprocessor composed of workstation nodes. In this scenario, the designer s primary goal was to achieve low host to host message latency. The main benefit of ....

P. Steenkiste, "Analyzing Communication Latency Using the Nectar Communication Processor," Proceedings of SIGCOMM `92, 1992, pp. 199-209.

....SMDS network. A custom timing card with 10 s accuracy provided the timestamps from the difference of which the delays were calculated. The monitoring PC with the card was connected to the SMDS network via routers on the same Ethernet as the PC. They present round trip delay pdfs. Steenkiste [22] has measured the communication latency of the Nectar system, a switch based network of workstations built at Carnegie Mellon University. He presents half of the measured roundtrip time for a message between two application processes as the one way latency. Kay and Pasquale [10] have measured mean ....

P. Steenkiste, "Analyzing communication latency using the Nectar communication processor," Computer Communications, vol. 16, no. 8, August 1993, pp. 472-83.

....bursty data communications traffic (such as transaction style traffic) bulk data transfer, and the sustained bandwidth requirements of applications supporting continuous media. We believe that approaches optimized towards a particular traffic type, such as low latency transactional traffic [24], will suffer if the traffic mix varies considerably. The software operating on the host is usually partitioned functionally into a series of layers defined by protection boundaries. Typically, each software layer contains several protocol layers. The user s applications are typically executable ....

....the latency required in request reply communications, while delivering high throughput for data intensive applications. The NAB separated these two classes of traffic to optimize its performance. The NAB included an on board microcontroller. The Nectar Communications Accelerator Board (CAB) [24] includes a microcontroller with a complete multithreaded operating system. The host CAB interaction is via messages sent over a VME bus, synchronized using a mailbox scheme. The programmability can be used by applications to customize protocol processing. Cooper, et al. 8] report that TCP IP ....

[Article contains additional citation context not shown here]

Peter A. Steenkiste, "Analyzing Communication Latency Using the Nectar Communication Processor," in Proceedings, SIGCOMM '92 Conference, Baltimore, MD (August 17-20, 1992), pp. 199-209.

....the latency required in request reply communications, while delivering high throughput for data intensive applications. The NAB separated these two classes of traffic to optimize its performance. The NAB included an on board microcontroller. The Nectar Communications Accelerator Board (CAB) [22] includes a microcontroller with a complete multithreaded operating system. The host CAB interaction is via messages sent over a VME bus, synchronized using a mailbox scheme. The programmability can be used by applications to customize protocol processing. Cooper, et al. 7] report that TCP IP ....

....traditional bursty data communications traffic (such as transaction style traffic) bulk data transfer, and the sustained bandwidth requirements of applications using continuous media. We believe that approaches optimized towards particular traffic types, such as low latency transactional traffic [22], will suffer if the traffic mix varies considerably. The software operating on the host is usually partitioned functionally into a series of layers defined by protection boundaries. Typically, each software layer contains several protocol layers. The applications are typically executable ....

[Article contains additional citation context not shown here]

Peter A. Steenkiste, "Analyzing Communication Latency Using the Nectar Communication Processor," in Proceedings, SIGCOMM '92 Conference, Baltimore, MD (August 17-20, 1992), pp. 199-209.

No context found.

Peter Steenkiste. Analyzing Communication Latency using the Nectar Communication Processor. Proceedings of the SIGCOMM '92 Symposium on Communications Architectures and Protocols, ACM, Baltimore, August, 1992, pp. 199-209.

....interface can easily become a bottleneck, resulting in poor performance. Another approach is to provide a simpler network interface and to minimize the amount of work that is assigned to it by performing some of the communication tasks on the distributed memory system itself. Earlier research [40] shows that the time spent on sending and receiving network data is distributed over several operations such as copying data, buffer management, protocol processing, and interrupt handling, and different overheads dominate depending on the circumstances (e.g. packet size) By executing some ....

Peter Steenkiste. Analyzing communication latency using the nectar communication processor. In Proceedings of the SIGCOMM '92 Symposium on Communications Architectures and Protocols, pages 199--209, Baltimore, August 1992. ACM.

....networks, the sending and receiving hosts typically form the bottleneck, and it is important to minimize the communication overhead to achieve high application level throughput. The communication cost can be broken up in per packet and per byte costs. The per packet cost can be optimized [1, 2], and for large packets, this overhead is amortized over a lot of data. However, the cost of per byte operations such data copying or checksumming cost is not reduced by increasing the packet size. Moreover, the per byte cost depends strongly on the memory bandwidth, which over time has not ....

....the CAB is in part a result of having outboard buffering and in part the result of having an experimental prototype, since a production version would probably not use a microprocessor. The fact that a network device controlled by software increases latency was also observed in the Nectar system [2], the predecessor of Gigabit Nectar. 7 Related work We review related work in the area of host interface design, focusing on single copy architectures. The Afterburner interface [6] built by HP Research Labs in Bristol, also uses outboard buffering and checksumming to achieve single copy ....

Peter Steenkiste. Analyzing communication latency using the nectar communication processor. In Proceedings of the SIGCOMM '92 Symposium on Communications Architectures and Protocols, pages 199--209, Baltimore, August 1992. ACM.

....packet sizes observed on networks is bimodal: it is a mix of small packets (header plus a few tens of data bytes) and maximum size packets. The overheads associated with both types of packets are quite different. The operations associated with sending and receiving small packets falls in 4 classes [11]: transport protocol processing, context switching (thread process switching and interrupt handling) datalink protocol processing (dealing with the network adaptor) and buffer management. Studies have shown that each class contributes significantly to the communication cost. As an example, Table ....

....the network adaptor) and buffer management. Studies have shown that each class contributes significantly to the communication cost. As an example, Table 2 breaks up the time it takes to send and receive a one word message (4 bytes) using different communication protocols over the Nectar network [11]. For large packets, the same set of operations has to be performed, but the cost of copying the data starts to dominate. Figure 3 shows how the communication cost grows with the message size. The cost of copying the data dominates the per packet processing cost for packet sizes over 1500 bytes ....

[Article contains additional citation context not shown here]

Peter Steenkiste. Analyzing Communication Latency using the Nectar Communication Processor. Proceedings of the SIGCOMM '92 Symposium on Communications Architectures and Protocols, ACM, Baltimore, August, 1992, pp. 199-209.

....high speed networks, the sending and receiving hosts typically form the bottleneck, and it is important to minimize the communication overhead to achieve high application level throughput. The communication cost can be broken up in per packet and per byte costs. The perpacket cost can be optimized [3, 17], and for large packets, this overhead is amortized over a lot of data. However, the per byte cost is not reduced by increasing the packet size. Moreover, the per byte cost depends strongly on the memory bandwidth, which over time has not increased as quickly as This research was supported by the ....

Peter Steenkiste. Analyzing communication latency using the nectar communication processor. In Proceedings of the SIGCOMM '92 Symposium on Communications Architectures and Protocols, pages 199--209, Baltimore, August 1992. ACM.

....interfaces that are more appropriate for network based multicomputer applications will be developed in parallel or on top of sockets. 3 The Host Network Interface Architecture Many papers have been published that report measurements of the overheads associated with communicating over networks [12, 4, 13, 14, 15, 16]. Even though it is difficult to compare these results because the measurements are made for different architectures, protocols, communication interfaces, and benchmarks, there is a common pattern: there is no single source of overhead. The time spent on sending and receiving data is distributed ....

....complicated and expensive since it requires a high performance general purpose CPU (with matching memory system) for protocol processing. A second drawback is that the host and network interface have to share state and the host interface pair must be viewed as a multiprocessor. Earlier experiments [18, 16] show that this can make interactions between the host and CAB considerably more complex and expensive compared with a master slave model. Given these drawbacks and the limited advantages, we decided to perform protocol processing on the host, and to make the CAB a pure slave. Given the high cost ....

P. Steenkiste, "Analyzing Communication Latency using the Nectar Communication Processor," in Proceedings of the SIGCOMM '92 Symposium on Communications Architectures and Protocols, (Baltimore), pp. 199--209, ACM, August 1992.

....hosts: traditional workstations with a powerful outboard protocol engine and light weight hosts with basic network interface, i.e. the CABs. The CAB runtime system is similar to the runtime system on dedicated multicomputers and to micro kernel operating systems. In this paper, which is based on [20], we first give an overview of Nectar, concentrating on the CAB architecture and Nectar communication software (Section 2) In Section 3 we present a breakup of the CAB CAB message latency for a number of communication protocols, and we discuss how these overheads are influenced by the CAB ....

Peter Steenkiste. Analyzing Communication Latency using the Nectar Communication Processor. Proceedings of the SIGCOMM '92 Symposium on Communications Architectures and Protocols, ACM, Baltimore, August, 1992, pp. 199-209.

No context found.

Steenkiste, P. Analyzing Communication Latency using the Nectar Communication Processor. In SIGCOMM92, pages 199-209. ACM, Baltimore, August, 1992.

No context found.

Steenkiste, Peter. "Analyzing Communication Latency using the Nectar Communication Processor", Proceedings of SIGCOMM-92, pp. 199-209, August 1992.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC