| >44 servers took consistently less than 9 seconds.
In my opinion these are quite good stats. Keep in mind that in order
for the table to be created with an entry of either available or
unavailable, the host has to do a `mop loop' to each of the servers. So
depending on the network utilization, the response may take longer.
I have just done a quick test here in the CSC, and for two server. One
of the server being unavalable, and the other being available. The
results were as follows.
Unavailable Server
15 Packets sent by TSM host send code 5, request ID frames.
Available Server
5 Packets sent by TSM host.
Packet 1 = code 5, request ID
Packet 2 = code 13, reserve console
Packet 3 = code 5, request ID
Packet 4 = code 15, release console
Packet 5 = code 5, request ID
Also dont forget that in between these you have the server responses
which are as follows.
host -> server = code 5, request ID
server -> host response
host -> server = code 13 request console
host -> server = code 5, request ID
server -> host response
host -> server = code 15, release console
host -> server = code 5, request ID
server -> host response
Quite a lot of bandwidth contention to go through here.
Regards
Steven F
UK CSC
|
| > The chance of the network being a bottleneck are very low; Ethernet has
> the bandwidth to switch those 10 packet to about 1000 terminal servers in
> a single second.
Assuming of course it doesn't have to contend with collisions, delays, and
retransmissions caused by other systems using the same Ethernet.
|