[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::lat

Title:LAT notes conference
Notice:To reset your notebook -> SET SEEN/BEFORE=13-OCT-1992:01:00
Moderator:STAR::KOJNOK
Created:Mon Mar 10 1986
Last Modified:Fri May 23 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4961
Total number of notes:19526

4956.0. "LAT data stuck for 10-20 sec in VMS/AXP V6.2-1H3" by RULLE::KLASSON (Sven-Olof Klasson @GOO) Wed Apr 16 1997 14:50

Hi,

A customer see a problem with LAT on OpenVMS/AXP V6.1-1H3. He has written a
application that communicates with some devices using a simple character
oriented protocol. The device is connected to a DS300 (V2.2 BL44G-3B) port.
The application on the VMS system uses a LTA application port and connects
to the DS300 port. The amount of data transfered is small (40 byte messages
with 2 seconds interval).

The problem is that data is quite often delayed somewere in VMS for 10-20
seconds before the QIO read returns the data. In a LAN sniffer trace that
decodes the LAT packets for me I can see that data is sent from the DS300 to
VMS and the VMS system acknowledge the data at once. I see no problem at all
with LAT in the LAN sniffer trace.
I have compared timestamps from the LAN sniffer trace with debug printouts
from the application. Here I can see that the data is delay in the VMS system.
The QIO read is issued. And then it can take 10-20 seconds until it returns
tha data (wich I have seen delivered to the system in the LAN sniffer trace).

When the data is given to the application, all messages that has been 
buffered somewere in VMS is delivered (subsequent QIO reads returns data at 
once). The QIO that returns the last data buffered usally has status "overrun"
in it's IOSB.

It does not seem to be a problem with resurses in the system there is plenty
of free memory in nonpaged pool. It's a Alphaserver 1000A with 300Mhz CPU.

The same application runs fine on a VAX/VMS V5.5-2 system against the same
DS300.
I'm aware of the ALPLAT01_062 patch but none if the problems fixed there
is close to this.

I attach information about the LTA terminal in VMS and the DECserver300.

    
Is there any known problems that could explain this?

Any suggestions how to best troubleshoot this and verify if it is a 
LAT problem or not?

Thanks,
Sven-Olof Klasson, CSC Sweden



Terminal: _LTA214:    Device_Type: Unknown       Owner: No Owner
   Input:   9600      LFfill:  0      Width:  80      Parity: None
   Output:  9600      CRfill:  0      Page:   24
Terminal Characteristics:
   Interactive        Echo               Type_ahead         No Escape
   No Hostsync        TTsync             Lowercase          No Tab
   Wrap               Scope              No Remote          No Eightbit
   Broadcast          No Readsync        No Form            Fulldup
   No Modem           No Local_echo      No Autobaud        Hangup
   No Brdcstmbx       No DMA             No Altypeahd       Set_speed
   No Commsync        Line Editing       Overstrike editing No Fallback
   No Dialup          No Secure server   No Disconnect      No Pasthru
   No Syspassword     No SIXEL Graphics  No Soft Characters No Printer Port
   Numeric Keypad     No ANSI_CRT        No Regis           No Block_mode
   No Advanced_video  No Edit_mode       No DEC_CRT         No DEC_CRT2
   No DEC_CRT3        No DEC_CRT4        VMS Style Input


DECServer 300:
==============
DECserver 300 V2.2 BL44G-3B  LAT V5.1  ROM 1.0.6   Uptime:  31 22:45:38
Address:   08-00-2B-1D-08-80   Name:   SERV2              Number:     0
Identification:
Circuit Timer:            30           Password Limit:            3
Console Port:              1           Prompt:               Local>
Inactivity Timer:         30           Queue Limit:             100
Keepalive Timer:          20           Retransmit Limit:          8
Multicast Timer:          30           Session Limit:            64
Node Limit:              200           Software:          SH1601ENG
Service Groups:   0
Enabled Characteristics:
Announcements,  Broadcast,  Dump,  Lock

DECServer port 14 / lta214:
==========================
Port 14: (Remote)                      Server: SERV2
Character Size:            8           Input Speed:               2400
Flow Control:           None           Output Speed:              2400
Parity:                 None           Signal Control:        Disabled
Stop Bits:                 1
Access:               Remote           Local Switch:              None
Backwards Switch:       None           Name:                   PORT_14
Break:                 Local           Session Limit:                4
Forwards Switch:        None           Type:                      Ansi
Default Protocol:        LAT
Preferred Service: None
Authorized Groups:   0-255
(Current)  Groups:   0-255
Enabled Characteristics:
    
T.RTitleUserPersonal
Name
DateLines
4956.1Code?XDELTA::HOFFMANSteve, OpenVMS EngineeringThu Apr 17 1997 18:0210
   I will assume you have checked the process quotas, and the
   network counters.

   What do the sys$qio[w] calls look like?  (Some *small* example
   source code, or a *small* standalone reproducer, would be quite
   interesting...)

   Can you get a description of this simple character-oriented
   protocol?

4956.2Don't know if this applies to EV56?KEIKI::WHITEMIN(2�,FWIW)Thu Apr 17 1997 19:0315
                  AST Delivery/Various Bugcheck/Process Hang
    \              Fixes; OpenVMS Alpha V6.2-V7.0; ALPSYS06_070
    
       Kit Applies To:  OpenVMS Alpha V6.2, V6.2-1H1, V6.2-1H2, V6.2-1H3,
                                        V7.0
    
    \              AST Delivery/Various Bugcheck/Process Hang
    \              Fixes; OpenVMS Alpha V6.2-V7.0; ALPSYS06_070
    
    
      o  On an EV5 system, it is possible for some ASTs (Asynchronous
         System Traps) to be delivered to their process in a different
         order from that in which they were queued.
    
    					Bill
4956.3COMEUP::SIMMONDSloose canonThu Apr 17 1997 23:056
    Re: .2
    
    AlphaServer 1000A 5/300 is a 'straight' EV5 I believe.. so your
    suggestion is probably right on the mark.. well spotted!
    
    John.
4956.4Just a possibility not a guaranteeKEIKI::WHITEMIN(2�,FWIW)Fri Apr 18 1997 16:351
    
4956.5Problem found, tracked down to application!RULLE::KLASSONSven-Olof Klasson @GOOFri Apr 25 1997 13:3415
    Hi,
    
    The problem has been found. It was a problem in the application written
    by a software house.
    They did not tell me exactly what the problem was, but I think their
    application got stuck for a while in a AST routine somewhere. Thus
    delaying delivery of the completion AST when the QIO read had got it's
    data.
    
    This was seen on a Alphaserver1000A. Don't know if it has a EV5 CPU.
    Anyway, after they fixed their application everything was fine.
    
    Thanks for the help.
    Sven-Olof