30 Sep
2010
30 Sep
'10
9:07 p.m.
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
30 Sep
30 Sep
9:14 p.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
9:32 p.m.
On Sep 30, 2010 at 20:07, Daniel-Constantin Mierla <miconda(a)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
11:11 p.m.
El Thu, 30 Sep 2010 21:50:19 +0300
Juha Heinanen <jh(a)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"
:)
11:38 p.m.
On 9/30/10 10:11 PM, Jon Bonilla (Manwe) wrote:
El Thu, 30 Sep 2010 21:50:19 +0300
Juha Heinanen<jh(a)tutpro.com> escribió:
"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
--
Daniel-Constantin Mierla
http://www.asipto.com
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"
5197
days inactive
5197
days old
5 comments
5 participants
participants (5)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Jon Bonilla -
Juha Heinanen -
Ovidiu Sas