I think the 4GB overflow has become a bit more likely - a friend who was using my script until earlier this year when he moved and "upgraded" to a Thomson (which broke the script, but he didn't bother mentioning it
) has had a similar experience to yours. I sent him the "ip iflist" and modified regexp required by the Thomson (I think he said his new modem is an ST5x5v6), and he gets these:
RX 1,310,535,716 Bytes / (1024 * 1024 * 1024) = 1.22 GB from CLI and 5.21 GB from web page.
Exactly 4GB difference... Now there's a surprise...
TX 851,830,849 Bytes / (1024 * 1024) = 812.37 MB from CLI and 811.75 MB from web page.
Again, essentially matching.
I wonder if there is really an overflow, or is the apparent 16 GB error just a coincidence? If there was an overflow, how does the web interface know what to do? It should never display > 4 GB.
That is what's annoying the **** out of me, actually - if it knows, why can't it tell us?
I assume that they have an overflow counter that gets increment appropriately, and the web interface is adding it back in to compensate. Or even another 32-bit word they were too lazy to include in the CLI output? Can you see a "4" in any of the output anywhere?
32 bit unsigned max number is 4,294,967,295. If the RX counter overflowed 4 times, then the error should presumably be:
4,294,967,295 * 4 = 17,179,869,180 Bytes / (1024 * 1024 * 1024) = 16 GB
My thoughts exactly.
My Web interface currently (23 June 17:00) shows:
[interesting numbers removed for brevity]
So my router's RX/TX figures seem to bear no resemblance to the ISP's figures. Neither from the router's web interface, nor from the CLI figures.
Dunno what to think.
Has (a) your router been reset, or (b) your billing period restarted at the ISP? Either of these will throw actual values off.
The script I had built for the other guy used "atm debug gstats clear=enabled" to get the data increments, which was then loaded into an Access database that he constructed to make pretty graphs etc.
He says his recollection is that it was pretty close to the ISP, and this would have covered a period when he was on an unlimited plan, so we're not talking small volumes here
So maybe the only way round this is to force the router to reset the counts whenever one of them approaches 4GB, or keep track of incrementals, rather than the actuals? BTW - did you find a way to reset the "ip iflist" counts without resetting the router?
I need to add the router uptime to my logging so I can see when there's been a reset...
If RX/TX figures are limited to 32 bits in ST546's CLI, maybe your newer TG585 won't suffer from it.
Will be interested to hear how your monitoring goes, and if you can line up what your router says with what your ISP says.
The ST5x5v6 seems to have the problem, so I'm not too hopeful for the v7, but it'd be nice. Unfortunately, by coincidence my router reset itself while I was playing with other commands trying to get more details (specifically "service settime" if it matters - looking for the uptime) so I'm back to zero on the counts again. Since I get throttled to dial-up speeds at 20GB, I'm not too keen on blowing my cap in the interests of science
The last day of my billing period is the 4th, so if I remember I'll keep an eye on it round then (I can go over the 20GB in the last 24 hours without being penalised. Not that I'd ever exploit a hole like that, of course...)
I am logging both the CLI and web numbers now (60 second intervals until I see how much disk it takes up, running on the HTPC which is usually on 24x7), so I'll have a good set of data to work with. I was considering scraping the ISP website, but the most resolution I can get from there is daily anyway, and it's always available, so I probably won't bother.
I'm sure we'll be able to confirm or deny the rollover problem at least, even we can't find a nice solution. I'll keep updating here if I find anything new...
Andrew