Thoughts on 'performance' of ACS

[Manny Veloso]

ACS performance is an interesting subject. Over the years I’ve found that there are really only three metrics or considerations for “performance” that matter in real life.

1. How long does it take to apply a setting to a device?
2. how long does it take to get information from a device?
3. given a population of devices informing continuously how long does it take for a device in case #1 or #2 to come into the ACS?

#1 is pretty simple. If an operator changes a setting, how long does it take for that setting to make it down to the device in question?

#2 is also simple. If you want to see the LAN hosts, how long does it take for the ACS to get and display that information from a device?

#3 is more existential. Given a population of devices, X number of them will attempt to inform to the ACS every second. How long does it take the ACS to handle all the devices? How do you ensure devices in case #3 don’t interfere with #1 and #2?

A corollary to #3 is: if every device attempted to inform at once, due to a power failure or DSLAM issue, how long would it take for the ACS to handle all the informs so the CPE population goes back to its steady-state and #1 and #2 can occur in an acceptable amount of time

Real world example of #1: if I’m trying to change X devices and my time window is Y minutes, how many devices can I operate on during that time window? This would be, say, a firmware update.

Real world example of #1: I change the WiFi SSID, and need that to get to the device while the customer is on the phone.

Real world example of #2: the customer calls in and I need to pull fresh data off the device to see what’s going on. How long will that take?

#1 and #2 have to occur in a reasonable amount of time, possibly while #3 is occurring.

There may be other ways to look at ACS performance, but these factors seem to be the most practical one. You can’t do #1 and #2 in a reasonable timeframe if you can’t handle #3 well, but really, #3 is protocol noise. Most of the time the data in an INFORM or BOOT doesn’t change, but you still have to check to see if the WAN IP changed…or record that the device rebooted or is still alive.

-- 
Manny Veloso

Sr. Solutions Engineer
Smartrg.com










On 9/6/15, 8:46 PM, "Users on behalf of Prashant Upadhyaya" <users-bounces at lists.genieacs.com on behalf of praupadhyaya at gmail.com> wrote:

>Hi guys,
>
>I was wondering how to define the performance of an ACS in terms of
>its ability to handle all those CPE's out there.
>
>Eg. should it be defined as the time taken to complete a typical
>Inform cycle during BOOT or BOOTSTRAP.
>Something like --
>TimeStart
>TCP connection initiation
>CPE Informs with BOOT
>No Firmware upgrade
>GPV
>SPV
>SPA
>.
>.
>TCP connection end
>TimeEnd
>
>Clearly an ACS is 'fast' if the difference between the TimeStart and
>TimeEnd is minimum. Further, the time difference makes sense when 'N'
>CPE devices attack the ACS simultaneously. Then cumulatively, to
>services those N CPE's, the ACS will take a total time say T.
>Can we then say that the performance of ACS is defined by the
>parameter N/T which represents a throughput of servicing 'CPE's per
>second' by the ACS ?
>
>Or am I clearly off the mark and there is a more meaningful way of
>defining the performance of an ACS, kindly do share with your
>experience.
>
>Regards
>-Prashant
>_______________________________________________
>Users mailing list
>Users at lists.genieacs.com
>http://lists.genieacs.com/mailman/listinfo/users