how the AvgRouterDelay metric impacts SL and ASA, can any one explain this

[thanvi2001]

how the AvgRouterDelay metric impacts SL and ASA, can any one explain on this ?

I wanted to get a bit more understanding around that AvgRouterDelay metric and reassurance it doesn’t impact the results.

[Gergely Szabo]

Hi,

it's good to have good old Infomaker installed :-)

Actually, you need to take a look at this and this.

I opened the report caltpy21_hh and I can see that the SQL command behind takes the value of  AvgRouterDelayQ = sum(isnull(CTHH.AvgRouterDelayQToHalf,0)) (of course, CTHH being Call_Type_Half_Hour) but this number is not used in a calculation as far as I see.

G.

[Jameson Gagnepain]

Gergely,

While AvgRouterDelayQ isn't actually calculated directly in the Half-Hour report, AvgRouterDelayQHalf is still calculated when the rows are filled in the database, much like the ServiceLevelHalf field is. The DB Schema clearly states that the field is computed as:

AvgRouterDelayQToHalf = RouterQueueWaitTimeToHalf / RouterQueueCallsToHalf

If you were to write a report that summarizes by a different time period and you want AvgRouterDelayQ to remain accurate, it would be best to create the field in the query as something like:

AvgRouterDelayQ = SUM(ISNULL(CTHH.RouterQueueWaitTimeToHalf,0)) / SUM(ISNULL(CTHH.RouterQueueCallsToHalf,0))

-Jameson

[Gergely Szabo]

Hi, with all due respect: what?

G.

[Jameson Gagnepain]

My point is that it's an average... by definition, an average would be a computed field.

My example was to demonstrate that if you were creating a different report, say one that summarizes by day, you would have to manually compute AvgRouterDelayQ and not rely on the AvgRouterDelayQHalf field. Averaging AvgRouterDelayQHalf would give you an average of an average. An average of averages is mathematically different from a single average.

-Jameson