From: CSYSMAS@UCLAMVS.BITNET (Michael Stein)
Newsgroups: bit.listserv.ibmtcp-l
Subject: Platform? (MVS TCP/IP performance?)
Date: 7 Oct 92 16:22:00 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

> > Michael Stein wrote:
> > 1000 -IUCV socket- calls a second will use 100% of a whole -ES/9000-900] CPU
>
> Which re-raises the questions:
> What is the impact of the VM platform on MVS TCP/IP performance?

What's your definition of "the platform"?  My impression is that
IBM considers it to be the "MVPMAIN" code, and does NOT include
the VMCF/IUCV support.

> Is MVS TCP/IP doomed to be a lethargic protocol as long as the
> platform is around?

It's not just the platform.  Every instruction and system call
costs.  If they aren't doing something useful why are they
being executed?

> I have not seen any real numbers quantifying what the improvement
> would be if TCP/IP were re-written to run natively on MVS.

"re-written to run natively on MVS" is *vastly* different than
"no platform".

As for numbers, I've previously sent these:

> A MVS QSAM PUT macro (MACRF=PM) takes about 5 usec of CPU, but
> doesn't cross address spaces nor privilege boundaries.

At 5 usec that's 200,000 PUTs/second.  At 512 bytes each that's
100+Mbytes/second, more at higher record sizes.

Since there's no privilege boundary crossing time nor TCP/IP
checksum time included, this is an estimate of an upper bound for
512 byte records.

> A locally written general cross address space service can send
> 10,000 2048 byte records between address spaces in 2 seconds of
> CPU time counting *all* the time in both address spaces
> (including SRB time).  It's about 50% SRB time, so the one side
> task time would be:

Now this is closer to what VMCF/IUCV is doing, only without the
VM VMCF/IUCV interface.  This is 20Mbyte send in 2 CPU seconds
(ES/9000 CPU), so thats 10Mbyte/second.

The bad news is that this doesn't include the TCP/IP protocol,
TCP/IP checksum, nor any I/O (or other protocol layers)
processing.

The good news is that:

1. This is *NOT* an optimized product.  It's possible it could
   be done faster.

2. This measurement includes the overhead of *TWO* user
   interfaces (privilege boundary crossings).  Conceptually,
   TCP/IP integrated into MVS only needs one.  This might halve
   the time.

3. The I/O might not take all that much CPU (assume the buffers
   are already fixed etc).

4. The TCP/IP protocol processing has been measured at
   about 300 instructions a packet (protocol performance
   measurements, non-IBM hardware & systems).

This implies a lower bound around 10Mbyte/second (for 512 byte
packets?  Large packets would be faster..)

So I'd wouldn't be surprised if a one CPU version could do FDDI
speeds (12.5 Mbyte/sec).

Is there any hardware which will connect to a ES/9000 which will
actually do that?  (Remember that wire channels won't go past
4.5Mbytes/second, so the interface would have to be ESCON
connected *and* support FDDI or something faster).

Anyway, even without faster hardware you'd save the CPU for
running other things.

PS: How fast is all of this?  IBM says that V2 is 30% faster than
    V1 and the use of the "offload" box is again 30% faster than
    just V2.

    I think by the "30% faster" they mean uses 30% less CPU.  So
    that's (100-30)/100 = .7 of the CPU which is 1.43 times
    faster.  The target I'd keep in mind is 100x faster than the
    current V2 TCP/IP.  Might or might not reach it, but I feel
    that it's the right target to focus on.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU