What is the exact OID you are collecting from?

Is the Cisco interface interval set to 30 seconds as well? By default, Cisco also has a 5-minute default interface averaging.

I have seen this on lots of traffic flows that should be very steady state (including T-1 interfaces that physically can not burst above 1.544 megabits per second).

I think you are right about the mean-1 vs. mean+1 comment. I was thinking that the actual value that is polled is only updated every “x” amount of time even though the traffic flow is consistent.

-Eric

I seem to recall in the cactid docs they recommend NOT polling more often than every couple of minutes, and this might be why. Another possible explanation is that there is in fact a periodic burst transfer which happens, say, every 10 seconds, and the poller is catching (mean-1) bursts in one window, and (mean+1) in the next. That would explain the weird up/down patterns. The last peak, though, makes me think otherwise, as does your “constant traffic” assertion.

Best guess:

I presume you’re running this from cactid, in which case I should also note that there is no guarantee in the C or PHP poller that your queries will be run exactly at the same time, or maybe even in the same order. Notice that the peaks happen every five minutes on even timess. That’s the default polling interval for most Cacti data sources! I bet the poller is taking extra long to finish the extra load on those five-minute intervals, and isn’t getting to this particular query until later in the sampling period. If it’s 5 seconds late, more traffic would accrue and that you’d see periodic variance with the same -/+ spike pattern.

Under those conditions, your best bet would be to either relax and stop trying to poll so often–the relative margin of error is way smaller at normal time intervals–or to move this particular job to a standalone poller where it won’t be interrupted.