| 00:00.05 | file | the NAT code that is |
| 00:00.22 | file | however you can't update an RTP instance, you'd have to tear down/create a new one bound explicitly to the IP address |
| 00:01.04 | gtjoseph | does the dns lookup not happen until we've called send_msg? |
| 00:01.29 | file | it does not |
| 00:01.52 | gtjoseph | yeah, that sucks |
| 00:03.03 | gtjoseph | although, what if we defer calling ast_rtp_instance_new until then |
| 00:03.20 | gtjoseph | or does ast_rtp_instance_new have to happen to construct the SDP |
| 00:03.29 | file | you'd have to fake parts of the SDP |
| 00:03.44 | file | and then be absolutely sure to replace them |
| 00:03.48 | gtjoseph | yeah, nope. :) |
| 00:03.59 | file | you'd also have to update the channel with file descriptors |
| 00:04.49 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-wjbssorcxzbpsgdb) |
| 00:04.53 | gtjoseph | i'll stick to the current implementation. if it works for folks, great. if not... |
| 00:05.30 | gtjoseph | unless you're using the same endpoint via different transports it'll be fine. |
| 00:06.13 | gtjoseph | or i could move the implementation to the transport. |
| 00:06.15 | gtjoseph | :( |
| 00:06.38 | file | it's a hard problem to solve |
| 00:07.33 | gtjoseph | maybe both places as you suggestedd |
| 00:35.43 | *** join/#asterisk-dev coreyf1513 (~coreyfarr@24-177-3-44.dhcp.nwtn.ct.charter.com) |
| 01:17.44 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 02:21.13 | coreyfarrell | I just did some profiling to see if an ao2_alloc_option for using malloc could be worth it, I knew malloc would be faster but didn't realize the difference would be so big. |
| 02:21.46 | gtjoseph | how big? |
| 02:22.13 | coreyfarrell | I ran http://pastebin.com/hVWaWjvS in callgrind. tried it with SIZE set to 64, 256 and 4096, always 1048576 iterations. callgrind said that calloc took 50% longer on 64 and 256 bytes |
| 02:22.51 | coreyfarrell | for 4096 bytes the calls to calloc took 3.5 times longer than the calls to malloc |
| 02:23.28 | gtjoseph | setting all those zeros :) |
| 02:24.01 | gtjoseph | any difference with calloc playing with items and size? |
| 02:24.33 | gtjoseph | I.E 1 item @ 4096 vs 4096 items @ 1 |
| 02:24.59 | coreyfarrell | not sure I follow |
| 02:25.50 | gtjoseph | calloc(1, 4096) vs calloc(4091,1) |
| 02:25.55 | gtjoseph | 4096 |
| 02:27.15 | coreyfarrell | not sure.. I just tested calloc(1, SIZE) - not calloc(SIZE, 1).. since ao2_alloc only uses the first form |
| 02:39.15 | coreyfarrell | ugh MALLOC_DEBUG is a pain |
| 02:39.27 | gtjoseph | so is sipp |
| 02:40.55 | coreyfarrell | we have __ast_malloc() when MALLOC_DEBUG is enabled, _ast_malloc() when it's disabled. both functions have the same parameters (they include file/line/function) |
| 02:46.19 | X-Rob | https://wiki.asterisk.org/wiki/display/AST/Configuring+chan_sip |
| 02:46.29 | X-Rob | one day, there'll be stuff there.. one day.. |
| 02:47.10 | gtjoseph | who's going to write it?? |
| 02:52.21 | X-Rob | gtjoseph: Probably me. Because I'm going to get sick of it not being there. |
| 02:52.28 | gtjoseph | :) |
| 03:27.50 | gtjoseph | coreyfarrell: gerrit is super speedy now. :) |
| 03:29.34 | coreyfarrell | yeah after file restarted it |
| 03:57.57 | coreyfarrell | is it actually safe to use ast_mutex_init on uninitialized/malloc'ed memory? looks like __ast_pthread_mutex_init can read the uninitialized t->mutex when DEBUG_THREADS, AST_MUTEX_INIT_W_CONSTRUCTORS and CAN_COMPARE_MUTEX_TO_INIT_VALUE are all defined. |
| 03:58.39 | coreyfarrell | pretty much same situation in __ast_rwlock_init too |
| 06:13.49 | *** join/#asterisk-dev goddva (~goddva@77.40.154.242) |
| 06:35.19 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 08:10.24 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:46.03 | *** join/#asterisk-dev hehol (~hehol@130.180.55.250) |
| 09:02.27 | *** join/#asterisk-dev skrusty (~skrusty@168.63.14.171) |
| 09:37.14 | dan_j | Any idea how long it takes legal to approve the Contributor License Agreement? |
| 09:44.00 | wdoekes | couple of working days? |
| 09:47.16 | dan_j | Ok. For now I'll play around with the source code from github. thanks. |
| 10:59.17 | dan_j | How do I add an item to sorcery? I've added this to the bottom of res/res_pjsip/config_global.c |
| 10:59.23 | dan_j | http://pastebin.com/Psi3kCLb |
| 10:59.35 | dan_j | And get this from the CLI |
| 10:59.36 | dan_j | config_options.c:710 aco_process_var: Could not find option suitable for category 'global' named 'regcontext' at line 6 of |
| 11:07.19 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 11:52.58 | file | you have to document what you've added in the XML documentation in res_pjsip.c |
| 12:07.24 | coreyfarrell | file: so is xml documentation still optional at runtime? |
| 12:07.46 | file | no clue! |
| 12:39.45 | stefan27 | do you asterisk developers ever run callgrind and cachegrind or similar tools on asterisk during load tests? |
| 12:44.45 | coreyfarrell | stefan27: I've never used cachegrind. I sometimes use callgrind to test a thousand or million iterations of a single function before and after a change to make sure I don't break performance. the only valgrind tool I use with real load (channels) is memcheck. |
| 12:58.36 | stefan27 | I used it for fun on a single webrtc video sip use case on a single deployment, but I got values I couldn't really interpret. (like 2% D1 cache misses, 0.3% last level cache misses, 5% branch prediction fails) |
| 13:01.35 | coreyfarrell | like I said I've never used cachegrind so I have no idea if those numbers are good, bad, or how many iterations/calls would be needed for the results to be significant. for callgrind you need to process with callgrind_annotate to make sense of the results. |
| 13:05.07 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 13:05.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:06.48 | *** join/#asterisk-dev newtonr (~newtonr@173-21-146-94.client.mchsi.com) |
| 13:06.48 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:12.23 | stefan27 | yeah callgrind has been helpful while playing with new modules to see which functions are bottlenecks, I guess the interpretation of the output of cachegrind depends even more on the OS/hardware environment |
| 13:24.18 | coreyfarrell | stefan27: I suspect volume will effect cachegrind.. it seems like you got really high cache hit rates so you probably didn't run enough volume to put any stress on caches |
| 13:25.14 | stefan27 | Yeah only single user in that one |
| 13:38.35 | stefan27 | I guess what I really want to know is how our performance of our asterisk deployment scales with number of concurrent (webrtc or normal) calls and sip users AND with hardware. At the moment we have 3 kinds of deployment environments, one is physical machine, two are virtual machines, the virtual machines have 2 and 4 cores and 0.5 MB and 30 MB cpu cache size respectively |
| 13:39.52 | stefan27 | it's easy to guess the performance benefit of adding cores but I don't know which other cpu/hardware parameters that are significant? |
| 13:42.18 | stefan27 | do you know of any good blog-posts about asterisk performance considerations? |
| 13:42.55 | file | noone, to my knowledge, has of yet done such a thing |
| 13:48.27 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-vzvrukmhvdphvqyy) |
| 13:50.05 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 14:13.49 | dan_j | file: yes i'm working on adding regcontext. just waiting for access to be able to submit code. |
| 14:14.43 | file | does the JIRA dance |
| 14:23.35 | dan_j | How do I access a pjsip global sorcery variable from within res/res_pjsip/pjsip_configuration.c ? Trying to find an example but cant seem to find anywhere where its done. |
| 14:25.56 | stefan27 | gtjoseph why did you refer to ASTERISK-25317 in your stasis_cache_pattern commit? |
| 14:26.45 | stefan27 | 25317 was resolved to 13.7 but by another commit afaik |
| 14:38.32 | file | dan_j, accessors for the set value are in config_global.c |
| 14:39.05 | dan_j | I've set them towards the bottom of that file. |
| 14:39.07 | file | dan_j, if you are referring to the XML instead it's just XML, just have to put the right stuff in |
| 14:40.04 | dan_j | I've set the regcontext value from pjsip.conf, and can now see it when doing 'pjsip show settings' on the CLI. |
| 14:40.23 | dan_j | I've also go the code to add the NoOp extension. |
| 14:40.42 | dan_j | But how do I pull the setting out of sorcery? |
| 14:41.29 | file | you write an accessor in config_global.c, add it's declaration to res_pjsip.h so it can be used elsewhere, and use it |
| 14:42.32 | dan_j | Ok. I think I get it. |
| 15:03.46 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-bouuqcgiaqgvcenq) |
| 15:15.00 | *** part/#asterisk-dev lumasepa (~gestoip@193.145.124.30.local.ull.es) |
| 15:24.15 | dan_j | code that worked in 13.5.0 no longer works in 13.7.0. I get this |
| 15:24.17 | dan_j | error: âE_MATCHâ undeclared (first use in this function) |
| 15:24.39 | dan_j | trying to use it in res/res_pjsip/pjsip_configuration.c |
| 15:26.23 | file | include files may have changed, resulting in it no longer being included |
| 15:27.28 | dan_j | I compared the includes within that file and they match, but it might have been removed elsewhere |
| 15:43.12 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-rgiajrrrbeseeibl) |
| 15:43.12 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:47.31 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 15:47.31 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 15:50.32 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 15:50.32 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 15:52.52 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 15:52.52 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 15:58.21 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-mywhawuglfsrlajw) |
| 15:59.56 | gtjoseph | stefan27: i typo'd the issue id. It should have been ASTERISK-25137 |
| 16:53.10 | stefan27 | cool - I guess it doesn't matter that much since both those issues should be closed by 13.7 ? but my closed jira 25317 now links to wrong commit |
| 16:56.47 | stefan27 | have a nice weekend |
| 17:10.19 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 17:10.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:47.24 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 22:42.30 | coreyfarrell | rmudgett: ping |
| 22:42.39 | rmudgett | pong |
| 22:43.24 | coreyfarrell | is it actually safe to use ast_mutex_init on uninitialized/malloc'ed memory? looks like __ast_pthread_mutex_init can read the uninitialized t->mutex when DEBUG_THREADS, AST_MUTEX_INIT_W_CONSTRUCTORS and CAN_COMPARE_MUTEX_TO_INIT_VALUE are all defined. |
| 22:45.12 | coreyfarrell | same question applies to ast_rwlock_init.. reason I ask is I'm looking at creating an option flag for ao2_alloc to be able to use malloc instead of calloc |
| 22:47.46 | rmudgett | Probably not since DEBUG_THREADS has a record keeping allocated pointer that it assumes is NULL if it hasn't initialized. |
| 22:48.02 | rmudgett | IIRC |
| 22:49.00 | coreyfarrell | hmm, so I guess to rephrase my question: is it a bug to run ast_mutex_init on memory that was malloc'ed, or is the DEBUG_THREADS code the bug? |
| 22:55.07 | rmudgett | Looks like it is not safe precisely because of that t->mutex reference. Looks like DEBUG_THREADS is trying to detect double initialization errors. |
| 22:56.23 | rmudgett | Double initialization would cause DEBUG_THREADS to leak memory. |
| 22:59.15 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 23:00.50 | coreyfarrell | I really dislike DEBUG_THREADS.. I did a quick test with callgrind running a loop of a million allocations, malloc measured 50% faster for small allocations (64 and 256 bytes), 3.5x faster for large allocations (4096 bytes). |
| 23:01.05 | rmudgett | Do you have a use case where malloc would be preferable to calloc on an ao2 object? |
| 23:01.51 | coreyfarrell | not a specific one, any case where all fields of user_data are initialized it would perform better (zero's aren't free). |
| 23:03.03 | rmudgett | Well you could limit the zero fill to the ao2 overhead fields. |
| 23:03.48 | rmudgett | Though the zero fill will clear out any padding bytes |
| 23:04.44 | rmudgett | Those bits aren't something you can easily access from a struct. |
| 23:05.50 | coreyfarrell | what do you mean padding bytes? you mean between the fields of the ao2 private structure? is it really needed to initialize padding bytes? I mean wouldn't they never be read anyways? |
| 23:06.11 | coreyfarrell | otherwise any program that uses malloc anywhere would have uninitialized memory access violations |
| 23:08.28 | rmudgett | You'd access the padding bytes if you tried to compare structs using memcmp() |
| 23:10.44 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 23:13.53 | coreyfarrell | only if memcmp was run against the AO2 internal structures, other than possibly the locking structure that would not happen. for the user_data it would be up to whatever code decides to allocate with malloc to never memcmp two structs like that |
| 23:23.50 | coreyfarrell | thanks you've given me some things to think about. the biggest concern I had previously was that someone might make a certain struct use malloc, then later on someone adds a field without realizing it won't be zero filled. |
| 23:41.42 | rmudgett | For ao2 it has been zero filled since the beginning that making an option to not zero fill could be a bit of a surprise. |
| 23:51.15 | coreyfarrell | well the same is true for ao2 objects having a mutex.. malloc would only be used in limited situations where it's worth it (a large structure where all fields are initialized), possibly only with opaque types. |
| 23:51.56 | coreyfarrell | but point taken, using malloc has the ability to create bugs that cannot be reliably found without valgrind |
| 23:54.38 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-bouuqcgiaqgvcenq) |