(RADIATOR) Inconsistant Accounting with MySQL

Michael Priest Michael at hotlinesupport.com
Wed Mar 15 19:20:59 CST 2006


After looking at some of the accounting data generated by radiator I was
noticing what seemed to be very strange accounting for generic data
usage some counters seemed to stop at exactly 2048MB (2147483647 Bytes
it isn't happening all the time I have seen records exceed 2048mb and
Create Giga-Word Values how ever this seems to be happening frequently
and I just don't understand why. 

 

I've tracked down the following information:

 

 

Part of the Radiator log which indicates my periodic update from our LNS

 

      Acct-Session-Time = 137632

      Acct-Input-Octets = 259766795

      Acct-Output-Octets = 4001408988

      Acct-Input-Packets = 3056688

      Acct-Output-Packets = 4747255

      Acct-Status-Type = Alive

 

Thu Mar 16 11:37:16 2006: DEBUG: do query is: 'insert into ACCOUNTING
(ACCTDELAYTIME,ACCTINPUTOCTETS,ACCTOUTPUTOCTETS,ACCTSESSIONID,ACCTSESSIO
NTIME,ACCTSTATUSTYPE,FRAMEDIPADDRESS,NASPORT,TIME_STAMP,USERNAME) values
(0,259766795,4001408988,'00000005',137632,'Alive','ip.ip.ip.ip',3,114246
9436,'xxxxxxx at xxxxxx')':

 

Data on our LNS Shows much the same to above.

 

LNS-SYD-01#sh caller user xxxxxxx at xxxxxx

 

  User: xxxxxxx at xxxxxx, line Vi5, service PPPoVPDN

        Connected for 1d14h, Idle for 1d14h

  Timeouts:    Limit     Remaining Timer Type

               -         -         -         

  PPP: LCP Open, multilink Closed, CHAP (<-), IPCP

  IP: Local ip.ip.ip.ip, remote ip.ip.ip.ip

  Counts: 3085920 packets input, 262376691 bytes, 0 no buffer

          0 input errors, 0 CRC, 0 frame, 0 overrun

          4787632 packets output, 4027949729 bytes, 0 underruns

          0 output errors, 0 collisions, 0 interface resets

 

 

 

Now all of that matches up except for the odd time difference except for
a little bit of time difference between the results, now this is where
it just doesn't make sense once I look in the database I see the
following. This record below is exactly the same as the log above
indicates should have been inserted.

 

mysql> SELECT USERNAME, TIME_STAMP, ACCTINPUTOCTETS, ACCTOUTPUTOCTETS
FROM `ACCOUNTING` where username = 'xxxxxxx at xxxxxx' and time_stamp =
'1142469436';
+--------------------+------------+-----------------+------------------+
| USERNAME           | TIME_STAMP | ACCTINPUTOCTETS | ACCTOUTPUTOCTETS |
+--------------------+------------+-----------------+------------------+
| xxxxxxx at xxxxxx     | 1142469436 |       259766795 |       2147483647 |
+--------------------+------------+-----------------+------------------+
1 row in set (0.00 sec)
 
As you can see the Output-Octets are completely wrong, and if I pull
back the previous few Accounting updates I see this. 
 
+--------------------+------------+-----------------+------------------+
| USERNAME           | TIME_STAMP | ACCTINPUTOCTETS | ACCTOUTPUTOCTETS |
+--------------------+------------+-----------------+------------------+
| 0294519111 at hotline | 1142469436 |       259766795 |       2147483647 |
| 0294519111 at hotline | 1142468585 |       254452546 |       2147483647 |
| 0294519111 at hotline | 1142467647 |       248165578 |       2147483647 |
| 0294519111 at hotline | 1142466773 |       241210305 |       2147483647 |
| 0294519111 at hotline | 1142465842 |       236030193 |       2147483647 |
| 0294519111 at hotline | 1142464941 |       230506303 |       2147483647 |
| 0294519111 at hotline | 1142464024 |       224926037 |       2147483647 |
| 0294519111 at hotline | 1142463160 |       221474014 |       2147483647 |
| 0294519111 at hotline | 1142462264 |       219840952 |       2147483647 |
| 0294519111 at hotline | 1142461335 |       218378041 |       2147483647 |
| 0294519111 at hotline | 1142460418 |       217118361 |       2147483647 |
| 0294519111 at hotline | 1142459507 |       215858539 |       2147483647 |

+--------------------+------------+-----------------+------------------+

 

 

Any help on this would be appreciated.

 

Cheers,

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20060316/799c7eeb/attachment.html>


More information about the radiator mailing list