[comp.dcom.lans] Increasing Ethernet frame length?

mac3n@babbage.acc.virginia.edu (Alex Colvin) (01/27/88)

> > What are the implications of increasing the maximum length of frames on
> > an Ethernet style network (we're using a Cheapernet)?
> 
> > Why does the spec have the 1518 byte limitation?  Would small increases, like
> > to 2048+18 be acceptable, but larger increases not?

12 Ethernet addressing
+ 2 length
+ 3 LLC header
+ 1 fill for word boundary
+ 1500 INFO

The 1500 limit is a lower bound -- an implementation must support at
least this much.  If it transmits 2048 there's no guarantee that a
receiver can buffer that much.  Really long packets would encounter the
Jabber inhibit. 

> Traffic that is largely small messages or bursty in nature
> (transaction oriented systems, for example) will see more benefit from
> a small frame sizes, unless of course delay is not an issue.

The 1500 limit doesn't mean you can't send shorter packets.  I believe
that an implementation must support packets as short as 48.  Too short
and you run into problems detecting collisions.  At least one
implementation that I know of hangs nondeterministically on 32 byte
packets. 

The access delay for short messages caused by the presence of large
messages is minimal.  2KB/10Mb/s is about 1.6ms versus 1500B/10Mb/s,
about 1.2ms.  if 400us makes a lotta difference to you, you've got one
fast network driver.  Note also that it's packets that cause collisions,
not packet size.  Fewer packets, less backoff time. 

Note that we're talking about 25% increase in packet size or reduction in
packet count.  If, as is likely, you spend your time processing packets
this could win you up to 25%.

Isn't the limit for the token bus 8K bytes?  What about the token ring?