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

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

1952.0. "response times" by NCBOOT::HARRIS (oooppps) Fri Dec 11 1992 21:16

The customer has asked me for some reponse time figures.  This is the
scenerio -

        ALL-IN-1 2.4  VMS 5.4-2  MR 3.2

Messages are sent from PROFS to SOFTSWITCH to MESSAGE ROUTER to ALL-IN-1 node
and then delivered to users.  What we're trying to measure is the time from
MR to ALL-IN-1.  The sender and Fetcher run every 7 minutes and 8 minutes.

The last 5 runs of the sender and fetcher average to 1 minute for sender and
2 minutes for fetcher.

Customer is using 7.5 minutes to go from SSW to MR.  They had been using 10
minutes for time from MR to ALL-IN-1.  The sender/fetcher used to run every
10 minutes.

So, I guess my question is if the sender/fetcher run every 10 minutes (for
example) and the time from SSW to MR is 7.5 minutes then -
the longest time that it should take for a message to go from SSW to MR to
ALL-IN-1 is 17.5 minutes. This is just a "best guess" effort.
I would assume that this would also depend on the actual number of messages
in the sender and fetcher and the size of the messages.

This number is used as a baseline. Actual message delivery times are compared
to the baseline (in this example 17.5 minutes for 1 way delivery). Those 
abovethe baseline are "bad" and those below the baseline are "good".

I hope this doesn't sound more complicated than it is.

	thanks - ann
T.RTitleUserPersonal
Name
DateLines
1952.1FORTY2::ASHGrahame Ash @REOMon Dec 14 1992 14:136
Don't say 'the longest time it can take is . . .'!! It can ALWAYS take longer!

For instance, by default, the fetcher and sender will not run at the same time 
- so you may have to wait for more than one fetcher submission. 

grahame