| 00:33.38 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 00:52.56 | *** join/#asterisk-dev AlexTO (n=alex@216.215.174.155.nw.nuvox.net) |
| 00:57.02 | *** join/#asterisk-dev stevie_ramjet (n=putnopvu@c-71-228-178-34.hsd1.al.comcast.net) |
| 00:57.02 | *** mode/#asterisk-dev [+o stevie_ramjet] by ChanServ |
| 01:02.24 | *** join/#asterisk-dev Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 01:28.41 | Corydon76-dig | bbryant: ping |
| 01:29.03 | lmadsen | intercepts the ping and runs it in for a touchdown |
| 01:29.14 | Corydon76-dig | Evening, LapTop006 |
| 01:29.24 | Corydon76-dig | s/laptop006/lmaden/ |
| 01:29.34 | Corydon76-dig | s/laptop006/lmadsen/ |
| 01:29.36 | lmadsen | :D |
| 01:29.39 | lmadsen | evening! |
| 01:29.44 | Corydon76-dig | How goes? |
| 01:29.49 | lmadsen | oh it goes |
| 01:29.55 | lmadsen | watching baseball |
| 01:30.05 | Corydon76-dig | Write any interesting dialplans today? |
| 01:30.10 | lmadsen | nada :( |
| 01:30.19 | lmadsen | just some boring consulting |
| 01:31.05 | lmadsen | you? |
| 01:36.32 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 01:38.36 | Corydon76-dig | Something curious |
| 01:38.59 | Corydon76-dig | I think I've just found someone using the bug database to Astroturf |
| 01:39.37 | Corydon76-dig | Same day as they posted a rather inflammatory subject on the bugtracker, that bug appeared on the first page of search results for a certain company name |
| 01:40.04 | Corydon76-dig | On a request for further information, we got nada |
| 01:40.56 | lmadsen | Astroturf? |
| 01:41.08 | lmadsen | ~astroturf |
| 01:41.43 | Corydon76-dig | Using a campaign of fraudulent links to better the reputation of your company in a search engine |
| 01:41.56 | lmadsen | ahhhh |
| 01:42.00 | lmadsen | gotcha |
| 01:44.37 | Corydon76-dig | I just emailed Google about it |
| 01:49.35 | Corydon76-dig | lmadsen: Navtel would appear to be in your backyard |
| 02:38.16 | *** join/#asterisk-dev jeffg (i=WMrEsF8w@pdpc/supporter/active/jeffg) |
| 02:39.01 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 03:24.40 | *** join/#asterisk-dev Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 04:40.43 | *** join/#asterisk-dev techie (n=techie@m010e36d0.tmodns.net) |
| 05:05.36 | *** join/#asterisk-dev fabled (n=fabled@xdsl-83-150-94-239.nebulazone.fi) |
| 05:17.04 | JerJer | Corydon76-dig: i think the 'official' term is AstroTurfing |
| 05:18.26 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-31641.home.otenet.gr) |
| 05:18.33 | JerJer | people love to do this against my little company -- slam us bad, while giving glowing reviews of another provider |
| 05:26.25 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.140) |
| 05:42.26 | Qwell | Corydon76-dig: did you google for the user name? |
| 05:42.30 | Qwell | do it. |
| 06:04.39 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 06:07.47 | *** part/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 06:14.23 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:39.52 | *** join/#asterisk-dev techie (n=techie@m650e36d0.tmodns.net) |
| 07:10.26 | *** join/#asterisk-dev techie (n=techie@208.54.14.98) |
| 08:22.45 | oej | morning |
| 08:24.35 | *** join/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 08:50.32 | mvanbaak | mornin |
| 09:18.32 | *** join/#asterisk-dev mbranca (n=matteo@81.208.92.210) |
| 09:19.21 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 09:20.13 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.133) |
| 10:19.35 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 10:22.40 | *** part/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 10:23.37 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 10:26.31 | *** join/#asterisk-dev RoyK (n=roy@ip-158-24-149-91.dialup.ice.no) |
| 10:39.24 | *** join/#asterisk-dev jeffg (i=r7xoWZlE@pdpc/supporter/active/jeffg) |
| 11:13.03 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 11:13.25 | *** part/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 11:30.09 | *** join/#asterisk-dev jeffg (i=IbepRsBY@pdpc/supporter/active/jeffg) |
| 11:42.09 | *** join/#asterisk-dev jeffg (i=7HzLsn3m@pdpc/supporter/active/jeffg) |
| 11:49.26 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 11:49.26 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 11:51.48 | file | seanbright: get to work, slacker! |
| 11:55.48 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:59.31 | seanbright | heh |
| 12:11.17 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 12:13.41 | agx | I was going to understand a little bit more about chan_misdn (because i want to fix some fax problem) but i'm missing some vital information. Under Zap i've understood that there is an IRQ 1000 times each seconds that reads 8 bytes from the card to obtain 8000 samples each seconds. How instead it works mISDN? It looks like reading 128 bytes each time. Any documentation about it? |
| 12:17.13 | steliosk | agx : It actually ignores 7 out of 8 interrupts |
| 12:18.38 | agx | steliosk, mISDN do you mean? |
| 12:19.07 | steliosk | yes, this how most of the HFC related drivers work |
| 12:21.28 | tzafrir_laptop | can't you just tell the chip to send less interrupts? |
| 12:22.00 | steliosk | tzafrir_laptop : there is no other source of timing interrupts |
| 12:23.58 | steliosk | tzafrir_laptop : btw any plans for Astricon ? |
| 12:28.18 | steliosk | agx : BTW mISDN seems to add some delay also, so this might a be reason for any fax issues. At least the EC seem to suffer a bit with this |
| 12:32.19 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:33.47 | tzafrir_laptop | Here's an interesting thing to do: |
| 12:34.17 | tzafrir_laptop | 1. build asterisk as amd64 |
| 12:34.37 | tzafrir_laptop | 2. in the same build directory run 'make clean' as i386 |
| 12:34.51 | tzafrir_laptop | 3. again, in the same directory, run 'make' as i386 |
| 12:35.23 | tzafrir_laptop | You'll notice a few things in sub directories of build directories (e.g: main/editline) were not properly cleaned |
| 12:37.57 | agx | steliosk, yes i've read about this "delay" effect on oslec+misdn webpage; is the internal jitter buffer that does the delay? |
| 12:38.05 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 12:39.34 | steliosk | agx : Not sure. haven't looked at the mISDN code for sometime now. Using bristuff here |
| 12:43.21 | steliosk | Crofton : Ping me if you need anything with regard to the ml403. |
| 12:43.56 | steliosk | Crofton : if you see no reply, better send email. spend a lot of time away from the pc these days |
| 12:44.17 | steliosk | sorry guys.. wrong window |
| 12:57.24 | agx | steliosk, i see but Bristuff seems to have some compatibility issue when operating in PMTP (i see that the L1 going down makes some problem) |
| 12:58.30 | tzafrir_laptop | agx, I suspect those are driver issues |
| 12:58.42 | tzafrir_laptop | I simply don't see those |
| 13:00.00 | *** part/#asterisk-dev gmaruzz (n=gmaruzz@213-140-6-122.ip.fastwebnet.it) |
| 13:03.25 | mvanbaak | it's a qozap issue if your telco enables powersaving on the BRI lines |
| 13:03.54 | mvanbaak | that is what caused in our setups |
| 13:13.51 | *** join/#asterisk-dev juanjoc (n=juanjoc@host223.190-225-200.telecom.net.ar) |
| 13:20.50 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 13:30.23 | steliosk | agx : yes seen that also. cpe works without the same issues though. |
| 13:41.23 | agx | steliosk, i think that issue its not hard to fix but the bristtuff is still an external patch? one reason i choose mISDN is because of the Digium 4 BRI card with EC onboard and because its part of the asterisk source tree |
| 13:56.06 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 13:57.31 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.140.193) |
| 14:02.11 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 14:02.11 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:03.32 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 14:13.43 | bbryant | Corydon76-dig: pong |
| 14:18.52 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 14:23.13 | codefreeze-lap | kpfleming: I notice in dahdi-linux, that the file mentioned in UPGRADE, system.conf.sample, is not in svn. Is this accident/design/soon to come? |
| 14:25.08 | kpfleming | well, since the release has not been made yet, you can assume it is not accident or design |
| 14:25.21 | *** join/#asterisk-dev ctooley (n=ctooley@rrcs-71-42-115-245.sw.biz.rr.com) |
| 14:25.21 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 14:25.28 | kpfleming | most of that stuff should be taken care of today, as i plan on making 2.0.0-rc1 tarballs today |
| 14:26.44 | kpfleming | also, that file will live in dahdi-tools, not dahdi-linux, but the UPGRADE.txt file will be common to both |
| 14:27.11 | codefreeze-lap | kpfleming: I'm playing with it; will it create the /dev/dahdi stuff? |
| 14:27.18 | ctooley | Can anyone tell me what part of the menuselect-tree that gets generated in murf's mtxprof branch causes MTX_PROFILE to either get included or not? I'm still trying to figure out what I'm missing to cause that not to be available. |
| 14:27.24 | kpfleming | yes, it should already do that, since we've been using it |
| 14:27.53 | codefreeze-lap | kpfleming: fascinating |
| 14:29.33 | snuff-home | mmm.. my unionisation of something within translate.h seems to have worked.. but that's 1 phone and playback/voicemail |
| 14:29.42 | steliosk | agx : yeah, its external although its a series of patches now, instead of a single mega-patch |
| 14:29.49 | codefreeze-lap | ctooley: lessee.... âbuild_tools/cflags-devmode.xml is a start |
| 14:30.32 | ctooley | codefreeze-lap, obviously I'm missing something that it's looking for, as I never get it to add that to the tree |
| 14:31.28 | codefreeze-lap | ctooley: I'm doing a grep -r in my source; another is include/asterisk/buildopts.h... I think that's generated |
| 14:32.05 | codefreeze-lap | ctooley: and include/asterisk.h -- I'd bet that this is a default decl |
| 14:32.08 | steliosk | Does anyone know if setting the kernel hertz to anything but 1000Hz could effect ztdummy ? I have an embedded system under test that has 5-10 iax calls trunked to another x86 based asterisk (all are latest 1.2) |
| 14:32.33 | steliosk | and i am getting rtc missed irq |
| 14:32.39 | tzafrir_laptop | steliosk, what is the clock source of ztdummy? |
| 14:32.49 | tzafrir_laptop | rtc does not use hz |
| 14:32.51 | steliosk | rtc |
| 14:32.56 | steliosk | i know |
| 14:33.06 | ctooley | codefreeze-lap, ok, I'll check those places to start |
| 14:33.34 | steliosk | but i wonder if that could cause ztdummy to have problems |
| 14:34.00 | steliosk | having missed rtc irq registed in dmesg is a first.... |
| 14:34.07 | steliosk | at least for me |
| 14:34.53 | codefreeze-lap | ctooley: and then, in menuselect, there's test/menuselect-tree, and example_menuselect-tree; and at the top level, menuselect-tree, and menuselect.makeopts |
| 14:35.20 | seanbright | i added test/menuselect-tree so you could run menuselect standalone |
| 14:35.21 | agx | steliosk, cat /proc/zaptel/X about ztdummy show HRtimer as clock source? |
| 14:35.31 | seanbright | when i was working on nmenuselect |
| 14:35.33 | mvanbaak | ctooley: you have to run configure with --enable-dev-mode |
| 14:36.07 | codefreeze-lap | ctooley: one thing to watch out for: if you accidentally mix up ownership (root vs user) on any of the generated files, you could make it so they can't be modified... just a thought, maybe... |
| 14:36.47 | steliosk | agx : nop. its rtc |
| 14:38.27 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 14:38.27 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:38.54 | steliosk | i got a lot of messages in the logs like rtc : Lost xxx interrupts with xxx ranging from 150+ to 250+ |
| 14:39.13 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583193.dsl.bell.ca) |
| 14:41.58 | agx | steliosk, check this i never had that problem with asterisk but had with other software http://www.callweaver.org/ticket/207 |
| 14:42.18 | agx | steliosk, i will suggest you backup of your data if its the disk really :-P |
| 14:43.34 | steliosk | agx : no disks. just flash |
| 14:44.19 | snuff-home | mmm anyone using trunk and getting the 'res_timing_pthread only supports timers at a max of rate of 100/sec' ? |
| 14:44.50 | kpfleming | that means something is requesting a timer with a shorter period... need to find out what it is |
| 14:45.35 | codefreeze-lap | kpfleming: also, just curious; I'm noting that at them moment, when I load the wctdm24xxp module, it's pulling in zaptel.ko; is this by design? |
| 14:45.53 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 14:45.57 | kpfleming | yes, if your wctdm24xxp module came from zaptel |
| 14:46.04 | kpfleming | you can't easily have both zaptel and dahdi installed at the same time |
| 14:46.56 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 14:47.14 | kpfleming | snuff-home: are you using IAX2 trunking? |
| 14:47.47 | snuff-home | nope.. not even using one at |
| 14:47.49 | snuff-home | *atm |
| 14:47.54 | kpfleming | ok |
| 14:48.43 | kpfleming | snuff-home: can you add a debugging statement for me? is this meesage reproducible for you? |
| 14:48.48 | snuff-home | mm but its wierd it shows that warning since only iax uses it.. and only place its ever possibily changed is in iax.conf |
| 14:48.54 | snuff-home | mm sure np |
| 14:48.58 | kpfleming | no, it can be used from other places too |
| 14:49.25 | snuff-home | well the error comes from set_rate from what i remember lookin at just before |
| 14:49.33 | kpfleming | in main/file.c, in the function ast_readaudio_callback, add an ast_log call to show what 'rate' is set to before calling ast_settimeout |
| 14:49.41 | kpfleming | yes, and that can be called from ast_settimeout in main/channel.c |
| 14:49.46 | kpfleming | that's the most likely culprit |
| 14:49.57 | snuff-home | k adding for u now.. |
| 14:50.00 | kpfleming | thanks |
| 14:52.13 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 14:52.13 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 15:04.13 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:04.13 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:05.43 | snuff-home | i added 1 line for that.. but never see it execute.. aka should i also add another one for when it calls settimeout with 'null' just to see if its dropping into there |
| 15:05.53 | kpfleming | no, that would be fine |
| 15:06.03 | kpfleming | so that's not the source of the calls to set_timer_rate then |
| 15:06.16 | kpfleming | how about modifying the log message in res_timing_pthread to also include the rate that was requested |
| 15:06.21 | kpfleming | that might give us some more clues |
| 15:06.30 | snuff-home | mm np |
| 15:07.16 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:07.16 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 15:07.37 | codefreeze-lap | kpfleming: very interesting! I've been doing 'modprobe wctdm24xxp', on the command line, and getting the old zaptel stuff. They aren't removed by a dahdi install, which is probably good. A check of modules.dep doesn't turn up the dahdi stuff. Running depmod doesn't add the dahdi stuff. |
| 15:07.41 | bbryant | happy birthday, russellb |
| 15:08.00 | kpfleming | no, the dahdi install process will eventually remove any zaptel modules that are installed |
| 15:08.03 | kpfleming | it just hasn't happened yet |
| 15:08.12 | kpfleming | bbryant: +1 from me |
| 15:08.21 | russellb | bbryant: thanks :) |
| 15:08.36 | mvanbaak | hey russellb. Happy birthday |
| 15:08.44 | russellb | waves to the room |
| 15:08.45 | kpfleming | russellb is now... 42! |
| 15:08.51 | russellb | yes! |
| 15:08.57 | file | russellb: O.O |
| 15:09.09 | codefreeze-lap | russellb: likewise.... oh, the days when birthdays weren't celebrated with black balloons! |
| 15:09.23 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 15:10.30 | mvanbaak | file: you should add dahdi to buildbot |
| 15:11.53 | snuff-home | mm kpfleming seems i must not have done something right last time maybe restarted asterisk.. ;) |
| 15:12.03 | kpfleming | hmm |
| 15:12.10 | snuff-home | i get calls with '130' and '364' |
| 15:12.15 | snuff-home | for a 'rate' |
| 15:12.49 | snuff-home | note the 364 is waiting user input on voicemail() |
| 15:13.37 | kpfleming | wow |
| 15:13.49 | russellb | talking about timers? |
| 15:13.50 | kpfleming | that is a very odd number to see there |
| 15:13.56 | russellb | or something else .. |
| 15:13.59 | kpfleming | yes, the warning in res_timing_pthread |
| 15:14.03 | russellb | ah, yes. |
| 15:14.09 | kpfleming | the 'max rate' warning, he's getting calls to set the rate to those numbers |
| 15:14.09 | russellb | i know what causes it. putnopvut noticed it last week |
| 15:14.25 | russellb | it happens on the very last frame when playing back prompts |
| 15:14.50 | russellb | it knows that the last frame is less than a normal frame, so it reconfigures the timer to tick as soon as the playback of that frame is done |
| 15:14.52 | russellb | in theory |
| 15:15.03 | kpfleming | ahh |
| 15:15.12 | russellb | it's a quick change to make it wait the full 20 ms anyway |
| 15:15.26 | russellb | but it could potentially introduce a small bit of delay right then ... |
| 15:15.30 | kpfleming | right |
| 15:15.46 | kpfleming | that could be bad i suppose when prompts are being played back-to-back |
| 15:15.53 | kpfleming | but 10ms is not very noticeable |
| 15:17.12 | russellb | yeah ... |
| 15:17.29 | russellb | we could a timer API call to check max rate |
| 15:17.35 | russellb | and use that there ... |
| 15:17.45 | russellb | so we can at least go as fast as we can if it's not as fast as we'd like |
| 15:18.29 | kpfleming | yes |
| 15:18.31 | kpfleming | that would be better |
| 15:18.41 | russellb | it's not perfect, but it'll do for now i suppose |
| 15:20.04 | russellb | i'll do that now |
| 15:20.54 | ctooley | codefreeze-lap, Yay! I finally have MTX_PROFILE |
| 15:22.45 | ctooley | --enable-dev-mode seems to have done it, but I remember doing that previously. However I might not have run "make clean" in the menuselect directory after I had configured _without_ dev mode, and therefore things didn't get redone. |
| 15:24.07 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 15:24.07 | wwalker | It could have been that you hadn't yet sacrificed two chickens and a baby goat. |
| 15:24.07 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 15:24.26 | wwalker | btw, you're cleaning up the goat guts. |
| 15:24.40 | file | waves to seanbright |
| 15:26.09 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 15:26.31 | *** part/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 15:27.25 | seanbright | waves |
| 15:27.36 | seanbright | file: shouldn't you be on a plane somewhere? |
| 15:27.53 | *** join/#asterisk-dev Cresl1n (n=matt@m7b5f36d0.tmodns.net) |
| 15:27.53 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 15:27.54 | file | in an hour, yes |
| 15:28.15 | Cresl1n | file! |
| 15:28.17 | codefreeze-lap | ctooley: good! sorry for all the hassle. I always use --enable-dev-mode on configure; honestly would not have guessed that you need to use it to compile with MTX_PROFILE. |
| 15:28.28 | file | Cresl1n! |
| 15:28.53 | kpfleming | yeah, you should always use --enable-dev-mode if you are doing development work on the code |
| 15:28.53 | seanbright | waves to Cresl1n |
| 15:29.46 | russellb | swizzle swozzles |
| 15:29.49 | oej | Afternoon |
| 15:33.18 | russellb | gah, asterisk takes a while to build if you haven't updated in a few days :) |
| 15:33.32 | Cresl1n | seanbright: !!!!! |
| 15:33.36 | Cresl1n | long time no see |
| 15:33.40 | kpfleming | russellb: was it your plan to include the dahdi changes in 1.4.21? |
| 15:34.04 | kpfleming | because the first two rcs didn't have them |
| 15:34.26 | kpfleming | and i'd like to get an rc out of 1.4 and 1.6 along with dahdi 2.0.0-rc1 today if i can get it in shape for release |
| 15:35.16 | codefreeze-lap | kpfleming: another nit, maybe you've already got it... ran dahdi_cfg --help, got the help message, it says -c <filename> -- Use <filename> instead of /etc/dahdi.conf; the UPGRADE says /etc/dahdi/system.conf... |
| 15:35.29 | kpfleming | then fix it :-) |
| 15:35.59 | codefreeze-lap | kpfleming: OK! 8-) |
| 15:36.01 | kpfleming | yes, the new file will be /etc/dahdi/system.conf |
| 15:36.45 | kpfleming | i would also appreciate any other comments on problems you've had that may need to be noted in UPGRADE.txt, altough it might be best to wait for those until i make a release candidate that is 'supposedly' done |
| 15:36.46 | *** join/#asterisk-dev _Krieger_ (n=krieger@193.39.118.158) |
| 15:37.05 | russellb | timing stuff committed but untested |
| 15:37.07 | russellb | time to board ... |
| 15:37.48 | russellb | snuff-home: ^^^^ |
| 15:37.50 | russellb | try that |
| 15:37.51 | russellb | g2g |
| 15:38.16 | tzafrir_laptop | are there any dahdi_system.conf settings that prevent running dahdi_cfg twice in a row? |
| 15:38.26 | codefreeze-lap | kpfleming: duh... already done. forgot to reinstall. Will wait for your updates before I do any more nit picking. |
| 15:38.46 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 15:38.58 | kpfleming | tzafrir_home: shouldn't be any, just like ztcfg |
| 15:39.50 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 15:47.36 | *** join/#asterisk-dev Cresl1n (n=matt@m145e36d0.tmodns.net) |
| 15:47.36 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 16:09.12 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.142) |
| 16:34.07 | *** join/#asterisk-dev macli (n=macli@nmc.brc.ubc.ca) |
| 16:44.02 | Rem| | oej: for bug 12215, why is it dangerous to mark the channel up at that point? |
| 16:44.31 | oej | You're removing the AST_ANSWER mesage to the other channel |
| 16:44.54 | oej | Feels like the bridge fails for some reason |
| 16:44.59 | oej | gotta go |
| 16:45.02 | oej | sorry |
| 16:49.18 | *** join/#asterisk-dev ajohnson (n=ajohnson@63.147.46.186) |
| 16:50.21 | ajohnson | I am experiencing a regular crash related to a memory leak in Asterisk 1.4.21. Do I need to compile Asterisk with the MALLOC_DEBUG compiler option set for the core dumps to be usable? |
| 16:50.29 | ajohnson | I'm already compiling with optimizations turned off |
| 16:51.14 | ajohnson | The core dumps are 3.2gb |
| 16:52.01 | Corydon76-dig | ajohnson: have you filed a bug yet? |
| 16:52.44 | ajohnson | Corydon76-dig: I haven't, though I've searched through mantis and I do not believe there is a bug report associated with this problem |
| 16:52.56 | ajohnson | I just wanted to provide everything necessary when I make the report |
| 16:53.01 | kpfleming | ajohnson: r123271 may be relevant |
| 16:53.26 | ajohnson | ok |
| 16:54.05 | kpfleming | that's the only memleak related fix that has gone in since 1.4.21 |
| 16:54.20 | *** join/#asterisk-dev oej_ (n=olle@ns.webway.se) |
| 16:54.28 | kpfleming | it was a simple patch, should be easy to apply without having to upgrade to SVN branch 1.4 that contains a bunch of other stuff |
| 16:55.44 | ajohnson | Ok. I appreciate it |
| 16:56.02 | ajohnson | If that doesn't fix the issue, should I recompile with malloc_debug on? |
| 16:56.08 | kpfleming | yep |
| 16:56.10 | ajohnson | ok |
| 16:56.13 | kpfleming | and now i am off to lunch |
| 16:56.15 | ajohnson | ciao |
| 16:56.42 | ctooley | codefreeze-lap, what compiler flags should I set to for this compile before this test run. |
| 16:57.38 | ctooley | oej_, I'm getting some "official" results to put up on the bug, but I noticed the issue because 30 calls per second started consuming 300% of cpu for trunk, where as previously 250 calls per second was consuming around 20% of cpu |
| 17:04.12 | Corydon76-dig | 300%? |
| 17:05.06 | ctooley | yes, 3 full cpus |
| 17:05.45 | ctooley | The boxes we're using have 8 cores, it's hardly irregular to see cpu utilization of 4-500% for a process. |
| 17:07.15 | ctooley | but, either way, 10 calls per core isn't exactly stellar performance. :( |
| 17:10.03 | Corydon76-dig | You mean, in 1.6, SIP may actually match performance with IAX? |
| 17:14.26 | ctooley | You mean it may perform badly? Because in our build of 1.4.19.1 we have very high SIP performance. |
| 17:14.43 | Corydon76-dig | was joking |
| 17:14.52 | ctooley | I figured |
| 17:15.21 | Corydon76-dig | IAX performance is on its way to getting better, though |
| 17:15.49 | ctooley | SIP performance was too |
| 17:17.16 | ctooley | Oh, and the time to get in and back out of Asterisk (round trip time) for a route request has skyrocketed with trunk. All asterisk does is take the sip INVITE, pass a header to ExternalIVR(), wait for it to exit, and then use a channel variable to build a 300 Multiple choices response and send it. |
| 17:18.43 | *** join/#asterisk-dev jeffg (i=DA7xo928@pdpc/supporter/active/jeffg) |
| 17:19.05 | ctooley | The ExternalIVR() round trip time hasn't changed, but the time from INVITE received to ExternalIVR() called, and the time from ExternalIVR() exit to 300 message sent, have both gone up by at least 10 times what our 1.4.19.1 build does. |
| 17:19.25 | ctooley | Now, I'm just trying to recreate the environment where I was able to show that. |
| 17:22.29 | *** join/#asterisk-dev eferro (n=eferro@212.230.49.164) |
| 17:25.30 | eferro | We have a little patch for use NCSs eMTAs.... we are using this code in a 3000/4000 lines distributed over 50/70 Docsis/EuroDocsis networks... |
| 17:25.41 | eferro | We want to release back the code.... |
| 17:26.18 | Corydon76-dig | Sign a license agreement on http://bugs.digium.com and submit the patch there. |
| 17:26.50 | eferro | We already sign... and already submmit some minor patches for mgcp.... |
| 17:27.54 | Corydon76-dig | Well, that's the place to file patches |
| 17:28.02 | eferro | but we only have this code in production customers at asterisk version from 1.4.4 up to 1.4.17.... but we don't have the code update for 1.6 --- |
| 17:28.16 | eferro | This can be a problem? |
| 17:28.21 | Corydon76-dig | It would have to be coded for trunk |
| 17:28.39 | eferro | Is better to migrate to 1.6 first? |
| 17:28.53 | Corydon76-dig | but if the code in interesting enough, you may be able to find someone to update it after you post the patch |
| 17:29.18 | Corydon76-dig | Trunk is the codebase from which 1.6 releases will be branched |
| 17:29.35 | eferro | I suppose that with some help I can migrate this code.... but I can't test in real customers... only at our labs |
| 17:29.39 | Corydon76-dig | So porting to trunk won't make it to 1.6.0.x, but it may make 1.6.1.x |
| 17:31.00 | eferro | Ok... understand... |
| 17:32.02 | eferro | Another question.... |
| 17:33.00 | eferro | The NCS patch is a patch for mgcp_channel..... is there any official mgcp mantainer? |
| 17:33.29 | Corydon76-dig | There is not, no |
| 17:34.07 | Corydon76-dig | We do our best not to have people 'owning' code, though it sometimes happens anyway |
| 17:34.20 | eferro | ok.... |
| 17:34.38 | codefreeze-lap | ctooley: well, maybe the time I spent on studying the INVITE slowdown wasn't completely wasted then... |
| 17:36.53 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 17:39.08 | codefreeze-lap | ctooley: Hmmm.... I timed the length of time that ast_pbx_start (from the chan_sip INVITE) took in trunk; I came up with 18,000 micoseconds avg over about 5 calls. It might really, really, be interesting to see it it is less than that in 1.4. I really don't suspect it would be..... |
| 17:40.17 | eferro | We have two developer user for the Digium Issue Tracking system.... Can we have some kind of "bussines" user account to submit the patches? |
| 17:40.51 | Corydon76-dig | There is no such type of account |
| 17:44.11 | Corydon76-dig | Submit a license for each account |
| 17:57.41 | seanbright | hmmm |
| 17:57.46 | seanbright | 1.4.21 |
| 17:57.59 | seanbright | 1 = major version, 4 = minor version, 21 = ? |
| 17:58.01 | seanbright | revision? |
| 17:58.02 | seanbright | build? |
| 18:03.33 | mvanbaak | looks like oej_ is back ;) |
| 18:04.00 | mvanbaak | my .lists.asterisk.bugs is full of his comments ;) |
| 18:06.22 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 18:07.20 | eferro | Corydon76-dig, thanks for the info... the next week I upload the code to the BTS.... |
| 18:10.42 | kpfleming | seanbright: .21 = point release |
| 18:13.03 | outtolunc | me too |
| 18:13.08 | outtolunc | ww |
| 18:15.18 | seanbright | kpfleming: danke |
| 18:16.58 | *** part/#asterisk-dev eferro (n=eferro@212.230.49.164) |
| 18:19.26 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 18:19.27 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 18:20.10 | mvanbaak | wb birthday man |
| 18:23.54 | russellb | thanks :) |
| 18:24.01 | russellb | hanging around in another airport ... |
| 18:24.13 | mvanbaak | ah |
| 18:24.15 | Corydon76-dig | woot, what a way to spend it |
| 18:24.18 | mvanbaak | you guys are lucky there |
| 18:24.20 | russellb | yeah. |
| 18:24.24 | russellb | free wifi ftw? |
| 18:24.24 | mvanbaak | wireless on airports |
| 18:24.27 | mvanbaak | yeah |
| 18:24.35 | Corydon76-dig | russellb: so you turned, what, 35? |
| 18:24.36 | mvanbaak | wifi access in .nl is very rare |
| 18:24.38 | Corydon76-dig | ducks |
| 18:26.17 | russellb | 24 :) |
| 18:26.28 | Qwell | russellb: youngin' |
| 18:26.33 | russellb | i feel old |
| 18:26.45 | Qwell | you aren't even 1/4 century old! |
| 18:27.00 | mvanbaak | 24 ???? |
| 18:27.13 | russellb | is that surprising? |
| 18:27.13 | Corydon76-dig | So you've only lost 24 of your marbles? |
| 18:27.26 | mvanbaak | russellb: yeah. I thought you were a bit older |
| 18:27.26 | Corydon76-dig | Wait until you lose like 72... |
| 18:27.32 | russellb | ah. |
| 18:27.44 | mvanbaak | somewhere between 30 and 35 |
| 18:27.48 | russellb | oh, heh |
| 18:28.05 | russellb | old enough to drink, but still not old enough to rent a car |
| 18:28.08 | Corydon76-dig | mvanbaak: are you older than me? |
| 18:28.22 | mvanbaak | Corydon76-dig: March 16th 1979 |
| 18:28.37 | Corydon76-dig | Oh, you're like way younger |
| 18:29.03 | outtolunc | turns to dust |
| 18:29.06 | Corydon76-dig | Whippersnapper! |
| 18:29.22 | russellb | 1984 ftw! |
| 18:29.31 | Corydon76-dig | outtolunc: late 30s? |
| 18:29.39 | outtolunc | haha i wish mid 40's |
| 18:30.24 | Corydon76-dig | celebrated his 22nd birthday this year (again) |
| 18:30.35 | mvanbaak | lol Corydon76-dig |
| 18:30.37 | Qwell | for the 10th time? |
| 18:31.24 | Corydon76-dig | Qwell: nah, I'm switching around, like a Quentin Tarantino film |
| 18:31.46 | Corydon76-dig | I was celebrating my 21st birthday when I turned 19, for example |
| 18:32.59 | Corydon76-dig | I suspect there's a lot of kids celebrating their 21st birthday at like 15 or so... |
| 18:33.17 | mvanbaak | what's so special about 21 ? |
| 18:33.26 | mvanbaak | I mean, 21 is only half the truth |
| 18:33.31 | Corydon76-dig | Legal drinking age in the US |
| 18:33.33 | Qwell | mvanbaak: 21 is legal drinking age |
| 18:33.38 | mvanbaak | aaaaaaaaah |
| 18:33.43 | mvanbaak | lives in .nl |
| 18:34.04 | Corydon76-dig | mvanbaak: legal drinking age is like 14 there, ain't? |
| 18:34.07 | mvanbaak | 16 |
| 18:34.10 | Qwell | 14 months |
| 18:34.17 | mvanbaak | 16 hours |
| 18:34.42 | Corydon76-dig | mvanbaak: oh, right 14 is age of consent... |
| 18:34.46 | mvanbaak | it's funny |
| 18:34.57 | mvanbaak | alcohol at 16, and softdrugs at 18 |
| 18:35.02 | mvanbaak | alcohol is harddrugs |
| 18:35.30 | mvanbaak | softdrugs is not addictive |
| 18:35.39 | Corydon76-dig | Personally, I think people should learn how to drink BEFORE they learn to drive... because a drunk guy on a bicycle doesn't do harm to anybody but himself... |
| 18:35.54 | mvanbaak | Corydon76-dig: erm, wanna bet ? |
| 18:36.20 | mvanbaak | we have a lot of accidents here with drunk cyclers |
| 18:36.20 | Corydon76-dig | mvanbaak: Well, okay, a little harm. But a drunk guy on a bicycle isn't going to kill anybody |
| 18:36.51 | mvanbaak | nope |
| 18:36.52 | Corydon76-dig | If he kills himself, it's because he fell off the bike into the drink |
| 18:37.12 | mvanbaak | that's why you loose your license directly here in .nl when you are caught driving with too much alcohol |
| 18:37.50 | mvanbaak | they activated that law like 5 years ago |
| 18:38.14 | mvanbaak | anybode under 25 with more then 0.2 promille alcohol looses their drivers license directly |
| 18:38.41 | mvanbaak | I like that low |
| 18:38.46 | mvanbaak | s/low/law/ |
| 18:38.57 | Corydon76-dig | mvanbaak: drunk in TN is anything over .08 |
| 18:39.34 | Corydon76-dig | Used to be you could be up to .10 on your first offense |
| 18:40.19 | Corydon76-dig | but yeah, 0.20 is soused |
| 18:41.01 | Corydon76-dig | I know a guy who, an hour after he stopped drinking, tested at something like 0.40 |
| 18:41.36 | mvanbaak | I drink one beer tops when I have to drive |
| 18:41.40 | mvanbaak | one or none |
| 18:41.43 | Corydon76-dig | Surprising that he didn't die on that binge |
| 18:41.46 | mvanbaak | if I drink more, I call a cab |
| 18:44.19 | mvanbaak | or my wife ;) |
| 18:44.33 | mvanbaak | sometimes on friday we grab a couple of drinks with some coworkers |
| 18:44.39 | mvanbaak | and my wife travels by train |
| 18:44.48 | mvanbaak | she picks me up then |
| 18:45.21 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 18:46.03 | kpfleming | Corydon76-dig: um... i don't think that i agree with the patches you committed for 12932 |
| 18:46.06 | *** join/#asterisk-dev anthm (n=anthm@208.54.7.188) |
| 18:46.48 | kpfleming | if the code puts a char * pointer into the .c element of the union, it will only be aligned to the natural alignment of a 'char' |
| 18:47.06 | kpfleming | reading it back out of the int16 element will *not* cause it to be in alignment for accessing int16 elements |
| 18:47.38 | Corydon76-dig | The compiler won't align the entire union for compatiblity with all of the elements? |
| 18:48.08 | kpfleming | the issue is not the alignment of the pointers, it's the alignment of the data they point to |
| 18:48.33 | Corydon76-dig | Ah, hrm |
| 18:48.59 | kpfleming | presumably (all modern platforms) align all types of pointers the same way, so the alignment of a 'char *' and a 'int16_t *' are the same |
| 18:49.13 | kpfleming | but the alignment of a 'char' and an 'int16_t' are not |
| 18:49.51 | kpfleming | so i believe the simple fix is in translate.c, when pvt->outbuf is initialized, that the value put in there must be a value that can be used as a starting point for either a char or an int16 |
| 18:50.03 | Corydon76-dig | Since snuffy works on Solaris, I naturally assumed that this fixed a specific Solaris issue |
| 18:50.05 | kpfleming | we do this in other places already in the code... let me find one |
| 18:50.14 | kpfleming | it's not a Solaris issue, it's a Sparc issue |
| 18:50.23 | kpfleming | since Sparc CPUs refuse to do unaligned accesses |
| 18:50.30 | Corydon76-dig | right |
| 18:50.31 | kpfleming | other CPUs do them, but they are slow |
| 18:50.56 | kpfleming | does he actually have a real result showing that this patch solved a problem? i'd find that hard to believe |
| 18:51.07 | Corydon76-dig | Not in this issue, no |
| 18:51.20 | kpfleming | ok, hang on a sec |
| 18:52.33 | Corydon76-dig | I have reopened the issue, with a query to snuffy |
| 18:53.09 | kpfleming | cripes... there is code in there already to attempt to fix this, but it's wrong |
| 18:54.32 | kpfleming | please assign the issue to me and i'll work on it tomorrow while i'm flying to San Diego |
| 18:54.48 | kpfleming | and this fix will need to go into all current branches |
| 18:55.19 | kpfleming | the other concern that I had is that this is an API change, so it either needs to go into both trunk and 1.6.0, or neither, because we haven't decided on how to handle API changes post-1.6.0 yet |
| 18:56.13 | kpfleming | do you need me to comment on the issue so snuffy knows what is going on? |
| 18:56.46 | Corydon76-dig | Well, there's a query to him on it, so hopefully we'll get a response back today |
| 18:56.52 | kpfleming | ok |
| 18:57.32 | Corydon76-dig | btw, are you still working on that iax2 issue from Monday? |
| 18:58.27 | Corydon76-dig | Or was my inability to reproduce the problem a showstopper? |
| 19:09.43 | kpfleming | well, it's not a showstopper, as i could still work on it, however we wouldn't be able to characterize the improvement as well, and i'm not sure the urgency warrants stopping the other projects i'm working on to do it |
| 19:11.18 | Corydon76-dig | Okay |
| 19:13.00 | russellb | is there much to do? |
| 19:13.05 | russellb | basically, remove the code and see if it breaks ... |
| 19:13.17 | russellb | it _will_ improve performance |
| 19:13.29 | russellb | assuming the hash table is populated at all times that it is supposed to |
| 19:13.39 | russellb | , it should be ok |
| 19:13.41 | Corydon76-dig | russellb: The section of code you're talking about, it breaks |
| 19:13.48 | russellb | when you remove it? |
| 19:13.52 | Corydon76-dig | qualify=yes breaks, specifically |
| 19:14.09 | Corydon76-dig | russellb: I was trying it on Monday, to see what effect it had |
| 19:14.21 | russellb | ah, ok, i seemed to remember that it broke something ... |
| 19:14.27 | Corydon76-dig | Any host on qualify=yes will show up unreachable immediately |
| 19:14.31 | russellb | nods |
| 19:14.50 | russellb | shouldn't be that hard to fix ... but just like kpfleming, time is short ... |
| 19:14.53 | Corydon76-dig | I was talking with Kevin about another change... |
| 19:15.27 | Corydon76-dig | make an iaxs structure in threadstorage, and wait for the last possible moment to find an empty slot in the iaxs array |
| 19:15.44 | kpfleming | yeah, there are other bits too, but that's the important part |
| 19:16.37 | Corydon76-dig | You know, I just thought of another change we could make... |
| 19:16.45 | russellb | um |
| 19:17.06 | Corydon76-dig | When searching for an empty slot, don't lock each slot, trylock it instead and skip over anything we can't lock |
| 19:17.24 | russellb | or just not do the search at all. |
| 19:17.29 | kpfleming | Corydon76-dig: when talking about chan_iax2, there are *tons* of changes we could make :_) |
| 19:17.30 | russellb | i mean, linear traversal |
| 19:17.43 | kpfleming | right... we need to find the last needs for linear traversal and get rid of them |
| 19:17.46 | russellb | that loop is stupid, there is no tweaking it, it needs to be gone |
| 19:18.35 | Corydon76-dig | What algorithm would you use to deterministically find an available callno? |
| 19:18.56 | Corydon76-dig | Jumbled queue? |
| 19:19.53 | Corydon76-dig | That might be the best way... |
| 19:20.13 | kpfleming | waits for the CS majors to start talking about algorithms |
| 19:20.27 | Qwell | LIFO |
| 19:20.40 | Corydon76-dig | I think jumbled queue would be nice... |
| 19:20.46 | russellb | why not just maintain a randomized queue of available call numbers. pop one off when you need one. |
| 19:20.46 | kpfleming | keep in mind that we need a method that is not predictable, or have very little predictability |
| 19:21.03 | Corydon76-dig | russellb: that's exactly what I was suggesting |
| 19:21.13 | russellb | ok, I had never heard of "jumbled queue" |
| 19:21.46 | russellb | i wonder if you randomize the order when you initialize the queue, and just put them at the tail when you're done, and grab new ones off of the head |
| 19:21.48 | russellb | if that's good enough ... |
| 19:21.59 | Corydon76-dig | Just need to ensure that we recycle all callnos to the end of the queue when we're done with them |
| 19:22.00 | kpfleming | and if you want to get really fancy, you keep thread-local lists to keep locking down |
| 19:22.23 | putnopvut | thread-local lists? But are the callnos global in scope? |
| 19:22.26 | Corydon76-dig | The recycling is going to be the biggest job |
| 19:22.31 | kpfleming | yes they are |
| 19:22.50 | kpfleming | so each worker thread (long-lived, not dynamic) would have a list of available callnos from the global pool |
| 19:23.08 | russellb | and what would the dynamic threads do? |
| 19:23.17 | *** join/#asterisk-dev Cresl1n (n=matt@65.14.229.26) |
| 19:23.17 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 19:23.20 | kpfleming | guess? :-) |
| 19:23.25 | russellb | heh .. |
| 19:23.28 | Cresl1n | 42 |
| 19:24.00 | russellb | this is probably a bit in depth to decide on IRC, anyway |
| 19:24.31 | Corydon76-dig | as long as we aren't working on competing implementations... |
| 19:24.45 | kpfleming | do it madlib style |
| 19:24.57 | Qwell | first word: Taco. |
| 19:25.13 | kpfleming | second word: Tuberculosis |
| 19:25.43 | putnopvut | third word: Together |
| 19:26.11 | russellb | fourth word: avacado |
| 19:26.25 | Corydon76-dig | Fifth word: Terrible |
| 19:27.22 | Corydon76-dig | as in, Y'all are terrible |
| 19:27.39 | Corydon76-dig | s/ble/bly silly/ |
| 19:27.54 | Cresl1n | we need more words than that for the online madlib poetry generator |
| 19:27.58 | russellb | runs around in polygons |
| 19:29.10 | Corydon76-dig | runs around in one-dimensional space |
| 19:29.23 | Cresl1n | that's just wrong |
| 19:29.32 | Cresl1n | slaps Corydon76-dig |
| 19:30.43 | Corydon76-dig | Cresl1n: haven't read Flatland recently? |
| 19:31.41 | Cresl1n | :-) |
| 19:31.46 | Cresl1n | Is that a Niven book? |
| 19:32.37 | Corydon76-dig | Abbott |
| 19:35.09 | mvanbaak | I hate to give an opinion while I have totally no knowledge |
| 19:35.34 | mvanbaak | but cant you look at OpenBSD's implementation of sequence numbers in tcp packets ? |
| 19:35.42 | mvanbaak | they have some random implementation in there |
| 19:35.56 | mvanbaak | so you cannot predict the next packets number |
| 19:37.05 | mvanbaak | it's ISN btw |
| 19:37.10 | mvanbaak | Initial sequence number |
| 19:37.35 | mvanbaak | modulate state: Much of the security derived from TCP is attributable to how well the initial sequence numbers (ISNs) are chosen. Some popular stack implementations choose very poor ISNs and thus are normally susceptible to ISN prediction exploits. By applying a modulate state rule to a TCP connection, pf(4) will create a high quality random sequence number for each connection endpoint. The modulate state directive implicitly keeps state on the |
| 19:38.06 | mvanbaak | maybe you can use that code to generate callno's |
| 19:38.07 | russellb | time for another flight, wheee ... |
| 19:38.29 | mvanbaak | it's 3clause BSD license |
| 19:39.01 | mvanbaak | just spitting out $random_ideas here |
| 19:39.08 | *** part/#asterisk-dev Cresl1n (n=matt@65.14.229.26) |
| 19:39.11 | mvanbaak | so shoot me if it's worthless |
| 19:39.16 | seanbright | shoots mvanbaak |
| 19:39.48 | mvanbaak | thank you |
| 19:39.52 | seanbright | :) |
| 19:40.03 | seanbright | didn't read a word you said except "so shoot me" |
| 19:45.09 | ctooley | codefreeze-lap, ok, so what data out of these runs do you want, what's a useful way to present it and how much background would you like? |
| 19:48.12 | *** join/#asterisk-dev ajohnson (n=ajohnson@63.147.46.186) |
| 20:18.31 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-168642.home.otenet.gr) |
| 21:00.12 | seanbright | hold off on upgrading to svn 1.5 |
| 21:00.15 | seanbright | that is my advice for today |
| 21:00.21 | mvanbaak | lol seanbright |
| 21:08.36 | *** join/#asterisk-dev snuff-home (n=snuffy@60-240-117-7-nsw-pppoe.tpgi.com.au) |
| 21:14.44 | *** join/#asterisk-dev jreign (n=reign@router.asteriasgi.com) |
| 21:15.31 | jreign | Can one issue an originate manager event for the pickup command *8? |
| 21:16.47 | putnopvut | jreign: you could issue an originate which called the pickup application or which called an extension which used the pickup application. |
| 21:17.56 | jreign | by setting Exten: *8?? |
| 21:21.44 | jreign | How would I issue an originate that called the pickup app? |
| 21:22.32 | mvanbaak | exten = |
| 21:22.49 | mvanbaak | exten => some_number,1,Pickup(<arguments>) |
| 21:22.50 | codefreeze-lap | ctooley: there are two places I see really big times to grant locks. One is the channel lock in __ast_answer. The other is the channel lock in ast_wairfor_nandfds(). I can explain both. Apparently, when INVITE is rcvd, chan_sip fires up a pbx processor in its own thread. Firing up the thread takes millions of clock ticks. Err, tens of millions of clock ticks, at least on my test machine. Funny, I once recorded it at 200k clock ticks. Must have |
| 21:23.33 | *** join/#asterisk-dev RoyK (n=roy@ip-158-24-149-91.dialup.ice.no) |
| 21:24.11 | jreign | I want to do this without using the dialplan |
| 21:25.42 | codefreeze-lap | ctooley: the other long-time-wait for lock is in the nandfds routine; there it might normally be a fairly short wait, except that occassionally, it is bumping into the ast_queue_frame routine, which gets a lock before it, and nandfds ends up waiting for it to finish. I haven't seen any other reasons, but I'm dealing with fairly small samplings of around 4 or 5 calls at a shot. |
| 21:26.43 | putnopvut | jreign: you can do a manager originate where instead of specifying an exten, context, and priority, you specify an application. issue a "manager show command originate" from the CLI for more details. |
| 21:27.08 | *** part/#asterisk-dev RoyK (n=roy@ip-158-24-149-91.dialup.ice.no) |
| 21:28.09 | codefreeze-lap | ctooley: I am curious about the huge amount of time that it takes to spawn a thread. Is this the case in 1.4? I committed some code that times the spawning in chan_sip.c, around line 17940; I (or you) are welcome to replicate this snippet in 1.4, and see if the results are the same. |
| 21:30.03 | jreign | putnopvut: thanks |
| 21:44.27 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 21:46.00 | codefreeze-lap | ctooley: O MY! OH MY!!! I did the exact same timing on ast_pbx_start in 1.4, and it only takes from 55 to 772 microseconds! Compared in trunk to 9000 to 47000! That's like 200x slower at the low end!! Why would spawning a thread take so much longer in trunk??????? |
| 21:46.50 | mvanbaak | holy smokes |
| 21:46.55 | putnopvut | codefreeze-lap: what's the difference between the two functions in 1.4 and trunk? |
| 21:46.57 | mvanbaak | that's a lot |
| 21:47.29 | codefreeze-lap | putnopvut: I didn't think there were *any* changes.... but there must be something going on deep down... |
| 21:49.01 | ctooley | codefreeze-lap, ding ding ding, we've found a winner! |
| 21:49.19 | putnopvut | Yeah, just looking at ast_pbx_start, the code is (while not exactly the same) almost identical. |
| 21:49.59 | ctooley | codefreeze-lap, Now.... we just need to figure out how to fix that. :) |
| 21:49.59 | Corydon76-dig | There is literally no difference between the two thread creation routines between 1.4 and trunk |
| 21:50.35 | ctooley | and by "we", I mean someone that knows that part of the code far better than I. |
| 21:51.29 | codefreeze-lap | And yet, on the same machine, compiler, etc. etc. etc. one runs like 200 times slower than the other, after things calm down... |
| 21:51.34 | putnopvut | The only difference I see is that there is an extra alloca() call for the pthread_attr_t. I don't think that should cause significant slowdown though. |
| 21:52.27 | ctooley | Corydon76-dig, That make me off the hook for keeping the bug open? :) |
| 21:53.21 | Corydon76-dig | ctooley: only if you figure that out |
| 21:54.19 | putnopvut | codefreeze-lap: have you tried transplanting 1.4's ast_pbx_start into trunk to see if that changes anything in your tests? |
| 21:54.20 | ctooley | Corydon76-dig, that fact that someone sees the issue, means it's not just me, and that's significant enough that I'd suspect it ranks plenty high in priority. |
| 21:54.50 | ctooley | s/that fact/The fact/ |
| 21:55.49 | ctooley | codefreeze-lap, I don't have any way to generate non-SIP calls, but if it appears to be an ast_pbx_start issue, I'd expect it to effect other channel types as well, correct? |
| 21:56.34 | codefreeze-lap | Hmmm, weird.... the 60 microsecond estimated avg comes out to around 167 k cpu ticks, which I've seen before in trunk, when it registered 250 k or so previously... what on earth is going on? |
| 21:57.15 | ctooley | codefreeze-lap, are you indexing your laptop with Google Desktop at the same time? :) |
| 21:57.20 | snuff-home | hey Corydon76-dig sorry bout the union vars not having right names.. it was late and i needed sleep ;) |
| 21:57.50 | codefreeze-lap | ctooley, wait a minute, I have a job for you. I'll grab a code snippet for you to put into your chan_sip.c over at your site, and you see what it does... hang on |
| 21:58.05 | ctooley | ko |
| 21:58.17 | ctooley | do you want it in the 1.4, trunk, or mtxprof version? |
| 21:59.16 | Corydon76-dig | snuff-home: Names aren't the query |
| 21:59.34 | Corydon76-dig | snuff-home: did you have an alignment issue that that patch solved? |
| 22:00.17 | codefreeze-lap | ctooley: 1.4 first, then trunk on your hardware/kernel/etc. |
| 22:01.03 | ctooley | codefreeze-lap, ok. Unfortunately it'll have to wait until tomorrow or at least later. They're running a test job on the box I have been using to test out some other aspects of Griffin. |
| 22:01.45 | snuff-home | yep.. |
| 22:02.02 | snuff-home | we still have the other 2 major points.. iax and dundi |
| 22:02.11 | ctooley | codefreeze-lap, please email me what you need, or put it in the bug. I've got to run. |
| 22:03.06 | ctooley | codefreeze-lap, I'll get an email if you put it on the bug, notifying that it's there. |
| 22:03.09 | ctooley | later all. |
| 22:04.16 | codefreeze-lap | ctooley: see http://www.pastebin.ca/1056761... it's a patch for 1.4 |
| 22:04.44 | codefreeze-lap | a day late, a dollar short, as usual |
| 22:05.10 | Corydon76-dig | snuff-home: Kevin would like to see the error that you had prior to the patch |
| 22:05.58 | snuff-home | k its just like the msg u get in that other bug report i made for solaris alignment |
| 22:06.17 | wwalker | codefreeze-lap: ctooley is gone I'll get the patch to him tonight or in the morning. |
| 22:06.19 | snuff-home | will try to get u output today |
| 22:06.40 | snuff-home | but onsite at customer most of today |
| 22:09.51 | *** join/#asterisk-dev brookshire (i=mbrooks@65.172.243.127) |
| 22:24.06 | codefreeze-lap | wwalker: thanks! I just sent him an email with the patch attached, also. |
| 22:24.18 | codefreeze-lap | One way, or the other! |
| 22:32.45 | wwalker | codefreeze-lap: thanks for the quick patch! :) |
| 22:35.11 | *** part/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 22:35.31 | codefreeze-lap | wwalker: no prob; if ctooley sees the same big diff between 1.4 and trunk as I do, then we have something we can optimize. |
| 22:36.02 | wwalker | we were seeing an overall 30-60X |
| 22:46.46 | Qwell | shouldn't ast_find_lock_info() unlock the lock_info lock? O.o |
| 22:47.10 | Qwell | mmm, maybe not |
| 22:47.26 | seanbright | lockity lock lock lock |
| 22:47.55 | file | don't ... talk ... back? |
| 22:47.56 | Qwell | hmm, yeah...it does seem a little odd that it doesn't get unlocked |
| 22:49.40 | Qwell | Corydon76-dig: thoughts? |
| 22:50.52 | Corydon76-dig | Qwell: The sky is a delightful shade of blue |
| 22:51.00 | file | rather grey here |
| 22:54.48 | Qwell | Corydon76-dig: is there some reason it doesn't unlock? |
| 22:55.25 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@216.207.245.1) |
| 22:55.27 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 22:55.28 | putnopvut | I put in another vote that it's weird that it is not unlocked. |
| 22:56.08 | putnopvut | And the DLA_UNLOCK macro kind of blows my mind. |
| 22:56.12 | Corydon76-dig | Qwell: unlock what? |
| 22:56.20 | Qwell | ast_find_lock_info() |
| 22:56.31 | putnopvut | it doesn't unlock the lock_info->lock |
| 22:57.03 | putnopvut | (except on failure) |
| 22:57.30 | Corydon76-dig | An oversight, perhaps? |
| 22:57.41 | seanbright | i think it was malicious |
| 22:57.46 | putnopvut | lol |
| 22:57.55 | Qwell | just trying to figure out if that could actually be the deadlock I'm seeing |
| 22:58.22 | putnopvut | Qwell: You could always add the unlock and see if the deadlock still happens. |
| 22:58.23 | mvanbaak | 'I see dead locks' |
| 22:58.39 | Qwell | putnopvut: pita to reproduce on my machine.. |
| 22:58.47 | Qwell | and Marko doesn't have ccache :p |
| 22:58.53 | seanbright | but if unlocking doesn't stop the deadlock than remove the unlock so that the lock stays locked |
| 22:59.04 | Qwell | seanbright: dr seuss? |
| 22:59.07 | putnopvut | parse erro |
| 22:59.09 | putnopvut | dammit |
| 22:59.19 | seanbright | Qwell: dr who? |
| 22:59.21 | seanbright | ba dum dum |
| 22:59.24 | mvanbaak | hands Qwell the key for the lock |
| 23:00.07 | seanbright | "3 reasons to register for AstriCon now!" |
| 23:00.16 | seanbright | here's 1 not to: i'm POOR. |
| 23:00.17 | seanbright | heh |
| 23:00.24 | mvanbaak | ok, smoking pot, drinking wine and talking on IRC is not the best combination |
| 23:00.34 | file | seanbright: well you know a way to overcome that! |
| 23:00.40 | seanbright | smoking pot? damn hippies. |
| 23:00.57 | seanbright | where hippies == europeans |
| 23:01.00 | mvanbaak | seanbright: I have the same problem. no money to come oven to USA |
| 23:01.09 | mvanbaak | s/oven/over/ |
| 23:01.17 | mvanbaak | freaking qwerty keyboard |
| 23:01.18 | seanbright | mvanbaak: count your lucky stars |
| 23:01.29 | mvanbaak | loadkeys us.dvorak |
| 23:01.29 | Corydon76-dig | Qwell: you fixing it? |
| 23:01.31 | mvanbaak | there, better |
| 23:02.02 | Qwell | no, I can though |
| 23:02.11 | Corydon76-dig | whomever |
| 23:02.22 | outtolunc | awaits another email with a coupon code for astricon <G> pretty please <G> |
| 23:02.29 | Corydon76-dig | I can fix it if you're in the middle of something else |
| 23:02.57 | Corydon76-dig | How did that not bite us until now? |
| 23:03.05 | Qwell | umm, dunno |
| 23:03.18 | Qwell | committed. look right? |
| 23:03.20 | *** join/#asterisk-dev bkw_ (n=brian@adsl-70-234-169-185.dsl.tul2ok.sbcglobal.net) |
| 23:03.25 | mvanbaak | outtolunc: if you get one, send me a copy please |
| 23:03.39 | outtolunc | k |
| 23:03.47 | mvanbaak | thanks |
| 23:04.00 | Corydon76-dig | Qwell: Yes |
| 23:05.00 | seanbright | i saw another good commit message earlier... |
| 23:05.03 | seanbright | goes to find it |
| 23:05.42 | Corydon76-dig | Speaking of good commit messages, do we need a humor_impaired option in asterisk.conf? |
| 23:06.27 | outtolunc | yeah 'if kernel version < 2.6.19 punt <G>' |
| 23:06.57 | Corydon76-dig | outtolunc: we've had some people tell us some of the error messages 'looked unprofessional' |
| 23:07.12 | seanbright | meh... can't find it |
| 23:07.15 | putnopvut | yeah, and that crap sucks. |
| 23:07.16 | outtolunc | i just changed the source to 2.6.18 <G> |
| 23:07.22 | mvanbaak | what's a 'paging device' in chan_skinny ? |
| 23:07.48 | seanbright | Corydon76-dig: they do |
| 23:07.53 | seanbright | well |
| 23:08.05 | Corydon76-dig | seanbright: They've got personality |
| 23:08.08 | seanbright | some of the more obvious ones have been removed ("they're gonna be PISSED") |
| 23:08.21 | seanbright | Corydon76-dig: i don't disagree |
| 23:08.24 | mvanbaak | Corydon76-dig: they must be talking about the ast_canary stuff |
| 23:08.35 | seanbright | new janitor project: remove all ! from log messages. |
| 23:08.35 | Corydon76-dig | seanbright: hence why humor_impaired=yes|no |
| 23:08.38 | putnopvut | and the "poopy" error messages. |
| 23:09.42 | Corydon76-dig | See, I want to put something like that in, and have someone down the line of a humor_impaired=yes installation go, "Hmm, what does this do?" and turn it off... |
| 23:10.40 | seanbright | Corydon76-dig: it would be great until people started filing mantis issues against it. |
| 23:10.41 | putnopvut | Then they'll hear random cuckoos and slide whistles in the middle of their conversations. |
| 23:11.03 | seanbright | 18924371: humor_impaired should take 1, 0, true, and false as well as yes and no. |
| 23:11.24 | Corydon76-dig | seanbright: it would already, as it would use ast_true() |
| 23:11.46 | seanbright | stares at his point as it flies across the room and darts out the window |
| 23:11.52 | putnopvut | lol |
| 23:11.58 | seanbright | bye bye little friend |
| 23:12.00 | seanbright | heh |
| 23:12.23 | Corydon76-dig | Speaking of things flying out the window, are you going to go see Wall-E tomorrow? |
| 23:12.44 | seanbright | and wait, does " yes" evaluate to true or false? ;-) |
| 23:12.45 | putnopvut | no |
| 23:12.47 | seanbright | wtf is wall-e? |
| 23:12.49 | seanbright | oh |
| 23:12.52 | seanbright | new movie? |
| 23:12.58 | putnopvut | new pixar movie |
| 23:13.02 | Corydon76-dig | You haven't seen the trailers? |
| 23:13.09 | seanbright | i'm saving my energy for 'the dark knight' |
| 23:13.22 | Corydon76-dig | http://www.pixar.com/theater/trailers/walle/index.html |
| 23:13.45 | Corydon76-dig | I'm rather excited about seeing it |
| 23:14.01 | file | I was just talking to a friend about seeing it |
| 23:14.03 | file | scary. |
| 23:14.11 | seanbright | i get to see dark knight 2 days before its released to the general public |
| 23:14.14 | seanbright | that makes me happy |
| 23:14.22 | Corydon76-dig | Heh |
| 23:14.33 | file | disappears |
| 23:15.27 | seanbright | whoa |
| 23:15.29 | seanbright | where did file go? |
| 23:15.38 | seanbright | one second he was here |
| 23:15.40 | seanbright | the next |
| 23:15.41 | seanbright | he was gone |
| 23:24.35 | *** join/#asterisk-dev pabelanger (n=pabelang@OTWAON23-1242541604.sdsl.bell.ca) |
| 23:25.09 | pabelanger | <PROTECTED> |
| 23:25.34 | pabelanger | do you have to compile any extra options into zaptel to get valgrind to work? |
| 23:26.08 | mvanbaak | Fri Jun 27 01:26:08 CEST 2008 |
| 23:26.12 | pabelanger | because when I run valgrind and asterisk together, it crashes right away and generates a core file. And looks to be within zaptel. |
| 23:26.13 | mvanbaak | time to get some sleep |
| 23:26.20 | mvanbaak | 6AM is wakeup time |
| 23:27.42 | *** join/#asterisk-dev frieze (n=frieze@pool-98-113-86-28.nycmny.fios.verizon.net) |
| 23:30.55 | frieze | okay so the good news is that now I have c han_mobile running. the bad news is that it kernel panics every time my phone connects |
| 23:31.28 | seanbright | frieze: sweet |
| 23:31.39 | seanbright | frieze: did you have to change the code any more to get it to run? pre-panic, anyway? |
| 23:31.43 | seanbright | Corydon76-dig: still here? |
| 23:32.01 | Corydon76-dig | Kind of |
| 23:32.10 | seanbright | i'll try to be quick |
| 23:32.13 | frieze | not beyond the patches you got me |
| 23:32.18 | seanbright | finishing up the cdr_tds stuff |
| 23:32.28 | seanbright | and i want to get the reload behavior correct |
| 23:32.32 | Corydon76-dig | does it work? |
| 23:32.48 | seanbright | haven't done the adaptive bits |
| 23:32.50 | seanbright | but otherwise, yes. |
| 23:32.52 | frieze | it actually works with the linksys adapter I have, but that chipset makes bluez unhappy for voice. th enew d-link one I have is approved by bluez, but kernel panics |
| 23:33.08 | seanbright | frieze: sounds like a library/device issue |
| 23:33.15 | seanbright | frieze: i.e. not asterisk |
| 23:33.16 | frieze | apparently badly enough that it doesn't make it to kern.log |
| 23:33.19 | frieze | yeah |
| 23:33.58 | seanbright | Corydon76-dig: so my question is this. you've got the module configured and happily posting records and then either a) remove cdr_tds.conf, or b) remove the contents of cdr_tds.conf and then reload. |
| 23:34.02 | seanbright | Corydon76-dig: what should happen? |
| 23:34.20 | Corydon76-dig | It should stop logging |
| 23:34.26 | seanbright | Corydon76-dig: cool. |
| 23:34.32 | seanbright | that's all i wanted to know. |
| 23:34.34 | frieze | looks like #bluez for me |
| 23:34.45 | seanbright | frieze: indeed. good luck and god speed and such. |
| 23:34.51 | frieze | thanks |
| 23:35.10 | Corydon76-dig | seanbright: exactly reverse of what happens if you had no file, created it, and then did a reload: it should then start logging |
| 23:35.41 | seanbright | i thought in that scenario the core would make you do a load first |
| 23:36.19 | seanbright | thought i saw an error message in loader.c to that effect, anyway. |
| 23:36.38 | Corydon76-dig | seanbright: only if it wasn't loade |
| 23:36.41 | Corydon76-dig | +d |
| 23:36.50 | putnopvut | pabelanger: I've never used valgrind with zaptel before, so I'm unsure of any special considerations that need to be made. |
| 23:36.51 | seanbright | Corydon76-dig: ah. |
| 23:37.34 | seanbright | Corydon76-dig: i also think that is a little weird. if there is no cdr_tds.conf, it doesn't appear that you can return anything from .load that will cause the module to be unloaded (without stopping subsequent modules from loading) |
| 23:37.56 | seanbright | returning _DECLINE from .load doesn't unload the module |
| 23:38.08 | Corydon76-dig | Correct |
| 23:38.33 | seanbright | i am assuming that is desired for one reason or another |
| 23:38.34 | Corydon76-dig | In that case, I wouldn't decline the load |
| 23:39.04 | Corydon76-dig | seanbright: Try turning on the code to make it unload sometime when you have lots of time to mess with it. |
| 23:39.17 | Corydon76-dig | The loader code goes kaboom |
| 23:39.20 | seanbright | is it a pain in the ass? |
| 23:39.21 | seanbright | ah |
| 23:39.39 | seanbright | is that a challenge to the reader or a wild goose chase? |
| 23:39.45 | pabelanger | nm: seem to found the issue with valgrind, it doesn't like codec_g729.so |
| 23:40.46 | Juggie | seanbright, i dont think modules actually dont load |
| 23:40.52 | Juggie | they just end up in purgatory |
| 23:41.08 | seanbright | no, that i get |
| 23:41.23 | seanbright | once the dso is loaded you can't unload it |
| 23:41.47 | Juggie | forgive my ignorance, dso? |
| 23:41.58 | seanbright | shared library. |
| 23:42.12 | seanbright | dynamic shared object |
| 23:42.18 | Juggie | ah |
| 23:42.26 | seanbright | that's what i used to call them at least |
| 23:46.23 | seanbright | i think the terminology is outdated, actually. |
| 23:49.41 | seanbright | goes home. |