Re: purpose of fddi mailing list

[Vernon Schryver <[e-mail]>]

> From fddi-relay  Wed Nov 28 13:03:01 1990
> Subject: purpose of fddi mailing list
> 
> Not knowing the function of the [e-mail] mailing list ... I'm
> interested in knowing if it is an appropriate forum for discussing
> performance of commercially-available fddi products.  Please e-mail
> me if performance issues are *not* an appropriate topic for the list.
> 
> Thanks,
> [e-mail]


Many of the readers of this list care a lot about the performance of
certain commercial FDDI products.  Generally, we each have a few products
we want to be faster and a lot we want to be slower.  It would be nice if
we could come up with some generally agreed benchmark or benchmarks.
Unfortunately, I have no hope for such a happy outcome.  Silicon Graphics
sales has been hearing the usual baloney via customers and prospects, so
are requesting the same baloney from me.

The usually baloney is any of:
    -quoting UDP instead of TCP, and often UDP transmit rates, sometimes
	Without checksums.  Depending on hardware, checksums can make a big
	difference.  Almost no one now runs UDP without checksums for
	anything but benchmarks.

	Many systems can queue UDP packets faster than they can transmit
	them.  Standard BSD-style drivers discard output frames when they
	get behind.  If you are not careful, you end up doing what one
	ethernet board vendor did in a presentation to me, claiming UDP
	transmission rates higher than the media speed.

	Of course, UDP is an important protocol, and I personally care how
	certain products do UDP.  The baloney quoting UDP instead of TCP.

    -running many TCP circuits, sometimes on several machines, and simply
	adding the numbers.   For example, one board vendor presented a
	number to me that turned out to be the sum of all of the TCP
	traffic among three machines.

	This might be a good benchmark, if what you intend to measure is
	some kind of aggregate system performance, and if the load is
	more interesting than simply a bunch of simultaneous ttcp's.

    -making "minor" changes in the most common TCP benchmark ("ttcp
	from BRL), and not mentioning that fact, let alone describing
	the nature of the changes.

    -running with novel tweaks, such as 32kByte IP packets, over the
	4KB FDDI MTU, but not mentioning it.

For your purposes, there is little hope.  We always ask each other for
numbers.  To get numbers, you have to give some, but this is all very
private.  Many of us have products released or in beta sites.  The beta
sites measure things in their own ways, but are usually constrained by
non-disclosure agreements from saying anything publically.  At another
extreme, we can expect any day to see individual users with FDDI cards in
PC's announcing that FTP over FDDI does twice as well as ethernet,
achieving all of 100KBytes/second.

Many of us have bags of tricks intended to make things faster.  We'd be
happy to add your suggestions to our own bags, but our bosses would not be
pleased if we publically disclosed our own tricks.

The numbers I've heard from various sources for products from companies
other than mine range from <10Mbits/sec to >80Mbits/sec for TCP.  For
various reasons, I think the former is a soon to be fixed bug, and the
latter is a naked lie.


Vernon Schryver,   [e-mail]