I was checking what are current differences between the two major flavours: ser and kamailio.
Apart of the name and default config file, kamailio flavour enables at compile time KMSTATS, FMSTATS and WITHAS, precisely these are:
ifeq ($(KMSTATS), 1) C_DEFS+= -DUSE_CORE_STATS -DSTATISTICS endif ifeq ($(FMSTATS), 1) C_DEFS+= -DMALLOC_STATS endif ifeq ($(WITHAS), 1) C_DEFS+= -DWITH_AS_SUPPORT endif
I am thinking that maybe we can make them (all or some) enabled by default now that Andrei added the new statistics API.
WITH_AS_SUPPORT enables extra api in TM, iirc this would be needed at least by seas module.
Anyone with pro/cons?
Cheers, Daniel
I would like to see less and less differences between the two flavours.
Regards, Ovidiu Sas
On Thu, Sep 30, 2010 at 2:07 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
I was checking what are current differences between the two major flavours: ser and kamailio.
Apart of the name and default config file, kamailio flavour enables at compile time KMSTATS, FMSTATS and WITHAS, precisely these are:
ifeq ($(KMSTATS), 1) C_DEFS+= -DUSE_CORE_STATS -DSTATISTICS endif ifeq ($(FMSTATS), 1) C_DEFS+= -DMALLOC_STATS endif ifeq ($(WITHAS), 1) C_DEFS+= -DWITH_AS_SUPPORT endif
I am thinking that maybe we can make them (all or some) enabled by default now that Andrei added the new statistics API.
WITH_AS_SUPPORT enables extra api in TM, iirc this would be needed at least by seas module.
Anyone with pro/cons?
Cheers, Daniel
-- Daniel-Constantin Mierla http://www.asipto.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On Sep 30, 2010 at 20:07, Daniel-Constantin Mierla miconda@gmail.com wrote:
I was checking what are current differences between the two major flavours: ser and kamailio.
Apart of the name and default config file, kamailio flavour enables at compile time KMSTATS, FMSTATS and WITHAS, precisely these are:
ifeq ($(KMSTATS), 1) C_DEFS+= -DUSE_CORE_STATS -DSTATISTICS endif ifeq ($(FMSTATS), 1) C_DEFS+= -DMALLOC_STATS endif ifeq ($(WITHAS), 1) C_DEFS+= -DWITH_AS_SUPPORT endif
I am thinking that maybe we can make them (all or some) enabled by default now that Andrei added the new statistics API.
Yes, but they are not yet used everywhere.
From the point of view of core and common modules (modules/):
USE_CORE_STATS will enable event callbacks (sr_event_exec) _for_ _each_ use. I don't have anything against migrating them to use directly counters and then having them enabled by default (right now they do all this extra stuff that is not needed anymore).
STATISTICS seem to enable only the statistics inside modules/sl. While module/sl could also be migrated to counters (very easily, only the help text would need some time), the performance impact is almost non-existent so I have nothing against enabling it.
WITH_AS_SUPPORT enables extra api in TM, iirc this would be needed at least by seas module.
That I am not sure. I don't think that the 1 or 2 modules that need it justify having it enabled by default (for one thing the transaction size will slightly increase). So far my impression is that modules that depend on WITH_AS_SUPPORT are seldom used, in specialized application (but please correct me if I am wrong).
Anyone with pro/cons?
Speaking of statistics we could try re-enabling stats.[ch] (after re-basing it on counters), and updating tm stats, dns stats and sl stats to use counters (it would be nicer to have all the stats from the same interface, with associated help and auto-generated documentation). Unfortunately I don't think we have time for it (leave them for 3.1.1 ?).
Andrei
El Thu, 30 Sep 2010 21:50:19 +0300 Juha Heinanen jh@tutpro.com escribió:
a couple of extra weeks would be worth spending if we could then have only one flavor.
-- juha
+1
Which release policy do we have? A la Debian or a la Ubuntu?
I'd like to read "sr will be ready when it's ready"
:)
On 9/30/10 10:11 PM, Jon Bonilla (Manwe) wrote:
El Thu, 30 Sep 2010 21:50:19 +0300 Juha Heinanenjh@tutpro.com escribió:
a couple of extra weeks would be worth spending if we could then have only one flavor.
-- juha
+1
Which release policy do we have? A la Debian or a la Ubuntu?
I'd like to read "sr will be ready when it's ready"
"ready" doesn't mean "nothing else to do". Otherwise we never release.
The problem with a not clear release policy is time planning. For example, I tried to free my September to work as much as possible on testing and preparing the release as we planned it. Other probably planned to wait a bit for some deployments just to benefit of some new features. Changing these kind of milestones last minute does not bring anything positive.
Considering ser's developers approach on the least effects on performance, initially I thought it is a trivial impact at least regarding the statistics, believing that all stats were migrated to new API, but proved not to be like this after Andrei's remarks. To be clear, Kamailio flavour has already all these on in 3.0 and works just fine, it is just affecting ser flavour.
Considering that major changes will require a new round of all tests, mixed with the fact that some cannot spend any longer much time on such things in the near future (at least me), means probably 3 months, that overlaps with winter holidays, so it is 4 months.
If we do it a release now, 3.1, with current tested code, next will be in about 6-8 months, with other new features and things like new stats better propagated. Andrei talked now about only common modules to be migrated to new stats API, by 3.2 we will probably have all stats with the new API.
Cheers, Daniel
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jon Bonilla -
Juha Heinanen -
Ovidiu Sas