[RADIATOR] Processing delay in Diameter

Kaspar Jasper kasjas at hot.ee
Thu Mar 26 07:45:51 CDT 2015


p{padding:0;margin:0;} Hello,

My Diameter peer sometimes complains about Diameter timeouts, 
which is 5 seconds. Debugging leads me to the interesting detail - 
Diameter messages sometimes are processing with delays in Radiator.
  
For instance, Radiator's server Wireshark capture:
No.    Time               Source         Destination   Protocol Length Info
231521 09:00:58.997242000 xxx.xxx.xx.xx  xxx.xxx.xx.xx DIAMETER
 1622   cmd=Accounting Request(271) flags=RP-- appl=Diameter Base 
Accounting(3) h2h=253e8654 e2e=253e8654
  
But in the Radiator this request appears 5.2 second later:
Thu Mar 26 09:01:04 2015 029052: DEBUG: StateMachine::event event R-Rcv-Message R-Open -> R-Open
Thu Mar 26 09:01:04 2015 029532: DEBUG: mm2.xxx.xxxx.ee DiaPeer::recv
Thu Mar 26 09:01:04 2015 031768: DEBUG: mm2.xxx.xxxx.ee <- sgc2.xxx.xxxx.ee recv_v1msg:
  Code:           271 (Accounting)
  Version:        1
  Flags:          0xc0 (RP)
  Application ID: 3 (Base Accounting)
  Hop-to-Hop ID:  624854612
  End-to-End ID:  624854612

Despite the fact that further processing is very fast, the Diameter timeout has already expired and peer send retry request, which cause a duplicate records in the SQL.
  Used Radiator 4.14 version. Slackware 14.0 (3.2.45 #1 SMP x86_64 Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz). My Diameter config:
  
LogStdout
  LogDir    /var/log/radiator
  DbDir    /etc/radiator/raddb
  LogFile    %L/logfile-fe-sbg-%Y%m
  LogMicroseconds
  Trace         3
  FarmSize    30
  AuthPort
  AcctPort
  DictionaryFile %D/dictionary
  DiameterDictionaryFile %D/diameter_attrs.dat
  
  <ServerDIAMETER>
      OriginHost mm2.xxx.xxxx.ee
      OriginRealm xxx.xxxxx.ee
      SupportedVendorIds    DictVendors
      PostDiaToRadiusConversionHook file:"%D/dia_to_radius_hook_sbg.pl"
  </ServerDIAMETER>
  
Normally there's no delays (Diameter service response time less than 
half of second), but 2-3 times per hour it can be 5-7seconds delay.
Is it possible to explain why this happened and how to fix or at least debugging it?
  
br,
Arthur
  
  
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20150326/063dcfa8/attachment.html 


More information about the radiator mailing list