Possible root causes that I have seen within companies (corporations) and in the minds of some engineers:
Someone's calculations being wrong when polling data from network devices. Most network devices count the number of octets sent/received across an interface. 1 octet = 1 byte, and 1000 bytes = 1 kilobyte (keep reading).
When it comes to network traffic, you're supposed to calculate things based on a fairly obvious calculation formula
which a lot of people don't use. Instead, they try to do things like go off of the number of kilobytes (which means you've lost granularity). Note in the reference material how all the calculation methods involve multiplying by 8. As I said above: 8 bits to a byte.
This brings us next to the whole Kilobyte
thing. God I hate this. It didn't used to be this nonsensical. As a computer programmer, a kilobyte, to me, has always been equal to 1024 bytes (2^10). That's how computers calculate data on a bit level: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024. xkcd
took a jab at this too.
And I say all this knowing quite well that the prefix "kilo-" has always meant 1000 -- it's just that the term when used in computer usage has always referred to numbers with a base of 2. Anyway, purists complained/bitched that "kilobyte" should actually refer to 1000 bytes, not 1024 bytes like it had up until that point. Hard disk manufacturers I'm certain had a role in this too, since they began claiming (on packaging, manuals, etc.) that 1000 bits = 1 byte (when in actuality on the hardware itself it doesn't work that way -- this was done purely from a marketing perspective to allow hard disks to look like they have more capacity than they really do (2.4% more, in fact). As such, the term "kibi-" was created to refer to 1024.
And let's not forget this annoyance too
, which is common for folks unfamiliar with network devices or telecommunications (speaking in general terms here).
Anyway, the question then becomes: when converting into a unit like kilobytes, do you go with dividing by 1024, or do you go with dividing by 1000? When it comes to network devices, you're supposed to use 1000, and you're always supposed to measure things in bits.
When I say "measure things in bits", I'm referring to the fact that all calculations should be doing things in bits, and save the large-unit-conversion for the very end.
The difference, when given large amounts of data, can be pretty substantial. Some real examples. Note that I'll either round down or up based on if the fraction is >=0.5 or not (duh).
193859387214 bits = 24232423402 bytes
Now let's apply the stupid kibi vs. kilo ordeal:
193859387214 bits = 189,315,808 kilobits (1000)
193859387214 bits = 193,859,387 kibibits (1024)
193859387214 bits = 24,232,423 kilobytes (1000)
193859387214 bits = 23,664,476 kibibytes (1024)
193859387214 bits = 193,859 megabits (1000)
193859387214 bits = 184,879 mibibits (1024)
193859387214 bits = 24,232 megabytes (1000)
193859387214 bits = 23,110 mibibytes (1024)
193859387214 bits = 194 gigabits (1000)
193859387214 bits = 181 gibibits (1024)
193859387214 bits = 24 gigabytes (1000)
193859387214 bits = 23 gibibytes (1024)
Technically the difference between the two (1000 vs. 1024) is 2.4%, and the reporter says he's seen differing amounts of up to 20-30%, so maybe I'm barking up the wrong tree.
Maybe someone is doing something stupid like trying to calculate a volumetric total from bits-per-second, which is incorrect -- the latter will result in an average, while the former will result in an aggregate total. If they're doing this, shame on them. I have seen people do this before, and I have also seen open-source projects screw this up too, so it's not limited to just big corporations.
And finally, god forbid if they're using something like RRDTool to store the acquired data, in which case this would actually work in the customer's favour, since RRDTool averages all the data (every row in its database) every time a new row/data point is inserted. (Yes, there are ways to turn this off (use LAST instead of AVERAGE) but even that has had some bugs in the past if I remember correctly).
This whole thing reminds me of the Verizon billing fiasco
, where morons (even managers) couldn't understand the difference between 0.002 dollars and 0.002 cents.
There's also the possibility that the device AT&T is getting their statistics from is something that's post-encapsulation. I don't know if ATM is used or what, but that tends to add quite a bit around every single frame (think packet, just to keep it simple), so if they're not subtracting that from the usage, again, shame on them. Otherwise they need to increase their permitted monthly totals by the encapsulation percentage delta to make up for it.
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.