NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/dcom/cellrel/735

Internet Message Format | 1992-11-17 | 1.8 KB

Path: sparky!uunet!sun-barr!ames!agate!doc.ic.ac.uk!uknet!pavo.csi.cam.ac.uk!dm
From: [e-mail] (Derek McAuley)
Newsgroups: comp.dcom.cell-relay
Subject: Re: Computers dont like ATM?
Message-ID: <[e-mail]>
Date: 18 Nov 92 07:31:23 GMT
References: <[e-mail]>
Sender: [e-mail] (USENET news)
Organization: U of Cambridge Computer Lab, UK
Lines: 24
Nntp-Posting-Host: malin.cl.cam.ac.uk

In article <[e-mail]>, [e-mail] (Greg Lampard) writes:
|> This morning I heard a talk by Dr Paul Green from IBM Research, in
|> which he was explaining his work on high-speed all-optical networking.
|> More or less in passing, he mentioned that 53 byte cells are too small
|> for computers (or words to that effect).  His claim was that small
|> packets are good for delay-sensitive applications, but they make a lot
|> of unnecessary work for the computer that has to receive them, since it
|> has to process a header every 53 bytes, and often just stores the cell
|> to build up a larger packet for the next layer up the protocol stack.

Many computers are well used to dealing in small fixed sized units; lets call
these units cachelines. The trick is to do such handling in hardware.

But the cry always goes up "the cost the complexity"; Pah! that's what people
said about caches / snooping / virtual addressing / pipelines / ad nauseum ...
until one day the hardware designers bit the bullet and it just happened because
that's what it took to go faster.

So look at it another way; assume some day we have to handle network traffic in
hardware - as someone who dabbles in hardware I know my prefered solution would
be to manipulate fixed rather than variable sized objects. The words paging and
segmentation seem to spring to mind for some reason.

Mac.