I really mean the SER webtree -- you can add articles on your own and
manage their content.
-jiri
William Zhang wrote:
> Hi Jiri, Sure. Do you mean the Berlios CVS repository or the ser
> maillist? -William
>
> On Wed, Apr 30, 2008 at 1:06 PM, Jiri Kuthan <[EMAIL PROTECTED]> wrote:
>> That's great, why don't you actually post it on the SER webpage? -jiri
>>
>> William Zhang wrote:
>>
>>>
>>>
>>> Finally I got some time to put everything together to produce the
>>> small footprint SER based on SER 0.9.6 for embedded system. Thanks a
>>> lot to Andrei for providing very useful suggestion. Here is the list
>>> of my changes:
>>>
>>> 1. Reduce code size
>>>
>>> a. Remove the USE_IPV6, USE_MCAST, USE_TCP, DISABLE_NAGLE and NO_DEBUG
>>> definitions
>>> b. Remove unix socket server support in the core and modules. Add
>>> NO_UNIXSOCKET definition in twenty some files in core and other
>>> modules for conditional compilation.
>>> c. Remove -g compiler option
>>> d. Add with -Os option
>>>
>>> 2. Reduce data size
>>>
>>> a. Decrease the shared Memory Pool from 32MB to 192KB (SHM_MEM_SIZE)
>>> b. Decrease the Memory Pool from 1MB to 64KB (PKG_MEM_POOL_SIZE)
>>> c. Decrease socket buffer from 64KB to 4KB (BUF_SIZE)
>>> d. Reduce the TM hash table from 64K entries to 1K entries (T_TABLE_POWER)
>>> e. Reduce the MySql buffer size from 64KB to 4KB (SQL_BUF_LEN)
>>>
>>> The data memory reduction is quite aggressive so it might not works if
>>> you have some load and but you can easily increase the constant value
>>> to meet your requirement. I tested it with SJPhone and Quintum Tenor
>>> AF PSTN gateway, it works fine.
>>>
>>> Below is the result for ser core on x86 target with gcc 4.2.1
>>> file size(KB) .text(KB)
>>> .bss(KB) .data(KB) .rodata(KB) shared mem(KB)
>>> Original 1430.4 490.4 1257.2 4.1
>>> 98.0 32768
>>> Modified 350.4 216.2 106.3 3.9
>>> 66.6 192
>>>
>>> I can post the files I modified for removing the unix socket server if
>>> anybody is interested. Just drop me a line. Also if you have any
>>> other idea to further reduce the footprint for embedded application,
>>> please let me know.
>>>
>>> Thanks!
>>> William
>>>
>>> On Thu, Apr 24, 2008 at 11:52 PM, William Zhang <[EMAIL PROTECTED]> wrote:
>>>
>>>> Thanks again for the help. It look like I need to look into more
>>>> detail of the code to understand the design and further reduce the
>>>> code/data size:) Sure I'll make a list of all my changes and I agree
>>>> it would be beneficial to other ppl who like to use SER in the
>>>> embedded system. There are a few changes in the header file const
>>>> definition, compilation defines and options, and also about 10 files
>>>> for adding conditional compilation for unixsocket support. I am going
>>>> to look further into the source code and see any other code can be
>>>> removed and tune the time out setting as you suggested so that i can
>>>> relax the memory pool a little bit. I should be able to put everything
>>>> together sometime next week and keep everybody posted.
>>>>
>>>> On Thu, Apr 24, 2008 at 7:01 AM, Andrei Pelinescu-Onciul
>>>>
>>>>
>>>> <[EMAIL PROTECTED]> wrote:
>>>> > On Apr 24, 2008 at 02:33, William Zhang <[EMAIL PROTECTED]> wrote:
>>>> > > Hi Andrei,
>>>> > >
>>>> > > Thank you very much for the information and detail explanation!
>>>> > >
>>>> > > The project requirement is to reduce the total code and data
>> memory
>>>> > > for SER and necessary modules(I listed in my previous message) to
>> 1MB
>>>> > > or less. I am working on SER 0.9.6 and I removed the the TCP, IPV6
>> and
>>>> > > UDP MULTICAST define and manually remove the unixsocket support in
>> the
>>>> > > core and modules that use it. With -Os and debug strip, I am
>> getting
>>>> > > 233.7KB for core and 225KB for my modules.
>>>> >
>>>> > That's great!
>>>> >
>>>> >
>>>> > > But base on your
>>>> > > compilation result on mipsel, I probably need to take consider a
>> code
>>>> > > size increase of 40% when build for MIPS system.
>>>> >
>>>> > Hopefully that had a lot to do with the compiler.
>>>> >
>>>> >
>>>> > >
>>>> > > By removing the unixsocket modules, I saved 128KB for the socket
>>>> > > buffer. And I slashed the pool memory to 64KB, and reduced the tm
>> hash
>>>> > > table from 64K entry to 1K entry( 24 bytes each entry so use only
>> 24KB
>>>> > > in total now) so I can reduced the shared memory to 192KB,
>> basically
>>>> > > 168KB for any other shared memory usage. (What the tm hash table
>> used
>>>> > > for? Is 1024 entries too less?)
>>>> >
>>>> > The tm hash table is used to store and quickly find a transaction.
>>>> > A call involves at least 2 transactions: one for the original INVITE
>>>> > and one for the BYE. So if you are aiming for 1cps that means at
>> most 2
>>>> > transactions/s. However transactions are kept in memory another 5 s
>>>> > after the completion (to catch retransmissions) so at a 1 cps
>> constant
>>>> > rate => you could have 10 transaction in memory in ideal conditions
>> (in
>>>> > non ideal conditions, like call attempts with nobody answering =>
>>>> > invite transaction timeout 120s + 5s => maximum 625 transaction in
>>>> > memory in the same time). So you could go much lower then 1024 (in
>>>> > theory, in practice we haven't checked if the hash function
>>>> > distribution is still good with very low hash table sizes). If you
>>>> > don't care about DOS or corner cases (like having only unanswered
>>>> > calls) you'll have less then 50 transaction in memory at any time =>
>>>> > you could even try a hast table with only 1 entry. The worst
>>>> > thing that could happen is to have very high cpu usage (if this
>> happens
>>>> > try to increase the hash table).
>>>> >
>>>> > I'm a little worried about the pool memory. 64Kb seems a little to
>> less
>>>> > to me. I don't think there would be a problem if you use a higher
>>>> > number. The unused part should not be paged-in by the OS so the
>>>> > effective used memory should not greater if you use a larger pkg_mem
>>>> > pool size. For example, if I start ser 2.1 with a basic stateless
>>>> > forwarding config, it uses only 556Kb of memory (RSS in top or ps
>> axl)
>>>> > although it is configured with 4Mb pool size and started with 2 Mb
>>>> > shared memory.
>>>> > So by limiting the POOL size or the shared memory size, you are in
>> fact
>>>> > limiting the maximum ser memory usage. If ser doesn't need the whole
>>>> > memory it won't access it and the memory will still be free for
>> other
>>>> > programs.
>>>> >
>>>> >
>>>> > > This way I end up consume less than
>>>> > > 1MB code and data size. I can run a few calls successfully. I
>> have
>>>> > > not run any significant load yet but based on your comment, I
>>>> > > definitely can not support 1cps and I have to either reduce cps or
>>>> > > increase the memory. You mentioned 1 cps with default timeouts you
>>>> > > need ~200k. What does the timeout do with the memory? Is it from
>> the
>>>> > > memory pool or shared memory?
>>>> >
>>>> > It's from the shared memory. The non-shared memory (memory pool)
>> it's
>>>> > used either on startup/init. or for temporary stuff.
>>>> > The timeouts influences how much a transaction will be kept in
>> memory.
>>>> > For example even if a transaction is complete it still has to be
>> kept in
>>>> > memory for 5s to catch possible delayed retransmissions (according
>> to
>>>> > the rfc). It's worse if you are trying to call somebody who doesn't
>>>> > answer. In this case the timeout is 120s by default in ser (IIRC in
>> the
>>>> > rfc is 180s).
>>>> > You could save some memory also by changing some of the tm
>> timeouts.
>>>> > In general if you have a simple setup with low probability of
>> delayed
>>>> > retransmissions (e.g. local net.) you can decrease the final wait
>> timer to 1s
>>>> > without problems ( in ser.cfg modparam("tm", "wt_timer" ,1)).
>>>> >
>>>> > You could also tune the no-response timeouts (e.g. fr_timer set to
>> 10s
>>>> > instead of the default 30 and fr_inv_timer to 90s instead of 120s).
>>>> >
>>>> >
>>>> > Could you make a list with all the changes you've made? I think it
>> would
>>>> > be very usefull for anynone trying to run ser on some embedded
>> system
>>>> > and we could even add and emebedded option in the makefile that
>> would
>>>> > automatically build a low memory optimized ser version.
>>>> >
>>>> > Andrei
>>>> >
>>>> >
>>>> >
>>>> > >
>>>> > > Thanks,
>>>> > > William
>>>> > >
>>>> > > On Wed, Apr 23, 2008 at 5:49 AM, Andrei Pelinescu-Onciul
>>>> > > <[EMAIL PROTECTED]> wrote:
>>>> > > > On Apr 20, 2008 at 20:04, William Zhang <[EMAIL PROTECTED]>
>> wrote:
>>>> > > > > Hi All,
>>>> > > > >
>>>> > > > > I am a newbie to the SIP Express Router and the project I am
>> currently
>>>> > > > > working on requires me to port SER to a MIPS embedded system
>> with
>>>> > > > > limited memory space. So the code size and data memory size
>> are my
>>>> > > > > primary concerns.
>>>> > > >
>>>> > > > ser already works and compiles for MIPS, so you'll need only to
>> optimize
>>>> > > > it for lower memory usage.
>>>> > > >
>>>> > > > Example cross-compile for openwrt (gcc 3.4.4):
>>>> > > >
>>>> > > > make ARCH=mips2
>> CC=${OPENWRT}/staging_dir_mipsel/bin/mipsel-linux-gcc \
>>>> > > > OS=linux OSREL=2.4.35 CC_EXTRA_OPTS=-Os extra_defs=-DNO_DEBUG
>>>> > > >
>>>> > > > After runing strip on it:
>>>> > > > ls -l ser
>>>> > > > -rwxr-xr-x 1 andrei andrei 526652 Apr 23 14:10 ser
>>>> > > >
>>>> > > > On x86, compiling with similar options, gcc 4.2.3 and
>> stripping, I get:
>>>> > > > -rwxr-xr-x 1 andrei andrei 379876 Apr 23 14:25 ser
>>>> > > >
>>>> > > >
>>>> > > > (for ser 0.9.7, 2.0 & 2.1 are ~ 1Mb for mipsel/gcc 3.4.4 and
>> ~640k
>>>> > > > x86/gcc 4.2.3)
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > > Since I am still having some issue with my MIPS cross
>> compilation, I
>>>> > > > > just worked the SER 0.9.6 on my SUSE PC. With all the default
>> compiler
>>>> > > > > option but removing the debug info (without the -g option)
>> and i386
>>>> > > > > release target, the SER
>>>> > > > > is about 490KB in code size (the .text section in the map
>> file). I
>>>> > > > > disabled the TCP, IPV6 and UDP MULTICAST support, the code
>> size
>>>> > > > > decreased to 423KB. The SER website mentions that footprint
>> size:
>>>> > > > > 300k core, all common modules
>>>> > > > > (optional) up to 630k (http://www.iptel.org/ser). Am I
>> missing
>>>> > > > > something here or maybe the website is not up to date with
>> the
>>>> > > > > footprint?
>>>> > > >
>>>> > > > It's not up to date (IIRC this was ser 0.8.10).
>>>> > > >
>>>> > > >
>>>> > > > > I only need the basic SER with authentication and PSNT
>>>> > > > > gateway support. I loaded these moduels:
>>>> > > > > mysql.so, sl.so, tm.so, rr.so, maxfwd.so, usrloc.so,
>> registrar.so,
>>>> > > > > auth.so, auth_db.so, uri.so, uri_db.so, domain.so, avpops.so
>> and
>>>> > > > > permissions.so. And these modules adds up to 432KB with tm.so
>> as the
>>>> > > > > biggest one(200KB). Is there any
>>>> > > > > way to further reduce code size for the core and modules?
>>>> > > >
>>>> > > > Compile with -Os (CC_EXTRA_OPTS=-Os to the make command line),
>>>> > > > extra_defs=-DNO_DEBUG.
>>>> > > > There are lots of othe different defines you can play with
>> (like turning
>>>> > > > down support for poll methods you don't use), but I don't
>> remember all
>>>> > > > of them.
>>>> > > >
>>>> > > > >
>>>> > > > > Of course, this is only the size for PC platform. I am hoping
>> the MIPS
>>>> > > > > should not differ too much. If anybody compile SER in MIPS,
>> could you
>>>> > > > > let me know what the code size is? Even for IPAQ compile
>> result, I
>>>> > > > > also would like to know it.
>>>> > > >
>>>> > > > It's bigger (see above) :-(
>>>> > > > Maybe a newer gcc would help.
>>>> > > >
>>>> > > >
>>>> > > > >
>>>> > > > > As for the data memory, it seems the SER use the 1MB pool
>> memory as
>>>> > > > > default for dynamic memory allocation and 32MB shared memory.
>> If I
>>>> > > > > only need to support 3600 call per hour, about 1 call per
>> second, and
>>>> > > > > maximum 80 concurrent calls,
>>>> > > >
>>>> > > > For 1 cps with default timeouts you need ~200k. If you want to
>> plan for
>>>> > > > a DOS: 2.5Mb - 5Mb.
>>>> > > > For maximum 80 concurent calls 1.6Mb.
>>>> > > > (rounding up transaction usage to 20k, in reality it's <10k on
>> a 32 bit
>>>> > > > cpu and a simple no-avps config)
>>>> > > >
>>>> > > > Note however that there is some memory needed for internal
>> structures
>>>> > > > (hashes a.s.o) so you can't probably start ser with less then
>> 2Mb shared
>>>> > > > memory (at least not 2.1).
>>>> > > > Try starting with 3Mb (ser -m 3) if you use 0.9.7 or 4 Mb if
>> you use 2.0
>>>> > > > or 2.1.
>>>> > > >
>>>> > > > There are also some compile option that could reduce
>> dramatically the
>>>> > > > memory usage. For example the size of various hashes (tm hash,
>> dns
>>>> > > > cache, blacklists a..s.o).
>>>> > > > I always wanted to introduce a make target or option for
>> embedded
>>>> > > > systems, that would minimize memory usage at the cost of
>> performance,
>>>> > > > but I never got to doing it :-(
>>>> > > >
>>>> > > >
>>>> > > > > is the default memory allocation too large? How far can I
>> reduce from
>>>> > > > > the default? Is there way I can monitor the memory usage for
>> an active
>>>> > > > > call?
>>>> > > >
>>>> > > > You can reduce default shared memory usage by starting ser with
>> a
>>>> > > > different value: ser -m <value_in_MB>.
>>>> > > > The pool memory can be reduced only by modifying config.h
>>>> > > > PKG_MEM_POOL_SIZE and re-compiling. You could porbably get away
>> with 512
>>>> > > > Kb of pkg mem. (or maybe even less). Just watch out the log for
>> out of
>>>> > > > memory errors.
>>>> > > >
>>>> > > > You can't monitor memory usage per call (in fact ser doesn't
>> even have a
>>>> > > > "call" notion). On 2.0 or 2.1 you could see the current shared
>> memory
>>>> > > > usage using sercmd: sercmd core.shmmem.
>>>> > > > For 0.9.x you could try looking at top output for the "RES"
>> value, or
>>>> > > > you could use a high log level and look at the log output on
>> exit or
>>>> > > > after kill -SIGUSR1 <pid_of_ser>.
>>>> > > >
>>>> > > >
>>>> > > > Andrei
>>>> > > >
>>>> >
>>>>
>>>>
>>> _______________________________________________
>>> Serdev mailing list
>>> [email protected]
>>> http://lists.iptel.org/mailman/listinfo/serdev
>>>
>>>
> _______________________________________________
> Serdev mailing list
> [email protected]
> http://lists.iptel.org/mailman/listinfo/serdev
>
_______________________________________________
Serdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/serdev
