>In speaking with an individual in the performance group at Sun, I was told
>that TCP/IP performance of SunOS 5.1 (and SunOS 5.2) was anywhere from equal
>that of SunOS 4.x (presumably 4.1.3) to 80% of SunOS 4.x. This was due
>primarily to implementing TCP and IP as STREAMS modules, which resulted in
>a net loss of performance. I believe this information was collected for the
>Sun4m architecture.
There was a measurable difference between 5.1 and 5.2, so I don't
think that you can say lump 5.1 and 5.2 performance together.
5.2 was released just last month, and from what I heard their
was quite a difference between the last 5.2 betas and 5.2 itself.
Quote:>I haven't spent any time looking at the performance of these systems, but
>I would recommend comparing between Solaris 2.2 and SunOS 4.1.3 (weren't there
>some tweaks in the 4.1.3 network code which gave improved performance over
>4.1.1?).
Actuall, I did look into this. We have only a few machines running 4.1.3,
but the performance test (50-70% more thruput on the loopback interface)
hold for 4.1.3 equally.
The original tests I've run are broken, though. The concentrators we
use start flashing red light when confronted with large mounts
of traffic. Most SPARC based machien can saturate ethernet.
Quote:>It is hard for me to imagine that the SunOS5.x STREAMS implementation of
>TCP and IP could beat the SunOS 4.x network code. Maybe Sun got around
>to fixing up the network code.
Hard to imagine? Please, do explain. The 4.1.x networking code
isn't really worlds best. Suns performed really poor in FDDI.
Also, I do not see why STREAMS based code should be slower.
There are no extra copies of the data involved. (Data passed
down through streams modules isn't copied)
Quote:>At any rate, I am somewhat skeptical of Sun's move to implement TCP/IP as
>STREAMS modules. Other vendors, such as SGI and Cray, although SYSV-based,
>have avoided STREAMS when it came to the network code. This was done, by
>and large, for performance reasons.
Presumably because the people at USL were writing a reference implementation.
Their productivity was measured in added features, not removed bugs
or improved performance. It shows. Things that are intersting from
a research point of few, like squeezing the last byte out of the bandwidth
or minimizing protocol overhead, showed up in ready to use socket
code. It was much easier for CRAY and SGI to get the socket code than
it was to reimplement those ideas in STREAMS.
Quote:>I'll be interested to see how future Sun network performance stacks up with
>vendors such as SGI and DEC (anybody have FDDI numbers for SunOS 5.x?).
The FDDI numbers will be interesting. It's easy to outperform SunOS 4.x
in that respect. You can do that with a flashlight and a piece
of fiber.
It is possible that STREAMS has a higher per packet overhead,
each packet must be handled explicitly at each layer,
but for the movement of bytes to the network layer, I've
yet to find someone to explain to me why `~STREAMS are inherently
slower for TCP/IP''.
It may be that TCP/IP is here to stay. In that case STREAMS will
by you nothing. (Or almost nothing). But if we get OSI on a large
scale, STREAMS code doesn't have to be rewritten. Socket code
will have to be changed.
Casper
by