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 18: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 19: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 23: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 16:35 | 1 |
4956.5 | Problem found, tracked down to application! | RULLE::KLASSON | Sven-Olof Klasson @GOO | Fri Apr 25 1997 13: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 |