| 00:02.21 | *** join/#asterisk-dev moy (n=moy@189.169.82.128) |
| 00:27.08 | eliel | ~eliel |
| 01:02.47 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 01:02.47 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 01:36.41 | *** join/#asterisk-dev DarkRift (n=dark@bas10-montreal02-1177582590.dsl.bell.ca) |
| 02:16.24 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 02:45.07 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 02:45.07 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 02:57.12 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 03:19.44 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-214-19.west.biz.rr.com) |
| 03:46.15 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 03:51.02 | *** join/#asterisk-dev moy (n=moy@189.169.82.128) |
| 04:22.46 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 04:36.40 | moy | anybody with an idea of why after zt_close (close) in chan_zap for 1.4 ZT_SPECIFY fails with EBUSY? if I sleep (1 second) and try again the channel is available, this is for an FXO device |
| 04:58.51 | *** join/#asterisk-dev CunningPike_ (n=arodgers@S010600095b33697f.vc.shawcable.net) |
| 05:14.06 | *** join/#asterisk-dev fabled (n=fabled@xdsl-83-150-94-239.nebulazone.fi) |
| 05:15.17 | *** join/#asterisk-dev bbryant (n=brett@c-71-228-178-34.hsd1.al.comcast.net) |
| 05:15.17 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 05:15.52 | bbryant | The bug tracker is going to be down for about 30 mins while it's upgraded. |
| 05:22.27 | Corydon76-dig | bbryant: I think you mean 2am est |
| 05:22.46 | Corydon76-dig | not pm |
| 05:23.36 | bbryant | yep, thanks |
| 06:42.30 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.139) |
| 07:10.53 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 07:10.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:18.47 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.108.119) |
| 07:18.47 | *** mode/#asterisk-dev [+o ctooley] by irc.freenode.net |
| 07:18.49 | *** join/#asterisk-dev freddyk (n=freddy@host131-140-dynamic.42-79-r.retail.telecomitalia.it) [NETSPLIT VICTIM] |
| 07:18.49 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) [NETSPLIT VICTIM] |
| 07:18.49 | *** join/#asterisk-dev _Vile (n=vile@208.100.152.234) [NETSPLIT VICTIM] |
| 08:01.43 | *** part/#asterisk-dev dominic1 (n=dob@213.221.82.242) |
| 08:35.13 | tzafrir_laptop | sed 's#__LOGDIR__#$(ASTLOGDIR)#g' < contrib/scripts/asterisk.logrotate | sed 's#__SBINDIR__#$(ASTSBINDIR)#g' |
| 08:35.16 | tzafrir_laptop | make that: |
| 08:35.41 | tzafrir_laptop | sed -e 's#__LOGDIR__#$(ASTLOGDIR)#g' < contrib/scripts/asterisk.logrotate -e 's#__SBINDIR__#$ |
| 08:35.55 | tzafrir_laptop | or even: |
| 08:36.31 | tzafrir_laptop | sed -e 's#__LOGDIR__#$(ASTLOGDIR)#g' -e 's#__SBINDIR__#$' contrib/scripts/asterisk.logrotate |
| 08:36.44 | tzafrir_laptop | and get an error if the input is not there |
| 08:41.06 | jsmith | tzafrir_laptop: I agree... |
| 09:12.31 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 09:41.28 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 09:41.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:50.03 | *** join/#asterisk-dev DarKnesS_WolF (n=sherif@unaffiliated/sherif) |
| 09:50.17 | DarKnesS_WolF | guys i want to add a country in the indecations.conf i got the rings and so on but i don't know how i should load it .. and should it be includeded into zonedata.c in zaptel driver ? or what and if this is the case so why we do have indecations.conf ? |
| 09:55.09 | tzafrir_laptop | DarKnesS_WolF, which country? |
| 09:55.40 | tzafrir_laptop | Usually you should be able to find references in the telephony standards of the said country |
| 09:55.55 | tzafrir_laptop | But is there one? (one, as opposed to many) |
| 09:56.50 | tzafrir_laptop | indications.conf and zonedata.c have the same information in a different format. |
| 09:57.09 | tzafrir_laptop | The contrib directory of asterisk has a small program to translate from one to another |
| 09:57.55 | DarKnesS_WolF | tzafrir_laptop: i already find the refrencis and i checked the code |
| 09:58.04 | DarKnesS_WolF | tzafrir_laptop: any new news about the problem i told u about ? |
| 09:58.52 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 09:59.40 | DarKnesS_WolF | tzafrir_laptop: about the indecations. the country should exists on both zonedata.c and indecations.conf ? |
| 10:00.04 | tzafrir_laptop | yes |
| 10:01.40 | DarKnesS_WolF | okay will see what i can do and will check this tool |
| 10:01.49 | DarKnesS_WolF | tzafrir_laptop: about this hangup problem i told u about yesterday |
| 10:01.51 | DarKnesS_WolF | any new news? |
| 10:54.42 | *** join/#asterisk-dev dominic1 (n=dob@213.221.82.242) |
| 11:03.37 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:16.24 | *** join/#asterisk-dev oron (n=oron@local.xorcom.com) |
| 11:48.39 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 11:53.19 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:55.59 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 11:57.36 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) [NETSPLIT VICTIM] |
| 11:57.36 | *** join/#asterisk-dev _Vile (n=vile@208.100.152.234) [NETSPLIT VICTIM] |
| 12:06.52 | *** join/#asterisk-dev freddyk (n=freddy@host131-140-dynamic.42-79-r.retail.telecomitalia.it) |
| 12:07.34 | freddyk | who is actually developing chan_skinny ? |
| 12:24.37 | *** join/#asterisk-dev Dovid (n=Dovid@bzq-79-180-162-122.red.bezeqint.net) |
| 12:33.20 | *** join/#asterisk-dev techie (n=techie@m210e36d0.tmodns.net) |
| 12:48.15 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:48.15 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:57.43 | *** join/#asterisk-dev eliel (n=eliel@151-202-114-200.fibertel.com.ar) |
| 13:04.10 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.193) |
| 13:06.51 | *** join/#asterisk-dev dbailey (n=doug@216.207.245.1) |
| 13:09.00 | *** join/#asterisk-dev pabelanger (n=pabelang@OTWAON23-1242541604.sdsl.bell.ca) |
| 13:15.30 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:23.34 | ctooley | freddyk, There's more than one person I believe |
| 13:24.07 | snuff-home | mvanbaak and DEA are the main ones that contrib code/fixes to it lately |
| 13:30.15 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) |
| 13:32.43 | *** join/#asterisk-dev moy (n=moy@nat/ibm/x-11005b0e5c0d0d22) |
| 13:53.07 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 13:53.07 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:53.53 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 13:55.23 | snuff-home | hello putnopvut.. hows ur astobj2 understanding.. have a q |
| 13:55.46 | putnopvut | It's pretty good. I know how to use the API and am pretty good with the internals but not a guru. |
| 13:56.43 | snuff-home | mm fair enough.. i'm wondering if its 'wise' to have a stringfield or a ast_str as the 'hashed' element rather than a std fixed char[] size |
| 13:57.59 | putnopvut | What's your reasoning for believing that it may not be wise? |
| 13:59.13 | snuff-home | just that the other 2 examples i've seen always have static char[size] and unsure how different sized elements would affect the hashing/bucket distribution |
| 13:59.51 | snuff-home | granted i haven't checked the astobj2 internals in a little while.. i'm assuming the hashing stops at a 'null' |
| 14:00.35 | putnopvut | Actually, hash functions are user-defined for each container. It's up to the user of the API to determine the number of buckets and the hashing algorithm used. |
| 14:02.15 | putnopvut | When an astobj2 container is created, a hash callback is one of the parameters of the allocation function. This callback is used by astobj2 to actually determine the hash of whatever is passed in. |
| 14:02.44 | snuff-home | mm i just noticed in chan_sip.. murf uses the 'str_hash' function |
| 14:04.07 | snuff-home | oh well i shall try as a stringfield since it should only be set once per instantisation of the struct ( from memory) |
| 14:06.09 | snuff-home | mm better not get too far ahead of myself will change to static char[size] for astobj2 then goto stringfields/ast_str afterwards |
| 14:07.16 | putnopvut | snuff-home: That sounds like a good idea. The biggest thing to remember is to hash based on something that uniquely identifies the struct. As long as that's true, it shouldn't matter what the type is. |
| 14:08.37 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 14:08.37 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:23.10 | atis_work | hey, can anybody help me with deadlock debugging a bit? |
| 14:23.31 | atis_work | i'm reading http://www.voip-info.org/wiki/view/Asterisk+debugging#HowToDebugaDeadLockinAsterisk but it's not clear how to relate PID in logfiles with thread numbers |
| 14:25.17 | atis_work | so, the "core show locks" with corresponding backtraces from "bt" are here http://www.pastebin.ca/1081879 |
| 14:29.16 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.108.119) |
| 14:29.16 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 14:30.30 | putnopvut | atis_work: do the "started at [ 1078]" numbers correspond to the PID in the log files? |
| 14:30.49 | *** join/#asterisk-dev UnixDog (n=UnixDog@181.128.204.68.cfl.res.rr.com) |
| 14:31.09 | putnopvut | Nope, that's a line number, nevermind. |
| 14:31.18 | *** part/#asterisk-dev UnixDog (n=UnixDog@181.128.204.68.cfl.res.rr.com) |
| 14:31.19 | atis_work | nope |
| 14:33.02 | putnopvut | It's strange that the lock at address 0x94743c is being waited on by two threads, but there is no thread which claims ownership of that lock. |
| 14:33.06 | atis_work | i was hoping that LWP is that, but they doesn't match |
| 14:33.24 | atis_work | putnopvut: maybe again the same "core show threads" bug? |
| 14:34.42 | putnopvut | It's possible. codefreeze-lap has been having difficulties because a certain lock would not show up in the "core show locks" output, IIRC. |
| 14:35.58 | atis_work | huh, is there any way to search for that in gdb? |
| 14:36.17 | atis_work | it's our testing server, so i can wait as long as necessary :) |
| 14:37.16 | putnopvut | The only way I know to do that is by searching a backtrace of all the threads, but that doesn't always work. |
| 14:38.11 | snuff-home | has made his own little git repository so hopefully when i screw up astobj2 of jabber i can easily revert some changes ;) |
| 14:39.22 | atis_work | well, i already grepped backtraces, but those i pasted in "core show locks" are only ones having that lock |
| 14:41.20 | atis_work | btw, here's the full backtrace http://www.pastebin.ca/1081887 |
| 14:42.07 | atis_work | putnopvut: i have few my own patches, so perhaps problem is in them.. btw, it's 1.6.0-r123772 |
| 14:45.34 | putnopvut | I can tell from the backtrace that the 0x94743c lock is a lock for a specific queue and that the 0x8fa44c is the lock for the queues container, if that helps to track it down any. |
| 14:47.58 | putnopvut | atis_work: are you using weights in your queues? |
| 14:48.07 | atis_work | putnopvut: yes |
| 14:49.19 | putnopvut | I thought I saw a potential locking problem when weights are involved. |
| 14:49.24 | putnopvut | But I think it's actually okay. |
| 14:50.04 | atis_work | putnopvut: well, all those patches worked fine on 1.4, but perhaps i messed something up while porting.. or it's just 1.6.0 issue |
| 14:51.15 | putnopvut | atis_work: I don't know how easy it was for you to get that deadlock to occur, but if possible, can you see if the same thing happens when using an unpatched 1.6.0? |
| 14:51.34 | atis_work | putnopvut: what's a queue container? ao2_list? |
| 14:51.43 | putnopvut | ao2_container |
| 14:52.00 | atis_work | huh, that would be hard.. our dialplan heavily uses some custom functionality.. |
| 14:53.47 | atis_work | oh, so i see queue members and queue lists are in ao2_container.. |
| 14:54.07 | putnopvut | That's correct. |
| 14:57.33 | atis_work | ok, i'll try to match logfile with threads, and get timing from that.. |
| 15:07.48 | tzafrir_laptop | was insects.digium.com activated? |
| 15:08.18 | tzafrir_laptop | Things look nicer |
| 15:08.18 | atis_work | hmm, interesting why log have only PID of logger thread.. |
| 15:08.33 | tzafrir_laptop | but I have a new attachment I can't mark as code |
| 15:09.13 | putnopvut | atis_work: ooh, I bet that's something that wasn't considered when changing how the threading worked for logging. |
| 15:09.23 | atis_work | yeah |
| 15:09.28 | atis_work | i'll search if it's open bug |
| 15:09.31 | putnopvut | atis_work: in 1.4 and below logging occurred in the same thread as the ast_log() call. |
| 15:09.41 | atis_work | probably that's why i can't match it with threads in gdb |
| 15:11.25 | atis_work | putnopvut: you are not going to fix it right away? i'll open an issue |
| 15:12.48 | putnopvut | atis_work: Yes, please open an issue. |
| 15:17.19 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:17.19 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:29.35 | atis_work | putnopvut: does "core show threads" show only one lock per thread? |
| 15:30.18 | *** join/#asterisk-dev bbryant (n=brett@216.207.245.1) |
| 15:30.22 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 15:30.33 | atis_work | putnopvut: it seems from last call, that queue was trying to ring members (i suppose that's where it locked queue), but didn't ringed any, then loaded members again and tried to lock the same lock again |
| 15:30.33 | putnopvut | core show threads doesn't show any lock information. Did you mean "core show locks?" |
| 15:30.39 | atis_work | yes |
| 15:31.13 | putnopvut | It should show all locks held by threads. |
| 15:32.00 | atis_work | even if thread is waiting for lock which was locked within the same thread? |
| 15:35.08 | file | it shouldn't be waiting |
| 15:35.48 | file | our mutex locks are initialized for recursive usage, and rwlocks can not be used recursively |
| 15:36.12 | Qwell | wow, I read that as "can not be used recursively", and almost fell out of my chair |
| 15:36.15 | Qwell | erm, can now* |
| 15:36.38 | file | it is possible to do it |
| 15:36.44 | file | but the data structure of an rwlock becomes much more complex |
| 15:43.23 | atis_work | putnopvut: does queue container have to be locked, before locking queue? |
| 15:44.07 | putnopvut | It does not have to be. |
| 15:44.32 | putnopvut | In fact, the only time the queue container is explicitly locked in app_queue is when weights are used. |
| 15:44.37 | putnopvut | I think... |
| 15:45.10 | putnopvut | Ah, it's used in load_realtime_queue, too. |
| 15:45.26 | putnopvut | Okay, it's used in a few places. Forget I said anything :) |
| 15:47.47 | atis_work | :) |
| 15:49.08 | atis_work | and does ao2_iterator_init(queues, 0) and ao2_iterator_next need to have lock before? |
| 15:49.27 | atis_work | sorry for stupid questions, i'm trying to understand how it works :) |
| 15:49.37 | putnopvut | No, the necessary locking is taken care of within the astobj2 code. |
| 15:49.49 | putnopvut | atis_work: stupid questions are always welcome :) |
| 16:02.35 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 16:04.33 | ctooley | I know this is probably a #asterisk question, but do the chan_zap, zaptel, Digium T1 card combinations support CAS signaling? |
| 16:06.31 | pabelanger | yes, which flavor are you going to be using? |
| 16:07.16 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 16:07.16 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 16:08.03 | eliel | something is wrong with mantis.. I think you also notice that.. |
| 16:08.15 | ctooley | pabelanger, I'm hoping not. |
| 16:09.19 | eliel | fixed. |
| 16:09.51 | *** join/#asterisk-dev oej (n=olle@81-224-166-188-o1036.telia.com) |
| 16:09.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:14.02 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 16:19.10 | *** join/#asterisk-dev moy (n=moy@nat/ibm/x-e7e0c5cfd4fe857f) |
| 16:23.39 | putnopvut | atis_work: I'm having some troubles with bugs.digium.com right now. Here's a patch for the log process ID problem. |
| 16:23.40 | putnopvut | http://pastebin.ca/1081964 |
| 16:24.25 | atis_work | putnopvut: oh, nice.. thanks :) |
| 16:26.39 | atis_work | seems to be working :) |
| 16:35.06 | putnopvut | atis_work: good! |
| 16:40.37 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 16:40.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:46.06 | putnopvut | atis_work: I uploaded the patch on bugs.digium.com now, too. |
| 16:51.06 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 16:51.08 | *** join/#asterisk-dev angler_ (n=angler@216.207.245.1) |
| 16:51.28 | *** join/#asterisk-dev Dovid (n=Dovid@tony09-121-90.inter.net.il) |
| 17:02.16 | eliel | What are those TAGS in mantis for? 'attachment', 'attachment.patch', and so on? |
| 17:02.50 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:04.30 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200.150.181.158) |
| 17:11.13 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 17:12.23 | *** join/#asterisk-dev xpot (n=jim@75.149.224.186) |
| 17:12.43 | tzafrir_laptop | eliel, I guess they should replace [patch] and alike |
| 17:14.08 | eliel | ok, i will wait and see... :-) |
| 17:23.25 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 17:23.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:30.10 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 17:47.37 | *** join/#asterisk-dev trelane (i=trelane@lan.trelane.net) |
| 17:56.42 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 18:01.11 | *** join/#asterisk-dev Dovid[laptop] (n=Dovid@tony09-121-90.inter.net.il) |
| 18:11.26 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 18:11.26 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 18:11.29 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 18:11.32 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 18:11.32 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 18:11.32 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 18:11.32 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 18:11.35 | *** join/#asterisk-dev angler_ (n=angler@216.207.245.1) |
| 18:11.40 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 18:11.40 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 18:11.45 | *** join/#asterisk-dev RichiH (i=richih@freenode/staff/richih) |
| 18:12.50 | ctooley | jbot, walk off a cliff, I'll be right behind you, I promise. |
| 18:13.02 | *** join/#asterisk-dev bbryant (n=brett@216.207.245.1) |
| 18:13.02 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 18:13.02 | Corydon76-dig | Phew, finally |
| 18:16.45 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 18:16.45 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:19.18 | ctooley | Corydon76-dig, just get past that last level to conquer the game? |
| 18:19.42 | ctooley | Corydon76-dig, or was "Phew, finally" a comment about me following jbot off a cliff? :) |
| 18:20.38 | Corydon76-dig | ctooley: no, the Digium connection was down for over an hour |
| 18:20.53 | ctooley | Corydon76-dig, super |
| 18:21.03 | Corydon76-dig | So I'm once again able to commit to SVN |
| 18:27.19 | *** join/#asterisk-dev Hertzy3 (n=ahertz@ahertz.atlantic.net) |
| 18:29.14 | Qwell | png is patent free, right? |
| 18:31.21 | Juggie | the 8 ball says yes |
| 18:31.58 | Juggie | its a patent free replacing for gif by w3c |
| 18:32.00 | putnopvut | Qwell: who cares, just commit the thing! |
| 18:32.06 | putnopvut | ducks |
| 18:32.53 | ctooley | might not matter soon anyway: http://www.patentlyo.com/patent/2008/07/the-death-of-go.html |
| 18:33.15 | Qwell | the death of go? |
| 18:33.31 | tzafrir_laptop | yeah, right. Noone elase but google has a working search |
| 18:33.31 | ctooley | Thankfully no, I love playing Go. |
| 18:33.43 | Juggie | do not pass go do not collect 200$ |
| 18:33.47 | tzafrir_laptop | go.com is dead |
| 18:34.12 | ctooley | go.com, now that could die and I wouldn't miss it a bit. |
| 18:34.27 | tzafrir_laptop | gif is also patent free by now |
| 18:35.02 | Juggie | but is vox patent free, thats important! |
| 18:35.27 | ctooley | tzafrir_laptop, October 1, 2006 was the patent expiration. |
| 18:35.36 | Qwell | weren't there multiple covering gif? |
| 18:35.39 | Qwell | or was that just the last one? |
| 18:35.40 | Juggie | so on a unrelated topic, should i run dd-wrt or tomato firmware on my router, anyone like tomato? |
| 18:35.43 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 18:35.50 | Qwell | Juggie: no tomatoes |
| 18:36.21 | Juggie | ok no squishy tomatoes |
| 18:38.26 | eliel | Qwell: png is patent free, but it is important? we are only reading the file and writing the same again, no transcoding is done... |
| 18:38.51 | eliel | reading and writing without translation... |
| 18:41.04 | eliel | hmm, ok, we are doing a reverse engeniering while cheking file format.. |
| 18:41.35 | ctooley | Qwell, but apparently the last one expired October 1, 2006 |
| 18:42.12 | Qwell | eliel: right, that "magic" string is why I was asking |
| 18:43.13 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 18:43.25 | ctooley | "The US LZW patent expired on June 20, 2003. The counterpart patents in the United Kingdom, France, Germany and Italy expired on June 18, 2004, the Japanese counterpart patents expired on June 20, 2004 and the counterpart Canadian patent expired on July 7, 2004. IBM patents all expired on October 1, 2006. Consequently, while Unisys has further patents and patent applications relating to improvements to the LZW technique, the GIF format may now be |
| 18:43.25 | ctooley | <PROTECTED> |
| 18:43.28 | ctooley | " |
| 18:44.18 | ctooley | sorry about the extraneous newline, thought I got them all removed. |
| 18:45.11 | *** join/#asterisk-dev Xaviertoor (n=Xavierto@200-146-243-009.xf-static.ctbcnetsuper.com.br) |
| 18:45.13 | Corydon76-dig | At some point, we may have a translator between the various image formats |
| 18:45.54 | Corydon76-dig | The only reason we haven't thus far is because there hasn't been any call for it |
| 18:46.16 | Corydon76-dig | but video translation would be cool, too |
| 18:46.25 | Qwell | ffmpeg |
| 18:47.17 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 18:57.17 | seanbright | we need an emacs major mode for ael |
| 18:57.17 | seanbright | that i don't have to write myself, that is. |
| 19:02.05 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:05.28 | Hertzy3 | Dovid[laptop]: Thanks for the help. I realized that sip.conf actually pulls from users.conf, and I had amiguous entries causing problems. |
| 19:09.51 | *** join/#asterisk-dev joetester (n=chatzill@216.191.34.13) |
| 19:12.59 | tzafrir_laptop | Is Centos 3.9 considered supported? |
| 19:13.09 | kpfleming | for what? asterisk? zaptel? dahdi? |
| 19:13.09 | tzafrir_laptop | in zaptel, that is |
| 19:13.13 | kpfleming | should be, yes |
| 19:13.22 | kpfleming | begrudgingly :-) |
| 19:13.50 | tzafrir_laptop | I figure you red Axel Thimm's post on the list |
| 19:14.16 | kpfleming | i saw it, but didn't pay a whole lot of attention |
| 19:15.11 | Juggie | centos 2.9 would be kernel 2.4 woudnt it? |
| 19:15.32 | codefreeze-lap | grunts |
| 19:16.18 | codefreeze-lap | I just posted a note to asterisk-dev, yielding the summation of my backporting mtxprof to 1.4 and running the same tests there that I ran on trunk |
| 19:16.19 | Juggie | er, 3.9 |
| 19:17.25 | codefreeze-lap | While the comparison of lock times on 1.4 vs trunk wasn't really enlightening per se, it did show a few things that *might* be culprits. |
| 19:19.45 | codefreeze-lap | The most interesting is the fact that in 1.4, to process like 830 calls, the routine channel_find_locked was called 3 times. |
| 19:20.17 | codefreeze-lap | but in trunk, to process like 1100 calls, it was called about 7000 times, and took like 6x longer per call than in 1.4 |
| 19:21.12 | seanbright | 7000 > 3 |
| 19:21.29 | codefreeze-lap | tends to think it might be involved |
| 19:22.11 | Juggie | that could be an issue potentially :) |
| 19:22.28 | codefreeze-lap | maybe! :D |
| 19:23.17 | ctooley | thanks codefreeze-lap profusely for all the time consuming work of performance debugging. |
| 19:23.28 | putnopvut | codefreeze-lap: do you know where these extra calls to channel_find_locked are occurring? |
| 19:23.56 | putnopvut | That can be a potentially slow function, especially when there are a lot of channels active. |
| 19:24.11 | ctooley | putnopvut, somewhere within ~/workspace/digium-svn/asterisk/trunk most likely. :) |
| 19:24.24 | putnopvut | ctooley: All right, that narrows it down some. |
| 19:24.44 | ctooley | you're welcome, I'll butt out again. |
| 19:24.44 | putnopvut | At least I know it's not my music causing the problem :) |
| 19:25.09 | seanbright | just maintain a list of channels and a hash of channels and you're done |
| 19:25.18 | seanbright | that would eliminate the expense at least |
| 19:25.31 | seanbright | glad i could help. |
| 19:26.26 | seanbright | or implement a sorted dictionary |
| 19:26.35 | Juggie | c++ list? :) |
| 19:26.54 | seanbright | Dictionary<string, Channel> |
| 19:26.55 | seanbright | heh |
| 19:26.58 | putnopvut | seanbright: russell actually has a branch where he's converted channels to use astobj2. That would certainly speed things up. |
| 19:27.08 | putnopvut | seanbright: what's the difference between a dictionary and a map? |
| 19:27.19 | seanbright | one of them can have null keys i think |
| 19:27.25 | putnopvut | wow, outside of a computer context, that last question would sound like either a joke setup or a really dumb question. |
| 19:27.31 | seanbright | not really sure to be honest |
| 19:28.00 | Juggie | at least your honest |
| 19:28.02 | seanbright | putnopvut: heh... well a dictionary has words in it... |
| 19:28.09 | seanbright | Juggie: you're |
| 19:28.49 | Juggie | seanbright: we dont need another lmadsen! |
| 19:29.04 | seanbright | Juggie: just carrying the torch in his absense |
| 19:29.22 | Juggie | XXX Note that this code has cost O(N) because of the need to verify that the object is still on the global list. |
| 19:29.22 | Juggie | XXX also note that accessing fields (e.g. c->name in ast_log()) can only be done with the lock held or someone could delete the object while we work on it. This causes some ugliness in the code. Note that removing the first ast_log() may be harmful, as it would shorten the retry period and possibly cause failures. We should definitely go for a better scheme that is deadlock-free. |
| 19:30.30 | seanbright | putnopvut: based on 30 seconds of wikipedia, i'm not convinced there is much of a difference |
| 19:30.49 | codefreeze-lap | Well, at most around 10 channels are active at any one time; so the find_channel locked isn't sucking large amounts of cycles because of the length of the list |
| 19:31.21 | codefreeze-lap | It's just that it locks the channel, and is being called a lot, that might be slowing things down |
| 19:31.44 | putnopvut | codefreeze-lap: right, the fact that it's being called a lot, and since channels get locked a lot, combines to make slow code. |
| 19:32.20 | Juggie | seanbright, is the dictionary object a microsoft thing? |
| 19:32.27 | seanbright | Juggie: tis |
| 19:32.34 | Juggie | ah, and map is stl. |
| 19:32.36 | Juggie | well there you go |
| 19:32.38 | seanbright | .NET generic collection |
| 19:32.43 | seanbright | map is java, too. |
| 19:32.48 | seanbright | SortedMap<K, V> is what we need |
| 19:33.03 | Juggie | ya i ment in C++ terms |
| 19:33.09 | seanbright | right |
| 19:33.16 | putnopvut | It doesn't need to be sorted. |
| 19:33.22 | codefreeze-lap | The assignment is, to find out WHY the channel_find_locked routine is getting called so often... |
| 19:33.26 | putnopvut | Actually, yeah, I guess it does need to be. |
| 19:33.38 | file | there is no real reason why it should be... |
| 19:34.00 | codefreeze-lap | (with a side note that removing the extra calls since 1.4 may be nigh to impossible...) |
| 19:34.03 | seanbright | well, either it should be or you have to write something to output it in sorted order |
| 19:34.18 | seanbright | so that 'core show channels' was usable |
| 19:35.13 | codefreeze-lap | for that kind of thing, you quickly collect the data, and then use qsort if order is important. |
| 19:35.28 | seanbright | but we're getting off track, the issue, as murf put it, is "WHY [is] the channel_find_locked routine ... called so often" |
| 19:35.42 | Juggie | seanbright, i would think it would be hella better to have code sort before outputing, then to keep a list in order as things are added, deleted. |
| 19:35.53 | seanbright | Juggie: i don't disagree |
| 19:43.07 | codefreeze-lap | ugh, channel find locked is front ended by 6 different functions |
| 19:44.01 | ctooley | codefreeze-lap, of course, it's a common thing that you'd want to know from a higher level function. Plus, if it wasn't that might be an easy step to debug, and that wouldn't work at all. |
| 19:44.31 | putnopvut | codefreeze-lap: hey, I might have an idea of why it's being called more often. |
| 19:44.47 | putnopvut | Check out ast_parse_device_state() |
| 19:45.04 | putnopvut | It calls ast_get_channel_by_name_prefix_locked (a front-end to channel_find_locked) |
| 19:45.19 | putnopvut | In 1.4, it only gets called if the channel technology has no devicestate callback. |
| 19:45.32 | putnopvut | In trunk, it's called even if the channel driver has a device state callback. |
| 19:45.46 | putnopvut | This will happen on every call to ast_device_state |
| 19:46.04 | putnopvut | Which means that every time a device changes states, that call will happen. |
| 19:46.21 | Juggie | can you do svn blame to see what revision it was changed in |
| 19:46.32 | Juggie | see if it was in response to a bug |
| 19:46.47 | putnopvut | Actually, that will only happen if channel driver returns AST_DEVICE_UNKNOWN. |
| 19:46.52 | putnopvut | Sorry, red herring. |
| 19:47.14 | seanbright | blame asterisk main/asterisk.c 12345 |
| 19:47.19 | seanbright | we need that ^^^ |
| 19:47.20 | putnopvut | I'll keep looking |
| 19:47.28 | seanbright | goes off to write add it to muffinman |
| 19:47.56 | Qwell | seanbright: what purpose would it serve? |
| 19:48.04 | Juggie | blaming file |
| 19:48.12 | Qwell | blame outputs an entire file |
| 19:48.18 | seanbright | ohhh |
| 19:48.20 | seanbright | you're right |
| 19:48.24 | seanbright | what am i thinking of |
| 19:48.28 | seanbright | annotate? |
| 19:48.35 | putnopvut | annotate == blame == praise |
| 19:48.37 | codefreeze-lap | putnopvut: I'll profile asterisk to see when/when. There are like 42 place where the ast_get_channel_* funcs are called, and 8 places where ast_walk_channel_by_* funcs are called. |
| 19:48.38 | Qwell | same thing |
| 19:48.40 | seanbright | yeah |
| 19:48.41 | seanbright | damn |
| 19:48.42 | seanbright | ah well |
| 19:48.57 | putnopvut | But it's possible to grep for a line number. |
| 19:49.26 | codefreeze-lap | I'll report back after I come to some conclusion |
| 19:50.05 | putnopvut | codefreeze-lap: another potential spot to look at in trunk is the handle_show_chanvar and handle_set_chanvar functions in pbx.c |
| 19:50.44 | putnopvut | d'oh, those are CLI command handlers. |
| 19:50.49 | putnopvut | jeez. |
| 19:51.16 | codefreeze-lap | putnopvut: hang on, I'll be profiling here in a minute |
| 19:51.17 | ctooley | putnopvut, so far my pointers have been almost as good. :) |
| 19:51.19 | Corydon76-dig | Frick... sip rt caching is completely screwed |
| 19:51.29 | seanbright | Frick? |
| 19:51.31 | seanbright | ok elliot |
| 19:51.39 | putnopvut | ooh, scrubs reference |
| 19:52.32 | ctooley | Corydon76-dig, Not to make light of the huge amount of effort that's gone into chan_sip.c already, but that can be said about quite a bit more than just RT caching. |
| 19:53.20 | Corydon76-dig | ctooley: what I'm trying to work on now, though |
| 19:54.18 | Corydon76-dig | According to the docs, rt caching is supposed to be for a limited time, not forever-until-reload, the way it is now |
| 19:54.32 | ctooley | Corydon76-dig, so I've noticed |
| 19:54.59 | Corydon76-dig | and rtautoclear is therefore completely non-functional |
| 20:00.00 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 20:00.05 | codefreeze-lap | putnopvut gets the prize! |
| 20:00.14 | putnopvut | what for? |
| 20:00.28 | putnopvut | And what's the prize? :) |
| 20:00.59 | jameswf-home | free software |
| 20:01.10 | putnopvut | oh boy! |
| 20:01.28 | jameswf-home | but it only runs in windows... |
| 20:01.44 | codefreeze-lap | Just ran profiled asterisk, on 975 sip calls; channel_find_locked run 5747 times purely by ast_get_channel_by_name_prefix_locked, purely from ast_parse_device_state(). |
| 20:01.55 | tzafrir_laptop | jameswf-home, open-windows? |
| 20:02.21 | ctooley | tzafrir_laptop, that might be just as brutal as Microsoft Windows at this point. :) |
| 20:02.24 | codefreeze-lap | putnopvut: the prize is a hearty "attaboy", and a firm thump on the back... errr, "pat" on the shoulder! |
| 20:02.40 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:09.49 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 20:09.49 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 20:10.53 | russellb | putnopvut: here for the rundown. |
| 20:11.00 | codefreeze-lap | Hmmmm. ast_parse_device_state hasn't changed that call since version 6063. That's probably before 1.4; so we need to see all the places where it's called instead... |
| 20:11.15 | putnopvut | russellb: well, here's the scoop. |
| 20:11.37 | putnopvut | murf suspected that a large number of channel_find_locked calls were contributing to the slowdown in trunk. |
| 20:11.53 | putnopvut | In fact, for 1100 calls in trunk, the function was called 7000 times. |
| 20:12.02 | putnopvut | Whereas for 800 calls in 1.4, it was called only 3 times. |
| 20:12.06 | russellb | nods ... saw that on -dev |
| 20:12.15 | russellb | (list) |
| 20:12.35 | putnopvut | So, I started searching and suggested that it may be ast_parse_device_state that was calling it since it will get called on every single device state change. |
| 20:12.50 | putnopvut | Or at least it has the potential to. |
| 20:12.55 | codefreeze-lap | I'm trying to see why ast_parse_device_state is being called often now, when in 1.4, it wasn't |
| 20:12.59 | putnopvut | Even for channel drivers which have a device state callback. |
| 20:13.25 | russellb | putnopvut: right, that's done in 1.4 as well ... |
| 20:13.41 | putnopvut | But in 1.4, it only happens if the channel driver has no devicestate callback. |
| 20:14.24 | putnopvut | It looks like in trunk it should only happen on an AST_DEVICE_UNAVAILABLE return, but apparently it's happening very often, even for channels who have a devicestate callback. |
| 20:14.44 | codefreeze-lap | hmmm. only two places in the code call it... up we go |
| 20:15.21 | russellb | the logic was restructured, but looks the same to me (looking at ast_device_state()) |
| 20:15.24 | russellb | where are you looking? |
| 20:15.32 | putnopvut | Where you are. |
| 20:15.48 | putnopvut | I suppose that what could be happening is that sip_devicestate is returning AST_DEVICE_UNKNOWN a lot in trunk. |
| 20:16.08 | putnopvut | (I said "unavailable" before but meant "unknown") |
| 20:16.11 | russellb | maybe so ... the logic of what gets called in what scenario is the same ... |
| 20:16.26 | russellb | it says UNKNOWN in both |
| 20:16.32 | russellb | ok |
| 20:16.51 | russellb | hrm! |
| 20:17.02 | codefreeze-lap | ast_device_state does both calls... up again |
| 20:17.07 | putnopvut | The only condition under which chan_sip returns AST_DEVICE_UNKNOWN is if it cannot find the peer we want. |
| 20:17.11 | codefreeze-lap | (you guys are ahead of me) |
| 20:17.23 | russellb | heh |
| 20:17.33 | kpfleming | how about you get on a conference bridge :-) |
| 20:17.33 | russellb | so maybe some logging in chan_sip to see if it's returning UNKNOWN, and how often .. |
| 20:17.35 | putnopvut | Which could very well happen if the device state function were called with a full channel name instead of just SIP/BLAH |
| 20:17.45 | russellb | kpfleming: pfft .. we don't _use_ this technology ... |
| 20:17.56 | kpfleming | true enough |
| 20:18.41 | russellb | putnopvut: yeah, i guess it's possible trunk is calling it with the channel name more often or something |
| 20:18.57 | putnopvut | russellb: I'd suspect the same from 1.4, though, to be honest. |
| 20:19.02 | russellb | nods |
| 20:19.34 | putnopvut | Perhaps in trunk, though, chan_sip does more with the bogus peer name. |
| 20:19.53 | russellb | putnopvut: if you look through ast_device_state_changed() calls in chan_sip, it uses the peer name everywhere |
| 20:20.03 | russellb | what do you mean by "bogus peer name" |
| 20:20.12 | seanbright | SIP/Foo-ABCDEF |
| 20:20.20 | putnopvut | russellb: in channel.c, ast_device_state_changed_literal is called with the full channel name. |
| 20:20.44 | putnopvut | Which causes __ast_device_state_changed_literal to pass that string to SIP's devicestate callback. |
| 20:20.46 | oej | putnopvut: But that only happens if there's no hook in the chan->tech, right? |
| 20:21.20 | putnopvut | oej: no it happens on every ast_channel_free and every ast_setstate call |
| 20:21.33 | russellb | same code in 1.4 ... |
| 20:21.34 | oej | I have some code to add channel names to those calls in a branch for the call pickup. |
| 20:21.51 | putnopvut | russellb: right, I'm going to check chan_sip's find_peer to see if that could be making a difference. |
| 20:21.53 | russellb | putnopvut: using the full chan name that is ... |
| 20:22.19 | codefreeze-lap | every time, do_state_change() called them |
| 20:22.42 | putnopvut | codefreeze-lap: did you happen to see the name of the device that was being asked to change? |
| 20:22.57 | codefreeze-lap | no, this is just the profile data |
| 20:23.12 | codefreeze-lap | But, I'll break there and tell you |
| 20:23.23 | putnopvut | codefreeze-lap: thanks |
| 20:25.46 | codefreeze-lap | putnopvut: It's being called with "SIP/5060-0b93b0c8" |
| 20:26.15 | codefreeze-lap | (the usual kinda name from sipp, I guess) |
| 20:26.44 | putnopvut | Okay, it makes sense that chan_sip would return AST_DEVICE_UNKNOWN given that input. |
| 20:26.55 | russellb | putnopvut: will 1.4 do that as well? |
| 20:26.56 | putnopvut | Now to figure out why it takes so much longer in trunk for that to process instead of 1.4. |
| 20:27.02 | putnopvut | russellb: yes. |
| 20:27.14 | putnopvut | This is all, of course, assuming that this is a major speed bottleneck. |
| 20:27.27 | codefreeze-lap | could verify that in a few minutes, but putnopvut is most likely correct |
| 20:28.10 | codefreeze-lap | putnopvut: true, it's just theory, but 7000 vs 3 is a pretty flagrant difference |
| 20:28.22 | russellb | at the same time, i would still expect the exact same number of calls to ast_parse_device_state given what we've said so far |
| 20:28.29 | russellb | so i'm still missing the piece that explains 7000 vs. 3 |
| 20:28.39 | putnopvut | russellb: you're exactly right. |
| 20:28.49 | russellb | k, just making sure we're on the same page |
| 20:28.59 | kpfleming | page 42 |
| 20:29.15 | tzanger | heh |
| 20:29.18 | russellb | exactly, page 42, which is 800 km in size, weight, and density |
| 20:29.19 | tzanger | damn I'm on 36 |
| 20:29.49 | codefreeze-lap | is still trying to figure out what the heck page number he's on |
| 20:30.05 | Qwell | codefreeze-lap: Do you see the words "copyright" anywhere on the page? |
| 20:30.09 | Qwell | word |
| 20:30.11 | russellb | ok, SO. um... |
| 20:30.37 | codefreeze-lap | so, the assignment is still to find out why 7000 vs. 3 |
| 20:30.42 | russellb | yes |
| 20:31.04 | russellb | i'm going to feel terrible if this is all my fault :-p |
| 20:31.13 | codefreeze-lap | The 3 probably came from the loading of the chan_sip file or somthing related |
| 20:31.22 | seanbright | russellb: i blame you regardless. |
| 20:31.29 | tzanger | that's safest. |
| 20:31.35 | russellb | thanks for the confidence |
| 20:31.37 | codefreeze-lap | russellb: no, you shouldn't... ya code first, then you optimize if necc. |
| 20:31.43 | seanbright | my pleasure |
| 20:31.45 | seanbright | :) |
| 20:31.47 | tzanger | that reminds me |
| 20:31.50 | tzanger | I gotta get on this x64 install |
| 20:33.03 | *** join/#asterisk-dev jameswf (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 20:33.25 | codefreeze-lap | I had two calls after the cli activated, about SIP/murf, in my sip.conf file, which is not part of the test |
| 20:33.50 | seanbright | so it's 7000 vs. 1 now? |
| 20:34.50 | seanbright | nevermind, i am out of my element at the moment. |
| 20:34.54 | russellb | codefreeze-lap: so you verified that all of the channel_find_locked calls are a result of parse_device_state? and that all of those calls are a result of ast_state_change, all called from do_state_change? |
| 20:35.13 | codefreeze-lap | yep, every single time. |
| 20:35.23 | russellb | ok, thank you' |
| 20:35.54 | Juggie | you may go and get yourself a dr pepper. |
| 20:40.01 | putnopvut | Perhaps, ast_setstate is being called a lot more often in trunk? |
| 20:40.39 | russellb | that would do it |
| 20:41.24 | codefreeze-lap | russellb: in my short, profiled run, do_state_change() was called 5750 times, by do_devstate_changes(); it appears to be called once, and must be a sleep/poll sort of thing. |
| 20:43.17 | putnopvut | codefreeze-lap: you're correct. There are two functions which can cause sip's device state function to return AST_DEVICE_UNKNOWN. |
| 20:43.24 | putnopvut | Well, indirectly. |
| 20:43.30 | putnopvut | ast_channel_free, and ast_setstate. |
| 20:43.48 | putnopvut | If either of those are being called a lot more often in trunk than in 1.4, that may point to the cause. |
| 20:43.51 | putnopvut | of the slowdown. |
| 20:44.20 | russellb | try ast_setstate ... it's more likely, for sure |
| 20:45.01 | codefreeze-lap | I just ran again under trunk, and broke in do_state_change(), and it's being called half the time with "SIP/6050", and half the time with "SIP/5060-0b89a9b8" |
| 20:46.14 | putnopvut | codefreeze-lap: that's because of the way __ast_device_state_changed_literal works. |
| 20:46.29 | russellb | and should be the same in 1.4 ... |
| 20:46.35 | putnopvut | right |
| 20:46.44 | Corydon76-dig | putnopvut: 12771 will change that |
| 20:46.50 | russellb | M12771 |
| 20:46.54 | putnopvut | Corydon76-dig: right |
| 20:46.55 | MuffinMan | [new] [Asterisk] Applications/app_queue 0012771: [patch] Bogus <member> is still 'Not in Use' warnings for AgentLogin'ed agents. reported by davidw (Karma: +0.25) http://bugs.digium.com/view.php?id=12771 |
| 20:47.12 | codefreeze-lap | ast_setstate was called 18 times |
| 20:47.17 | Corydon76-dig | It's simply a huge hassle to try to deal with both forms |
| 20:47.21 | russellb | rawr, so that's not it |
| 20:47.33 | putnopvut | dangit |
| 20:49.04 | codefreeze-lap | ast_channel_free was called 6 times |
| 20:49.35 | putnopvut | This is starting to make less sense, now. |
| 20:49.45 | putnopvut | codefreeze-lap: for how many calls? |
| 20:50.03 | russellb | codefreeze-lap: are you 100% confident in the accuracy of these numbers? :) |
| 20:50.09 | russellb | the 7000 vs. 3 thing ... |
| 20:50.30 | seanbright | looks around for a wild goose |
| 20:50.32 | codefreeze-lap | russellb: yes. It's in the profile data |
| 20:50.35 | russellb | k :) |
| 20:50.49 | russellb | this is using your mtx_prof branches? |
| 20:50.57 | codefreeze-lap | russellb: yes |
| 20:50.59 | putnopvut | Maybe somehow a sip peer is ending up with a name like BLAH-5fc2e42? |
| 20:51.05 | putnopvut | That would be weird and unlikely though |
| 20:51.18 | codefreeze-lap | russellb: and verified in my gprof profiling. |
| 20:51.23 | russellb | codefreeze-lap: ok, cool |
| 20:51.53 | russellb | codefreeze-lap: can you log when the sip devicestate callback fails to find a peer, and what the name was that it was looking up? |
| 20:52.03 | russellb | to see if the lookup is succeeding when you would expect it to? |
| 20:52.23 | putnopvut | good call there |
| 20:52.51 | russellb | ast_verbose("Failed to find a peer called '%s'\n", host); in the else block |
| 20:52.58 | russellb | or whatever |
| 20:53.21 | codefreeze-lap | russellb: which func are we talking about? |
| 20:53.30 | russellb | sip_devicestate() in chan_sip.c |
| 20:53.32 | russellb | in trunk |
| 20:54.12 | russellb | interesting note ... there is a difference in behavior with 1.4 and trunk in that function ... |
| 20:54.42 | russellb | if a peer isn't found, but it can be resolved via DNS, the result is UNKNOWN, otherwise INVALID. trunk doesn't do that. if no peer is found, it will be UNKNOWN. |
| 20:54.56 | russellb | however i dont' suspect that is related to murf's setup from the sound of it |
| 20:55.21 | codefreeze-lap | sip_devicestate was called 42 times (lol, that's the page # we were on) |
| 20:55.49 | putnopvut | russellb: actually that sounds like it could be related if I hear you right. |
| 20:55.56 | putnopvut | s/hear/read/ |
| 20:56.08 | russellb | putnopvut: *thinks* ... yeahhh ... |
| 20:56.19 | russellb | putnopvut: yes, i think you're right. |
| 20:56.24 | russellb | patch coming ... |
| 20:56.28 | codefreeze-lap | wait |
| 20:56.41 | codefreeze-lap | stupid gmon.out got overwritten! |
| 20:57.52 | codefreeze-lap | disregard all numbers given since... a few minutes back |
| 20:57.57 | russellb | O.O |
| 20:58.18 | seanbright | found the wild goose |
| 20:58.35 | codefreeze-lap | lessee, disregard the 42, 18, and 6 |
| 20:58.40 | putnopvut | it still makes sense that the change in behavior in sip_devicestate would cause the increased number of calls to channel_find_list_locked, or whatev. |
| 20:58.49 | russellb | putnopvut: yes, it does |
| 20:59.12 | russellb | trying to post a patch |
| 20:59.33 | putnopvut | to the mantis issue? |
| 20:59.36 | russellb | no |
| 20:59.43 | russellb | pb .. |
| 20:59.50 | russellb | my dev box is being a nub |
| 21:00.04 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 21:00.05 | seanbright | paste2pastebin.pl rocks |
| 21:00.08 | ctooley | it probably can't reach SVN due to SSL issues. :) |
| 21:00.22 | putnopvut | russellb: are you also going to incorporate Corydon76-dig's 12771 patch too? |
| 21:00.27 | russellb | putnopvut: |
| 21:00.27 | russellb | no |
| 21:00.55 | russellb | putnopvut: as i only want to touch differences between 1.4 and trunk |
| 21:01.04 | russellb | otherwise, we're not comparing apples to apples anymore |
| 21:01.16 | russellb | codefreeze-lap: http://pastebin.com/m107241eb |
| 21:01.29 | putnopvut | Okay, for the purpose of comparison that makes perfect sense. |
| 21:01.44 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 21:01.53 | putnopvut | Any idea why that was removed from trunk? |
| 21:02.06 | russellb | putnopvut: not a clue |
| 21:02.10 | putnopvut | It's hard to svn blame something that's not there anymore :) |
| 21:02.21 | russellb | putnopvut: we'd have to do a binary search to find out when it got removed ... |
| 21:02.21 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 21:02.25 | russellb | putnopvut: let's see if it explains it first |
| 21:02.27 | Corydon76-dig | Just found why a SIP realtime cached peer won't expire |
| 21:02.27 | russellb | (probably does) |
| 21:02.29 | Qwell | actually |
| 21:02.35 | Qwell | a friend of mine has a script that does exactly that :P |
| 21:02.36 | Qwell | sec |
| 21:02.50 | file | that may... have been... me |
| 21:03.00 | putnopvut | file: you're Qwell's friend? |
| 21:03.06 | file | no! I may have made the change |
| 21:03.13 | putnopvut | oh. |
| 21:03.19 | Corydon76-dig | When it tries to go out of memory, it queues a devicestate change, goes out of memory, and the next thread says "oh, someone asked for a devicestate change" and loads it BACK into memory |
| 21:03.21 | russellb | codefreeze-lap: plz to be testing that change. |
| 21:03.39 | codefreeze-lap | russellb: I'm on it |
| 21:03.45 | russellb | codefreeze-lap: thx! |
| 21:04.03 | putnopvut | hopes for the best in the next round of tests. |
| 21:04.14 | putnopvut | yeah that rhymed. What of it? |
| 21:04.14 | Corydon76-dig | ad infinitum |
| 21:04.54 | *** join/#asterisk-dev pabelanger (n=pabelang@OTWAON23-1242541604.sdsl.bell.ca) |
| 21:05.40 | russellb | annotating chan_sip takes a while. |
| 21:06.40 | seanbright | you can annotate removals? |
| 21:06.53 | russellb | seanbright: not easily |
| 21:07.58 | Qwell | seanbright: see above |
| 21:08.37 | seanbright | doesn't see anything above |
| 21:08.54 | seanbright | except drop-tiled ceilings |
| 21:09.17 | Qwell | http://deport.me/blame_game.pl |
| 21:09.32 | seanbright | ohhh |
| 21:09.33 | seanbright | nice |
| 21:10.14 | Qwell | escape anything bash might mangle |
| 21:11.44 | seanbright | commit asterisk 98954 |
| 21:11.55 | MuffinMan | [98954] Committed by file on 2008-01-16T02:30:13.459129Z: Remove DNS lookup from sip_devicestate. This seems to come from way back when and I can't think of a reason for it being here, plus it could cause needless DNS lookups. |
| 21:11.55 | MuffinMan | ..(closes issue #10983) |
| 21:11.55 | MuffinMan | ..Reported by: jtodd |
| 21:12.10 | file | I thought so! |
| 21:12.16 | Qwell | seanbright: use the script to find it? |
| 21:12.31 | seanbright | Qwell: no, did a find on the log page for "state" |
| 21:12.34 | Qwell | ahh |
| 21:13.23 | seanbright | spanks file |
| 21:13.28 | russellb | file: well um ... i think we should ... put it back. |
| 21:13.32 | putnopvut | The change makes sense in a way. It seems like an incredibly rare case that the DNS lookup would accomplish anything. |
| 21:13.32 | seanbright | in a non-creepy way |
| 21:13.42 | russellb | thinks about it for a minute ... |
| 21:13.58 | putnopvut | russellb: another possible change is just to not return AST_DEVICE_UNKNOWN in the case that a peer can't be found. |
| 21:14.22 | russellb | putnopvut: that would be a problem ... |
| 21:14.31 | russellb | putnopvut: if you don't say UNKNOWN, the core won't try to look in the channel list |
| 21:14.50 | putnopvut | Isn't that what we're trying to accomplish? |
| 21:14.58 | russellb | i think the logic was, if it's not a peer name, and it's not something we can look up via DNS, then it's just plain not a valid SIP device thingy. |
| 21:15.06 | codefreeze-lap | russellb: OK, that knocked the number of times ast_parse_device_state() got called to 2 with over 1400 sipp calls. I'll rerun the tests without all the profiling. |
| 21:15.19 | russellb | codefreeze-lap: thanks :) |
| 21:15.20 | kpfleming | but if we can look it up via DNS, what does that accomplish? |
| 21:15.43 | russellb | kpfleming: because you can Dial(SIP/pbx.digium.com) for example ... and if we have active channels to that "peer", we can report that it is in use |
| 21:15.53 | russellb | even though it's not a peer in sip.conf |
| 21:16.04 | kpfleming | but we'll find that out by doing a channel name search anyway |
| 21:16.19 | kpfleming | so what does the validity of a DNS lookup in that case prove? |
| 21:16.22 | putnopvut | Of course, most of the DNS lookups will be spurious, so Corydon76-dig's fix in 12771 should be added, too in the long run. |
| 21:17.06 | russellb | well, the DNS lookup may not be the best way, but it filters out some things where we shouldn't even be trying to look in the channel list |
| 21:17.12 | kpfleming | oh |
| 21:17.45 | russellb | and yes putnopvut, you may be right, i haven't looked at the patch, but if we could avoid the calling of the device state code with a full channel name, and the stripped one, that would also filter out the bogus crap |
| 21:17.56 | russellb | filtering out the bogus lookups is key here. |
| 21:18.44 | russellb | (background for those following along at home, when you say the device state of "SIP/5060-abc123" has changed, it tries to process SIP/5060, and SIP/5060-abc123) |
| 21:18.50 | putnopvut | russellb: and correct me if I'm wrong, but we could eliminate looking in the channel list (for channels with a device state callback) because we would know that the device in question wouldn't be found in the channel list. |
| 21:18.58 | putnopvut | Unless we searched by prefix. |
| 21:19.16 | russellb | it does search by prefix |
| 21:19.21 | russellb | and we can't do that anyway |
| 21:19.30 | russellb | because just because it has a device state callback, doesn't mean the channel driver knows the state |
| 21:19.41 | russellb | a lot of the time it just punts to the core to go figure it out |
| 21:19.46 | russellb | which is what returning UNKNOWN means |
| 21:19.52 | putnopvut | Ah, I didn't realize. |
| 21:20.05 | russellb | it's not a pretty situation |
| 21:20.14 | ctooley | Now that seems extremely backwards to me. |
| 21:21.06 | putnopvut | ctooley: you mean that a channel wouldn't know its own state but that the core would? |
| 21:21.11 | *** join/#asterisk-dev NickKoji (n=nicholas@168-215-215-195.static.twtelecom.net) |
| 21:21.26 | russellb | chan_iax2 is kind of mimumal in that regard.... if it doesn't find a peer, it returns INVALID. otherwise, if it's a dynamic peer and unregistered, it's UNAVAILABLE. otherwise, it punts ... |
| 21:21.51 | ctooley | putnopvut, yes |
| 21:21.55 | russellb | yes, it is backwards, and it was done out of convenience ... however, it has caused a lot of pain, and has caused the device state code to be a huge mess |
| 21:22.23 | russellb | the "right" way is to rip out _ALL_ core processing, and let the channel drivers do full control of the state, but that's a lot of work ... |
| 21:22.37 | russellb | and i don't want to go down the tangent of how to rearchitect it right now |
| 21:22.40 | ctooley | 3.0 here we come. :) |
| 21:22.41 | NickKoji | Hello, i am farely new to VoIP and asterik i was wondering what website you would recommend to begin reading and understanding the basics. I will be installing asteriknow onto my box |
| 21:22.47 | russellb | NickKoji: #asterisk |
| 21:22.59 | NickKoji | thank you |
| 21:23.57 | *** join/#asterisk-dev eliel-iphone (n=mobile@200.123.176.161) |
| 21:26.29 | russellb | reads the patch from 12771 ... |
| 21:27.55 | ctooley | codefreeze-lap, Are you running a new round of tests to test speed differences? |
| 21:29.52 | russellb | putnopvut: Corydon76-dig: Ok, I agree with the ptch in 12771. I _think_ that should solve this same problem in a better way, and without having to put the DNS lookup hack back in there. |
| 21:30.14 | russellb | So, codefreeze-lap, I'd also like you to test trunk with the changes in 12771 |
| 21:30.53 | russellb | thinks we have found the core issue at hand |
| 21:30.57 | ctooley | both with and without the DNS hack? |
| 21:31.19 | ctooley | assumes that the changes in 12771 negate the DNS hack |
| 21:31.23 | russellb | i think with the DNS lookup hack, it will be back to normal, but Tilghman's patch will fix it in a better way |
| 21:31.27 | russellb | yes, that is correct |
| 21:32.25 | Corydon76-dig | Yeah, I was trying to solve 12771 seven ways from Sunday, and just making the function more strict is a much simpler way to go |
| 21:33.12 | putnopvut | I would suspect that the 12771 patch could have the effect of speeding up both 1.4 and trunk. |
| 21:33.18 | russellb | putnopvut: yes :) |
| 21:33.25 | russellb | at least a little bit, yeah, for sure |
| 21:33.47 | russellb | actually ... a lot |
| 21:33.59 | russellb | it will cut the number of peer container traversals in half |
| 21:34.04 | russellb | in 1.4, that will be significant |
| 21:34.19 | russellb | in trunk, it shouldn't matter as much, given the hash container |
| 21:36.34 | russellb | ok, what's the next crisis we need to solve? :) |
| 21:36.57 | putnopvut | russellb: don't ask that :) |
| 21:36.58 | ctooley | Does that mean 12771 is going into 1.4? |
| 21:36.58 | Qwell | russellb: ^^ < |
| 21:37.04 | Qwell | russellb: see jabber :D |
| 21:37.05 | russellb | ctooley: yes |
| 21:37.11 | ctooley | Awesome |
| 21:38.33 | russellb | commit commit commit commmittttt |
| 21:38.34 | MuffinMan | Invalid repository given. |
| 21:38.52 | ctooley | :) |
| 21:39.15 | seanbright | commit asterisk 123456 |
| 21:39.25 | MuffinMan | [123456] Committed by mmichelson on 2008-06-17T20:19:49.079612Z: Add the same fix from revision 123271 to container_destruct_debug. |
| 21:39.32 | seanbright | putnopvut: you son of a bitch |
| 21:39.35 | putnopvut | lol |
| 21:39.42 | putnopvut | Yeah, I was proud of that one. |
| 21:39.57 | seanbright | i'm going to get 654321 |
| 21:40.02 | seanbright | in 3 1/2 years |
| 21:40.12 | putnopvut | freaking automerge got 100000 |
| 21:40.16 | ctooley | it's funny that the solution to 12772 came out of the resolution to 12771 |
| 21:40.19 | seanbright | unbelievable |
| 21:40.34 | seanbright | i hate automerge, and his wee beady eyes |
| 21:42.19 | pabelanger | Oh, your going to by my chicken... |
| 21:42.22 | seanbright | hehe |
| 21:42.40 | seanbright | because he puts an addictive chemical in his chicken that makes you crave it fortnightly... smartassss |
| 21:42.54 | seanbright | will stop |
| 21:43.06 | Corydon76-dig | seanbright: I prefer my 127001 |
| 21:43.46 | seanbright | i wonder who got my birthday |
| 21:44.01 | seanbright | commit asterisk 010879 |
| 21:44.11 | MuffinMan | [10879] Committed by root on 2006-02-23T18:01:14.501834Z: automerge commit |
| 21:44.17 | seanbright | sonofa... |
| 21:45.33 | putnopvut | seanbright: is that Jan 8 or Aug 1? |
| 21:45.44 | seanbright | putnopvut: i'm from the USA |
| 21:45.50 | putnopvut | so Jan 8 :) |
| 21:45.54 | seanbright | yes |
| 21:46.10 | pabelanger | was curious on feedback about a patch to set ASTVARRUNDIR=/var/run/asterisk on a default linux install? |
| 21:46.38 | seanbright | pabelanger: what is it set to now? |
| 21:46.39 | putnopvut | I had an Indian friend whose birthday was Nov 2. His license had 2/11/<year> on it. So the year he turned 21, he started drinking nine months early. |
| 21:46.56 | seanbright | putnopvut: that's *awesome* |
| 21:47.02 | ctooley | seanbright, automerge got mine too. |
| 21:47.35 | seanbright | i went to the same bar on my 21st birthday that i had drank at for the previous 3 years |
| 21:47.39 | pabelanger | "/var/run" |
| 21:48.00 | seanbright | pabelanger: ah |
| 21:48.34 | seanbright | pabelanger: i have no opinion either way on that one |
| 21:48.46 | pabelanger | major reason, each time we setup asterisk to run as non root, we need to manual make sub-asterisk directory to setup permissions. |
| 21:49.37 | seanbright | pabelanger: seems reasonable, have you submitted the patch into mantis? |
| 21:49.38 | pabelanger | plus, this looks to be the only file in asterisk, besides executables / init.d scripts that is not installed under a asterisk folder |
| 21:49.46 | pabelanger | nope, can do it now |
| 21:49.53 | seanbright | pabelanger: cool, will get more attention that way |
| 21:49.56 | pabelanger | wanted to check here first |
| 21:49.58 | pabelanger | kk |
| 21:57.04 | codefreeze-lap | running a perf test on trunk now. at 270 cps and ok |
| 21:57.13 | russellb | !!! |
| 21:57.14 | Qwell | codefreeze-lap: is that a good thing? |
| 21:57.19 | russellb | ctooley: ^^^ |
| 21:57.25 | Qwell | ctooley: is that a good thing? |
| 21:57.30 | codefreeze-lap | at 300 and ok |
| 21:57.30 | Qwell | russellb: ^^^ |
| 21:57.34 | russellb | yes, it's very good |
| 21:57.37 | Qwell | oic |
| 21:57.39 | codefreeze-lap | (was 100 and conk out time) |
| 21:57.41 | russellb | it was dying way before that ... |
| 21:57.42 | Qwell | then...yay? |
| 21:57.55 | Qwell | is 1.4 faster too then? |
| 21:58.03 | seanbright | you typed that backwards. it's "yay" |
| 21:58.05 | ctooley | That's back to where 1.4 was |
| 21:58.05 | codefreeze-lap | at 350 and ok still |
| 21:58.13 | ctooley | Good. |
| 21:58.30 | ctooley | codefreeze-lap, I'd let 350 run for a bit and see how that settles out. |
| 21:58.32 | codefreeze-lap | at 400 and still ok |
| 21:58.37 | seanbright | heh |
| 21:58.41 | seanbright | i feel like we're landing on the moon |
| 21:58.57 | russellb | me too :) |
| 21:58.59 | snuff-home | what did u have before with initial conv? like almost 1000 ? |
| 21:59.00 | codefreeze-lap | will sit at 400 for a while and see |
| 21:59.00 | ctooley | would really love to see that 600 mark broken though. :) |
| 21:59.00 | russellb | I am pumped |
| 21:59.05 | codefreeze-lap | still ok |
| 21:59.15 | Qwell | russellb: good - let's go win |
| 21:59.16 | Qwell | D: |
| 21:59.19 | russellb | codefreeze-lap: thanks for the diligent work, sir :) |
| 21:59.24 | russellb | time to go play softball! |
| 21:59.30 | ctooley | Thanks to all of you guys for getting it resolved. |
| 21:59.32 | codefreeze-lap | 420 now |
| 21:59.37 | seanbright | 420! |
| 21:59.40 | russellb | w0t |
| 21:59.41 | seanbright | goes to smoke |
| 21:59.42 | russellb | lol |
| 21:59.52 | codefreeze-lap | 430 and still ok |
| 22:00.01 | codefreeze-lap | I expect it to die around 450 |
| 22:00.08 | Qwell | jump to 1200! |
| 22:00.09 | russellb | it's hard to leave, lol |
| 22:00.10 | seanbright | wonders what audio quality looks like ATM |
| 22:00.20 | codefreeze-lap | 440 and strong |
| 22:00.25 | putnopvut | This is awesome, but I have softball to win. |
| 22:00.26 | putnopvut | Bye! |
| 22:00.34 | putnopvut | codefreeze-lap: great work, man! |
| 22:00.39 | codefreeze-lap | 450 and no complaints |
| 22:00.58 | codefreeze-lap | 0 retrans so far |
| 22:01.05 | ctooley | cool |
| 22:01.07 | snuff-home | 0 retrans.. nice |
| 22:01.16 | seanbright | codefreeze-lap: just curious, what is processor utilization? |
| 22:01.21 | codefreeze-lap | 460 now |
| 22:01.41 | codefreeze-lap | seanbright: get back to you on that |
| 22:01.48 | seanbright | will wait here |
| 22:01.57 | codefreeze-lap | 470 now |
| 22:02.19 | codefreeze-lap | 480 |
| 22:02.27 | codefreeze-lap | hee hee |
| 22:02.56 | codefreeze-lap | 490 and ok |
| 22:03.12 | ctooley | drum roll please.... |
| 22:03.12 | codefreeze-lap | 52 calls simul |
| 22:03.29 | codefreeze-lap | almost 180 k calls total |
| 22:03.36 | pabelanger | sorry, can I ask what tests your running? |
| 22:03.40 | codefreeze-lap | 500 now |
| 22:03.55 | codefreeze-lap | still OK |
| 22:03.58 | ctooley | pabelanger, just max calls/second with little to no audio |
| 22:04.06 | codefreeze-lap | still 0 retrans |
| 22:04.18 | seanbright | codefreeze-lap: are you profiling too? |
| 22:04.21 | ctooley | codefreeze-lap, with your mtxprof profiling turned on? |
| 22:04.24 | seanbright | heh |
| 22:04.25 | ctooley | :) jinx |
| 22:04.27 | pabelanger | Ah, makes little more sense now ;) |
| 22:04.35 | codefreeze-lap | bang! at 510, it pooped out. |
| 22:04.40 | seanbright | damn |
| 22:04.43 | ctooley | piss |
| 22:04.56 | ctooley | any idea what it crapped out on? |
| 22:05.16 | ctooley | can't wait to get his dev machine back now. |
| 22:05.25 | codefreeze-lap | I feel like a kid with a crotch rocket and 150 on the speedometer, except I don't have to worry about cops, or.... death |
| 22:06.30 | codefreeze-lap | ctooley: I'll run it again, with top running, and tell you the cpu util, but I suspect it hit 100% and asterisk died. That's the good 'ol behavior we know and love |
| 22:06.47 | seanbright | codefreeze-lap: were you profiling? |
| 22:07.26 | codefreeze-lap | seanbright: nope. it's a speed test, and you don't do that with a car loaded with instrumentation |
| 22:07.37 | seanbright | right |
| 22:07.47 | ctooley | codefreeze-lap, I'll have a couple of cores to test on |
| 22:09.00 | codefreeze-lap | Actually, I took a plain current trunk, svn update'd it, added the patch from russell, and compiled with debug flags enabled, (my only concession), and away we went. |
| 22:09.17 | ctooley | russell's or the one from 12771? |
| 22:09.58 | codefreeze-lap | http://pastebin.com/m107241eb |
| 22:10.14 | ctooley | ok, so russell's |
| 22:10.40 | ctooley | Alright I have to go pour a driveway. Talk to you guys tomorrow. |
| 22:12.54 | codefreeze-lap | ctooley: you go pour the driveway, I'll play with my maserati, er asterisk... |
| 22:14.29 | codefreeze-lap | Hey, I vote we commit that patch to trunk, and everybody else? |
| 22:17.40 | seanbright | codefreeze-lap: i thought the suggestion was to use 12711 instead of the DNS lookup? |
| 22:18.19 | seanbright | 17:31 <@russellb> i think with the DNS lookup hack, it will be back to normal, but Tilghman's patch will fix it in a better way |
| 22:18.31 | codefreeze-lap | I'll look at 12711, then, and we'll measure that one, also |
| 22:19.37 | codefreeze-lap | But I'll do it tomorrow... gotta go |
| 22:19.41 | seanbright | doh |
| 22:19.42 | seanbright | ok |
| 22:45.43 | *** join/#asterisk-dev jeffg (i=QrxXcaeL@pdpc/supporter/active/jeffg) |
| 22:50.18 | jpeeler | it's not possible to get a log of all the lock activity is there? |
| 22:54.50 | snuff-home | mm u could debug channel locks.. / debug locks |
| 22:58.12 | snuff-home | most locking info will need (lookin at lock.h) debug threads to get mutex_logger |
| 22:58.39 | jpeeler | yes i have that enabled, i'm looking for a way to write all lock activity to a file |
| 22:58.57 | jpeeler | core show locks is too (time) limited |
| 22:59.06 | codefreeze-lap | jpeeler: yes, you can, see my team/murf/mtxprof branch... |
| 22:59.24 | snuff-home | murf to the rescue ;) |
| 22:59.33 | jpeeler | codefreeze-lap: is it code that you just wrote? |
| 22:59.35 | jpeeler | i'll take a look |
| 23:00.47 | codefreeze-lap | jpeeler: You could alter the macros to record stuff to a file, but it's way too slow (tried that). I was more interested in the time spent in lock grant/hold... |
| 23:01.26 | jpeeler | well ultimately i suppose that's what i am interested in as well |
| 23:01.28 | snuff-home | mm i wouldn't write to file.. rather have a buffer in memory that was flushed every so often |
| 23:01.43 | snuff-home | least that wouldn't slow it down so much |
| 23:05.33 | Deeewayne | codefreeze-lap: look at taskprocessors yet ? |
| 23:06.26 | codefreeze-lap | Deeewayne: Russell says it shouldn't be a big slowdown, it's code that was getting executed in the devicestate stuff, just separated out. |
| 23:07.10 | Deeewayne | I don't think it is either. I did some basic performance testing before merging it in and I saw a slowdown prior to adding taskprocessors to trunk |
| 23:07.43 | jameswf | so whos bright idea was it to put the crash on unconfigured zaptel with a 3 page error.... |
| 23:08.46 | Deeewayne | I was thinking of making taskprocessor statistics optional to optionally reduce some operations in the processing thread, but its not much |
| 23:11.16 | *** join/#asterisk-dev explidous (n=explidou@gateway.in-florida.net) |
| 23:13.29 | kpfleming | so what was the magic slowdown fix? had to go to a meeting, so i missed the discovery |
| 23:16.55 | Deeewayne | kpfleming: I missed it too |
| 23:19.24 | kpfleming | bummer... guess we'll find out tomorrow |
| 23:27.26 | *** part/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 23:51.11 | tzafrir_laptop | jpeeler, if you're into q921 and specs, how about http://bugs.digium.com/12861 ? |
| 23:55.25 | jpeeler | tzafrir_laptop: i wouldn't say i'm into it, maybe getting into it... |