🚀 go-pugleaf

In article <541@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes:

>Is anyone working on higher speed LANs?

Yes.

>..  We have lots of conversation
>here on ISO, TCP/IP, and ISO vs. TCP/IP, but they all seem to be
>content with the same old (what, 12 years now?) speed.  Ethernet at
>10Meg, twisted pair stuff at 1 or 2Meg, fiber backbones at 80 and
>100Meg.  But, disk to disk rates are still down at 20K to 100K bytes
>per second.

I believe that there is a fundamental problem in using a general purpose
reliable network protocol like TCP/IP or most of the ISO/OSI protocols for
VERY high speed data transfers.  But, not all of the cited problem is
TCP/IP, and not that many people need as high rates as they think they need.
In fact, if many people really knew what rates they were actually getting,
they really might confuse themselves.  

Anyway, TCP/IP could easily support packet sizes of 32KB which would make a
very big difference in speed (My guess is that you could do 1-2MB/sec easily
just by increasing packet size to 32K).  Hyperchannel will support packets
that big (Hyperchannel has other problems, though).  But what packet size will
Proteon 80Mbit/s rings support, or the new FDDI standard?  I'm not sure, but
the 1500 Byte Ethernet limitation is too small.  Even if you can get the data
rates up there, you burn up too many CPU cycles doing it.  Your TCP/IP needs
to be smart enough to negotiate larger packet sizes.  The default limit still
has to be 576 bytes or whatever for dealing with PC's, the internet, etc.

But I would like to add to the question and ask - How much bandwidth do you
really need, and for which purposes?  You also have to distinguish between
individual rates and aggregate throughput [for example, two 1 MIPS machines on
an Ethernet may do .25 Mbit/s between them, when the Ethernet itself is
running at 3 Mbit/s aggregate].

Also, one of the reasons that packets must be kept small on lower speed
networks is so that response time can be kept reasonable.  One of the
advantages of using higher speed (e.g. optical fiber) LANS will be that packet
sizes can be increased without increasing the access time for an individual
user.

>
>Are there fundamental problems with TCP/IP that limit its application
>to higher speed use?  Are the new ISO protocols better for high speed
>file transfer?  Or, is the problem in the operating systems or
>interface to the computer bus?  Can the high speed backbone fiber
>networks be made to handle individual computer to computer or
>computer to terminal traffic?  Or, it there some fundamental issue
>that keeps them in the LAN to LAN bridging application?
>

In general, ISO will not be better.  The usual limitation is the operating
system and CPU, which can't switch between walking (running your job) and
chewing gum (handling network interrupts) too many times per second, and may
not be able to process all the network level stuff fast enough to provide
acknowlegements fast enough, etc.  An alternative approach is to put all the
interrupts in a special processor.  Excelan makes boards that do just that.
Many people, including people at Ames, are looking at high speed fiber as a
way to increase network speed.

>I know that there are propritary protocols and links that go much
>faster, but is it necessary to throw out the standards and ability
>to internet and use diverse equipment and applications to get the
>higher speed?

Some of those proprietary protocols and links don't run as fast as people
think.  If you want channel speeds, you are going to have to look at the whole
data transfer process very carefully.  How many interrupts will you generate,
are the processes involved kernel processes or user processes, what is the
protocol, packet sizes, acknowledgement and window strategy, etc.  One way to
increase the speed between two specific machines would be to reimplement ftp
with a special high speed channel backdoor that would avoid TCP/IP altogether,
while running normally to other nodes.  You may have to do some extra
checksumming to guarantee data integrity, but you don't have to worry about
data out of order, routing, etc.  Acknowledgement is much faster, and your
data transfers can be in much larger blocks. 

If you need the reliability and generality of a complete network protocol, you
are going to have to pay the price for it in slower speed and larger
consumption of CPU cycles.


  Hugh LaMaster, m/s 233-9,  UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")