Tops20 TVT performance improvments


William (BILLW@SU-SCORE.ARPA)
Fri 21 Feb 86 04:22:24-PST


BUG: Under certain situations, throughput on TOPS20 TVTs drops to
        approximately 0 for long periods of time. I believe that
        the problem got worse with v6.1, and may be the reason
        that the TVT SMTP server doesn't work well under 6.1.

Reproduce by:
        I think this shows up best when trying to run a dialout
        type program while logged in on a TVT. However, the
        following program will exhibit the problem too:

        start: movei 6,^d32
        loop: movei 1,"%"
                pbout
                movei 1,^d30
                disms
                sojg 6,loop
                haltf

Diagnosis:
        The tops20 TVT scanner attempts to send characters that are
        part of "echoing" immediately. It's criteria for recognizing
        "echoes" is that there be fewer than 8 characters in the
        terminal output buffer. Since the TCP process runs at a very
        high priority, it will probably get to look at the TTY output
        buffers if the user process blocks for any reason. In the
        case above, therefore, there is a good chance that 32
        separate 1 byte packets are queued. And there are certainly
        lots of machines that don't like to receive 32 almost
        back-to-back short packets. This leads to many retransmissions
        and excessive use of CPU time on both systems, not to mention
        any gateways that might be in between them.

Fix: Make TOPS20 TCP pickier about what it considers echoing.
        In addition to there being only a few characters in the
        buffer, have it insist that the retransmission queue for
        that connection be empty. (If a person types faster than
        the Round trip times, it won't hurt to have his echoing
        clumped together a little anyway.) This is much simpler
        than having the TCP repacketize retransmissions.

        By the way, it turns out that this is "reinventing the
        wheel", as almost identical suggestions were made by
        John Nagle in RFC896. It is surprising, however, that
        this makes such a difference even on local ethernets
        with no gateways involved. Admittedly, tops20's
        scheduling of TCP provides a pathological case!

        The relevant code is in TVTSRV, just before OPSCA7:
        [This is from 6.1 sources. There should be an easy
         equivalent for 5.x. From SCORE:: <6-1-monitor>TVTSRV.MAC ]

         SKIPA T4,T1 ; Yes. Get PZ to call SNDTVT
          JRST OPSCA7 ; No.
IFE STANSW,<
        MOVX T1,^D200 ; The function to queue for PZ if a lot
        MOVX T2,<XCDSEC,,ENCPKT> ; to send - wait a bit, maybe more
        CAIGE T4,^D8 ; Less that 8 is echoing so
         MOVX T2,<XCDSEC,,FRCPKT> ; Force it now
        CALL (T2) ; See Note above
>;IFE STANSW
IFN STANSW,< ;;; there is not going to be any more output if all of the
                ;;; output buffers are full, so send packets immediately.
        CALL TTSOBF ;output buffer full?
        CAIGE T4,^D8 ; or looks like echoing.
         SKIPA T2,[XCDSEC,,FRCPKT] ; Force it now
          MOVX T2,<XCDSEC,,ENCPKT> ; otherwise wait for more data
        LOAD T1,QNEXT,<+TCBRXQ(TCB)> ;check if retranmission queue empty?
        CAIE T1,TCBRXQ(TCB) ;skip if RXQ empty
        CAIL T4,^D8 ; or if a large packet
         TRNA
          MOVX T2,<XCDSEC,,ENCPKT> ; otherwise wait for more data
        MOVEI T1,^D200 ; for a couple hundred millisecs.
        CALL (T2) ;call appropriate packet routine.
>;IFN STANSW
OPSCA7: MOVE T2,LINADR ; Restore address of terminal block
OPSCA8: CALL ULKTTY ; Decrease reference count, OKINT
-------



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:35:40 GMT