Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Saw tooth can be very common when monitoring links with very few rate-adaptive flows that can exceed link bandwidth.
What happens, for example, a single rate-adaptive flow (e.g. FTP) "probes" available bandwidth by increasing its bandwidth utilization (the front side of the saw tooth). When such a flow exceeds available bandwidth, it generally sees packet drops and backs-off its bandwidth demand (the back side of the saw tooth). It continues to repeat this process.
Short lived rate-adaptive flows (e.g. HTTP) might also show a saw tooth as they increase their bandwidth usage but then finish their transmission.
Rate-adaptive flows that stop "probing" bandwidth before reaching link capacity, may show as square tooth.
Non-rate adaptive flows may show as irregular bandwidth usage if they are variable bit rate (e.g. video) but if constant bit rate (e.g. VoIP g.711) will show as a flat line.
Lastly, if you have a mix of traffic, graph can be very irregular as it shows the aggregation of all the concurrent data flows.
