Queries regarding Meraki Port Telemetry API

[DrunkBiscuit]

OperationID: getOrganizationSwitchPortsUsageByDeviceByInterval
Route: /organizations/{organizationId}/switch/ports/usage/byDevice/byInterval

I have been tasked to create alerts using port telemetry data, and I have settled on using the above end-point as it provides me with valuable traffic / bandwidth related data for the ports on my organization's devices. I have a few questions regarding this API though:

1. With regards to interval size, the smallest interval seems to be 300 seconds (5 minutes). Is there any way I can have a smaller interval, such as 180 seconds (3 minutes)?

2. When using this API, I am only interested in the latest available intervals. To achieve this, I have set t0 to be the current time - 300 seconds. However, the API returns me two intervals with the same start and end timestamps with differing bandwidth and data information. Why is this so?

3. My understanding of the information provided was that Bandwidth referred to the average traffic speed per second (in KB) while data referred to the total amount of data transferred. Thus, given a 300 second interval, I was expecting total data = 300 * total bandwidth, but given the image above you can see that it is not the case. May I know how these values are being calculated then?

Any help is greatly appreciated!

[sungod]

Afaik the published limits are fixed, if you try out of bounds values the result is typically an error, if there's not an error I wouldn't trust the accuracy of data anyway.

I've found when using short intervals that results can be inconsistent...

The call, the internal API service, and the underlying data source(s), aren't in sync, also I suspect some info is held in pre-determined internal time buckets, rather than a time-series of samples that can be dipped into between arbitrary start-end times, so that when you request a short period that doesn't exactly match bucket start-end, you get two returns - one from the bucket containing the start time, and one from the bucket matching the end time.

I'd say you are running up against edge effects caused by a combination of these things.

If you want to stick to the 'latest sample' approach, In this situation my suggestion is to assume the last sample (irrespective of number returned) is the 'truth', and go with that.

The chance of numbers being literally correct is low, stuff on the network takes time to reach Dashboard, there's imperfect device time sync, info gets delayed/lost due to uplink issues, etc.