jas@proteon.COM (John A. Shriver) (09/06/88)
Trailers only happen when the amount of data is a multiple of the page size of the machine (512 bytes on a VAX). This is because their (alleged) benefits have to do with replacing mbuf copies with dinking the memory management to copy pages on the VAX. These benefits only accrued if all of the data was page aligned and page length. Most packets are not 512 bytes of data, so you open the connection, give the command (maybe do a more on telnet), and wham!, you die the trailer death. Sun does not reccomend trailers because they don't even offer their (alleged) benefits on a Sun. They depended on the fact that a VAX has two memory maps. One is the CPU memory management. The other one is the Unibus map, which mapped pages (512 bytes) in Unibus slave address space to pages in main memory. This gave them the precision needed to play the page alignment games. The Sun DVMA system does DMA through the same MMU as the CPU uses. This is cheaper (Sun always designs hardware to a price), but not as flexible. Moreover, the routines in the VAX that did the page based hacking (if_rubaget, if_wubaput) aren't even there on the Sun. This is because all of their Ethernet devices have either been memory mapped (the 3Com and Sun/Intel Multibus boards), or DMA using kernel virutal addresses (all of the on-CPU Ethernets). The VAX routines eased writing Unibus network drivers. (Unfortunately, their absence on the Sun makes writing VMEbus DMA device drivers rather nasty.) Sun uses different strategies than page dinking to speed copying, namely enormous mbufs with an mbuf free upcall. When a Sun gets a trailer, it has to copy the blasted trailing header back to an mbuf at the front of the chain. It is distinctly slower to receive trailers on a Sun. Trailers are best disabled. They cause too many problems, and there are disagreements on whether the performance advantages on the VAX are real or were measurement artifacts. The hosts RFC will cover trailers.
henry@utzoo.uucp (Henry Spencer) (09/10/88)
In article <8809061604.AA29996@monk.proteon.com> jas@proteon.COM (John A. Shriver) writes: >Sun does not reccomend trailers because they don't even offer their >(alleged) benefits on a Sun. They depended on the fact that a VAX has >two memory maps... They also depended on the fact that a VAX has relatively small pages. It's impossible for an Ethernet packet to be a multiple of the page size of any modern Sun. (Sun 3 pages are 8KB; I think even the Sun 2 used 2KB.) -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
nowicki@SUN.COM (Bill Nowicki) (09/13/88)
While we are on the subject of trailers, we recently ran into the following question. Right now we have to support trailers on Ethernet, in case someone else sends them, but what about the IEEE 802.2-based networks? For example, 802.3 (with the SNAP headers), Token rings, FDDI, etc. Given the inter-operability problems that trailers have caused in the past, I would like to say "good riddance" to them on the more modern networks. What do people think? Will we be flamed mercilessly again for getting rid of trailers? Or flamed mercilessly for propagating them? -- Bill Nowicki Sun Microsystems
jbn@glacier.STANFORD.EDU (John B. Nagle) (09/13/88)
Trailers were a bad idea whose time has passed. Even under Berkeley UNIX on a VAX, their home ground, the performance improvement was very marginal. John Nagle
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (09/14/88)
RFC 1042 states: Consenting systems on the same IEEE 802 network may use this format between themselves. Details of the trailer encapsulation method may be found in [9]. However, all hosts must be able to communicate using the standard (non-trailer) method. If I were you, I would not "consent" to using them so that you don't have to support them. Drew