| 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 |
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.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 4956.1 | Code? | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu Apr 17 1997 17:02 | 10 |
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.2 | Don't know if this applies to EV56? | KEIKI::WHITE | MIN(2�,FWIW) | Thu Apr 17 1997 18:03 | 15 |
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.3 | COMEUP::SIMMONDS | loose canon | Thu Apr 17 1997 22:05 | 6 | |
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.4 | Just a possibility not a guarantee | KEIKI::WHITE | MIN(2�,FWIW) | Fri Apr 18 1997 15:35 | 1 |
| 4956.5 | Problem found, tracked down to application! | RULLE::KLASSON | Sven-Olof Klasson @GOO | Fri Apr 25 1997 12:34 | 15 |
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
| |||||