Hello Folks @ 3000-l,

Re: Spool Nazi: "The Saga Continues"

------------------------------------------------------------------------
> >Seems UDP is single-threaded on the HPe3000.
>
> Hmm... this doesn't make any sense. UDP is a connectionless protocol,
> meaning that unlike TCP, the lower levels of the networking stack
> don't know or care about responses to UDP packets. So there's nothing
> to "thread" at the network level.
------------------------------------------------------------------------

UDP on the HP-e3K is not a system process, it is a port server procedure.
This can be seen in debug...

:netcontrol status;prot=udp

PROTOCOL STATUS : TUE, JUL 10, 2001, 10:36 PM
PROTOCOL STARTED : FRI, JUL  6, 2001, 11:38 AM

PROTOCOL NAME    : UDP

TRACE MASK       : $00000000

GPB ADDR INFO    : ENTRY $467D08B0
TRACE INFO       : ID : $00000000
PORT ID          : $FFFFFECC
CONTEXT ADDR     : $B.81CF7000

:debug
DEBUG/iX C.25.06

HPDEBUG Intrinsic at: a.01086bf8 hxdebug+$e8
$1 ($49) nmdebug > use datinit.dat.telesup
Type "macstart" to load Macros & Symbols.

$b ($49) nmdebug > macstart ,"1"

$113 ($49) nmdebug > port_info $FFFFFECC

Information for Port : $fffffecc

Port Type        : Message Port
Port is PFP      : FALSE
Purge Pending    : FALSE
Access Count     : $0
Owner Pin        : $7ffd (Not owned by a process)
Ports PFP Port   : $ffffffe4
Global Port Desc : $800c18d0
Freeze Desc      : $00000000

Subqueue Information

Highest Subqueue # : $f
Enabled Subq Mask  : $ffffffff
NonEmpty Subq Mask : $00000000
Number of Messages : $0

Server Information

Server Type         : Procedure Server
Server Invoked      : FALSE
Queued to PFP       : FALSE
PFP Priority        : $a
Deferred            : FALSE
Message Threshold   : $20
Server Procedure    : ?udp    <<<<====  This is the UDP port server
procedure
Server Data Area    : $b.81cf7000

Message Pool Information

Use Count     : $1
Message Size  : $4c
Pool Desc Ptr : $87708000

... and in this MPE internal implementation UDP is single threaded in
that pointers to received UDP messages are read and processed from a
message port one at a time.

No problem, the HP-e3K is fast and UDP is connectionless so the messages
are processed first come first serve and no delay.  The problem is with
the implementations of the ULP 'Upper level Protocols' which send a
protocol message in a UDP packet and at the ULP require a reply the in
the correct order.  In some of the ULP this is accomplished by masking
off UDP from processing further server request "send" until a reply is
received on a specific Subqueue.  This works fine until a reply is lost
due to a network outage and even then this design works fine until many
process's are queued relying on messages to be processed by the UDP
Procedure Server.

It might sound a bit difficult to believe that UDP was implemented in
this manor... but keep in mind UDP has not seen great usage on the 3000
until the last few years with the increased implementation of DNS Name
Resolvers, SNMP, Network Printing and the internal INETD procedures.
Even then 99.9 % of hp-e3k systems have never seen/reported a problem
with this UDP implementation.

The solution to the problem where a ULP is driving problems with UDP
backing up messages is to move the ULP request messages which require
replies to a separate "ordered" queue and to not mask off the UDP port,
but to continue to other process UDP request and when a ULP reply is
received match it up with the first ULP message in the queue and then
process the next ULP request pending in the queue.

The UDP on the HP-e3k is still single threaded in that pointers to UDP
messages are read and processed by the UDP port server procedure one at a
time, but now we have eliminated the ULP request/reply introduced delays.

P.S.  The patches which include this redesign to UDP and ULP are:

6.0: NSTGD70 for SR 8606104340
6.5: NSTGD66 for SR 8606104340
7.0: To-Be-Done

The most common symptoms to this problem are:

1) The entire Network Spooler will hang when 1 printer becomes unreachable
   over the network.

2) DNS Name Lookup request will hang when a DNS server becomes unreachable
   over the network.  This symptom is exasperated by applications which
   loop back when a name lookup request fails.

I hope this helps.

Regards,

James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *