[Users] Delayed signalling?

[Bogdan-Andrei Iancu]

Jiri Kuthan wrote:

>if you happen to have a PCAP file with the incident, let me please know.
>
>-jiri
>
>p.s. even if you didn't tweak timers, the results may be suboptimal because
>the software version you are using is having rather indeterministic timer subsystem.
>For example, the recent measurements  (http://www.iptel.org/ser/doc/performance)
>show quite scattered server responsiveness under high load. (Note though that
>the measurement results were achieved in a best-effort manner based on the tester 
>knowledge and understanding of openser and that the result are not officially confirmed 
>by the OpenSER project.) Whether it is indeed the cause is not certain though
>-- this looks really like a stealth bug.
>
>  
>
it is not a bug - the timer's behaviour is quite difficult to predict on 
real traffic platforms and experience showed that it has nothing to do 
with the patterns observed during lab stress tests. Personally, I'm very 
keen when it comes to finding bugs and as a matter of fact I did 
submitted a full bug report for the timers in the latest SER stable 
version, couple of weeks ago. I also checked and this bug was not 
present in non of the OpenSER versions.

regards,
bogdan


>At 15:58 15/12/2006, Max Gregorian wrote:
>  
>
>>Thanks very much for all the replies. I shall try and post a config and traces as soon as I can get them from the office.
>>
>>Some more information, if it helps:
>>
>>Server specs:
>>- HP ProLiant DL360 G4 (1U rack servers)
>>- 3 GHz processors (800 MHz FSB)
>>- 1 GB RAM
>>- 10K rpm SCSI HDs (in a RAID 1+0 Mirror)
>>
>># Servers are running OpenSER 1.0.1 (no-TLS).
>># Servers are listening on 3 ports (both tcp and udp for each port), so in openserctl ps I am seeing 4 child processes for each port.
>># Servers running CentOS Linux 4.3
>># MySQL installed when CentOS was installed but not running and not currently being used with Openser.
>>
>>
>>Things I have pretty much managed to eliminate are:
>>1. It's doesn't seem to be hardware. The specs for the servers are more than sufficient I think.
>>2. It doesn't seem to be traffic/load related as I see these problems on 2 brand new servers I have just installed with no traffic on them. However, it does seem to get worse with more traffic.
>>3. I don't think it's database related as I have deliberately not configured mysql on any of the servers in case of database performance.
>>4.  I haven't played with the timers at all so far.
>>5. I haven't configured nscd yet, but as far as I can tell it's not caching DNS.
>>6. Though openser is listening on tcp ports as well, currently only the udp ports are being used as most of our customers use hardware phones. In any case, I haven't as yet seen as requests on tcp.
>>7. I am not sure it is DNS as in the tests I ran I sent requests directly to the external IP of the server and not to the domain name it is responsible for. Also the test servers are now only responsible for one domain, but in future will have more than one. 
>>8. Also TTL on the domain name is really short. Ping from the server itself TTL=64 and ping times are low as you would expect (< 1ms when pinging from the server itself). Ping from outside the network (from the internet - for me - tp the domain was) 12ms (average), no packet loss, TTL = 53. 
>>9. I have not setup any internal DNS entries for the domain. Servers are resolving domain from entries in /etc/hosts.
>>
>>Like I said, it doesn't happen all the time - just maybe once or twice every hour on the servers with more traffic.
>>
>>I ran SIPp pointing at one of the new servers last week and at around 100CPS I was seeing about 2,000 out of approx. 10,000 calls were failing. Setup was UAC -> openser -> UAS (Both UAC and UAS were running on the same machine, but different ports). Again there is no traffic on these servers now so I have no idea why so many failed calls. 
>>
>>I am not sure if any of this information helps, but I am certainly open to suggestions on things to try.
>>
>>Thanks in advance.
>>
>>
>>
>>On 12/14/06, samuel <<mailto:samu60 at gmail.com>samu60 at gmail.com> wrote: 
>>It might be due to a DNS query....whenver a request has to be
>>forwarded to a domain, openSER makes a DNS query to resolv the IP. 
>>During this operation, the child processing the request will not
>>answer to further incoming messages.
>>
>>it also can be happening due to a spiral loop that stays on the server.
>>
>>Without further information (confg,logs) it's hard to tell which is 
>>the reason...
>>
>>hope it helps,
>>Samuel.
>>
>>without more information
>>
>>2006/12/14, Max Gregorian <<mailto:gregorian442 at googlemail.com>gregorian442 at googlemail.com>:
>>    
>>
>>>Hi all,
>>>
>>>Just wondering if anyone else has had this problem. I have noticed while
>>>tracing on my OpenSER server, that every now and then the server receives a
>>>packet which it does to respond to immediately, resulting in a string of 
>>>packets being sent to the server and then the server responding a few
>>>seconds later. This does not happen all the time, just say maybe once or
>>>twice every hour. The rest of the time the signaling is correct and 
>>>responses follow request packets in the correct order.
>>>
>>>What I am trying to figure out is whether this is a load traffic issue (i.e.
>>>can the server not handle too much load), and if so is it OpenSER or the 
>>>network or the server in general? I have run diagnostics on the servers and
>>>there is nothing wrong with the hardware.
>>>
>>>On the other hand Could this be related to any timer issues? I remember 
>>>there was mention of timers in SER but are there any default timer settings
>>>that can be tweaked?
>>>
>>>Thanks in advance for any response.
>>>
>>>
>>>      
>>>