| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4540.1 | Net_Response does output | CTHQ::WOODCOCK | | Sun Feb 14 1993 13:38 | 31 |
|
> My customer is looking for response time monitors for use with both
> DECnet and TCP/IP nodes. I am aware of the Assets package Response
> Time Monitor (for DECnet PIV). Is there a package or facility
> available for TCP/IP nodes which could be used/integrated/launched
> with DECmcc BMS?
> Also, does anyone know if there is a way to save the information which
> is display by the Response Time Monitor to a file. The customer would
> like to save this for reports, later analysis, etc.
Response Time Monitor? Is this Net_Response?? If it is, yes the latest version
of the tool does allow output to a file. It is crude but was good enough for
us to build a production level monitor in batch sampling response hourly to
multiple locations and storage into flat files. Good stuff cheap.
There are also a couple of IP monitors floating around EASYnet which use
ping. I don't belive they are in ASSETs so I'm not sure of the legal issues.
Also note that MCC V1.3 with the SCRIPT AM could be used somewhat easily to
build your own IP monitor with minimal effort/scripting. More good stuff
cheap cheap if they already own BMS and are going to upgrade. You'll also
most likely need UCX V2.0 if on VMS.
cheers,
brad...
ps. your customer is on the money and should definately pursue RESPONSE as
a managed metric for their protocols even if it costs a bit. This is the
single most important metric for network mngmt, don't know why more don't
pay attention to it.
|
| 4540.2 | Modify SOurces for PINGs? | DPDMAI::DAVIES | Mark, SCA Area Network Consultant | Sun Feb 14 1993 14:18 | 10 |
| RE: .1
Does the customer get the sources for Net_Response when it is
purchased? I ask because they might be interested in modifying it to
do IP PINGs as opposed to MOP Loopbacks.
Thanks,
Mark
|
| 4540.3 | The Example FM provides a response time ... | MOLAR::ROBERTS | Keith Roberts - Network Management Applications | Mon Feb 15 1993 08:11 | 7 |
| Check out the Example FM which comes with the DECmcc Toolkit.
It provides a response time; that is how long the entity took
to respond. Currently the Example FM 'rides ontop of' the Node4 AM ..
but some early-on experiments proved that it could provide this
information for *any* entity
/keith
|
| 4540.4 | probably no source | CTHQ::WOODCOCK | | Mon Feb 15 1993 08:39 | 25 |
| re: .2
I doubt the source comes with it but I don't know for sure.
re: .3
> Check out the Example FM which comes with the DECmcc Toolkit.
> It provides a response time; that is how long the entity took
> to respond. Currently the Example FM 'rides ontop of' the Node4 AM ..
> but some early-on experiments proved that it could provide this
> information for *any* entity
This would look like a good area for further development. As I said in the
previous note RESPONSE metrics are all important. Even more important than any
Rates/Averages/Stats that you could possibly provide for routers and links.
Response indicates NETWORK SERVICE LEVELs which is ultimately what the network
provider is offering to customers and a means to PROVE those levels. All other
metrics are used for detecting WHY or avoiding future service degradation.
My only caution to mcc developers if this were persued would be to ensure that
the metrics provided for IP are similar to those provided by PING because it is
the defacto standard from the customer base.
cheers,
brad...
|
| 4540.5 | Response time built-into the system | MOLAR::ROBERTS | Keith Roberts - Network Management Applications | Mon Feb 15 1993 09:47 | 18 |
| Brad - I imagine Response Time built into the system, perhaps via the PING
directive or what have you. If a particular technology can provide an accurate
implementation, then the AM would provide this functionality. In the case of
SNMP, the SNMP AM would use PING.
But - if a particular MM does not provide the Response Time directive, then
a higher level FM (kind of like the Example FM) would call the MM asking for
'all identifiers' .. The MM would then tickle the entity and the FM would
time how long it took. Using this concept of inheritance *every* MM will
have a Response Time directive .. and over time can implement the most
efficent technique for their technology.
The key here is to provide some rules (architecture) which describes how the
Response Time should work .. so it that it works consistently across every
entity. The Example FM provided a basis for this as working code .. also
we needed and example of writing an FM; seemed to solve two problems.
/keith
|
| 4540.6 | A response time "monitor" is part of DECnet | BLUMON::SYLOR | Architect = Buzzword Generator | Sun Mar 07 1993 17:45 | 20 |
| For Phase IV and Phase V you *should* have a built in response time
monitor already there. It's the application level loopback protocol.
I don't have the spec here at home, but the command for testing the
response time from node A to node B when A is a phase V node is
something like
LOOP Node A Application Loopback Destination Node=B
You can add on additional arguments to control how big the messages
looped are, how many messages to loop, etc. It returns data like when
the test began and when it ended.
Only problem I know is that Alarms/Historian/Exporter can't do their
tasks on actions, but there are ways around that.
Application loopback also works where A is a Phase IV node, but there's
less data returned.
Mark
|