| 00:13.49 | *** join/#asterisk-dev moy (n=moyhu@189.169.83.78) |
| 00:43.55 | *** join/#asterisk-dev stevie_ramjet (n=putnopvu@c-71-228-178-34.hsd1.al.comcast.net) |
| 00:43.55 | *** mode/#asterisk-dev [+o stevie_ramjet] by ChanServ |
| 01:18.46 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-210-44.west.biz.rr.com) |
| 01:43.31 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 01:52.19 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 01:52.19 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 02:22.56 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.108.119) |
| 02:22.56 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 04:40.43 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 04:57.06 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 05:04.17 | *** join/#asterisk-dev fabled (n=fabled@xdsl-83-150-94-239.nebulazone.fi) |
| 05:16.10 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 05:16.30 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 05:16.32 | *** part/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 06:01.37 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 06:20.57 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.142) |
| 06:26.09 | *** join/#asterisk-dev droem (i=droem@p548EA642.dip0.t-ipconnect.de) |
| 08:19.22 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 08:29.06 | *** join/#asterisk-dev obnauticus (n=obnautic@c-67-160-181-107.hsd1.wa.comcast.net) |
| 08:58.56 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 08:58.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:01.27 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-106428.home.otenet.gr) |
| 09:01.48 | oej | Hello |
| 09:08.47 | snuff-home | ello oej |
| 09:09.02 | oej | Morning Snuff |
| 09:10.15 | snuff-home | is yet to see how having a union is any different to making a var of the bigger type and casting it back to smaller things |
| 09:10.47 | oej | It's easier to read and understand the union than casting things around. Well, on the other hand, a union can be pretty confusing too. |
| 09:11.26 | snuff-home | mm.. i like the unions too.. |
| 09:12.07 | snuff-home | atm got other alignment issue that scares me.. and i'm without a clue how to fix.. |
| 09:12.33 | snuff-home | <PROTECTED> |
| 09:12.38 | snuff-home | grrr |
| 09:13.47 | snuff-home | <PROTECTED> |
| 09:13.59 | snuff-home | mm.. stupid copy n paste |
| 09:14.14 | snuff-home | line 114 of astobj2.c |
| 09:15.48 | *** join/#asterisk-dev RoyK (n=roy@box36.fortel.no) |
| 09:17.37 | snuff-home | astobj2.c:114: warning: cast increases required alignment of target type |
| 09:17.51 | snuff-home | at that line.. |
| 09:17.54 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.135) |
| 09:17.55 | oej | Casts are hard to handle |
| 09:18.18 | snuff-home | mm especially void * ones + offsets :) |
| 09:18.46 | snuff-home | basically sparc = no unaligned accesses.. so it falls foul :) |
| 09:20.11 | snuff-home | corydon made an attempt at union'ising iax2... but failed at initial attempt |
| 09:20.28 | snuff-home | see 11485 |
| 09:48.26 | *** join/#asterisk-dev RoyK (n=roy@ti200720a080-1442.bb.online.no) |
| 10:12.06 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 10:19.22 | *** join/#asterisk-dev agx (n=AGX@88.34.216.63) |
| 10:33.54 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca) |
| 10:47.05 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:47.52 | *** join/#asterisk-dev shtoom (n=shtoom@121.246.167.147) |
| 10:54.50 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 10:54.58 | *** join/#asterisk-dev juanjoc (n=juanjoc@host223.190-225-200.telecom.net.ar) |
| 11:02.08 | mvanbaak | gheh |
| 11:02.24 | mvanbaak | gcc -O -Wall -O -Wall -O -Wall -O -Wall -O -Wall -O -Wall -O -Wall -O -Wall -O -Wall -O -Wall -c mxml-string.c |
| 11:02.35 | mvanbaak | maybe we should compile mxml with -O -Wall |
| 11:02.36 | mvanbaak | ;) |
| 11:04.15 | seanbright | that way it's super optimized |
| 11:04.48 | seanbright | you'd figure with -Wall you'd get something like "-Wall specified too many times. Aborting." |
| 11:05.05 | mvanbaak | yeah |
| 11:21.59 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582944.dsl.bell.ca) |
| 11:30.18 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 11:33.32 | mvanbaak | seanbright: what's the big win with hoard ? |
| 11:36.52 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:38.02 | seanbright | mvanbaak: not sure yet :) gotta finish getting the build to work |
| 11:39.03 | seanbright | mvanbaak: according to russell, some users report performance improvements. want to get a gauge of that. |
| 11:40.22 | mvanbaak | ah |
| 11:43.56 | ctooley | what's hoard? |
| 11:44.04 | seanbright | http://www.hoard.org/ |
| 11:44.36 | ctooley | hmmmm |
| 11:44.51 | ctooley | I'd be interested to see how that affects our routing platform. |
| 11:45.15 | seanbright | well i'll put together some baseline numbers |
| 11:45.55 | ctooley | seanbright, would be hard for me to do the same, we're already timing everything and it's brother in Asterisk now to try to track down the channel creation issue. |
| 11:48.36 | seanbright | well the most i plan to do is "i was able to create this X channels in Y seconds without hoard. and P channels in Q seconds with hoard." |
| 12:06.20 | snuff-home | mm.. i think menuselect is broken.. least on solaris |
| 12:06.33 | snuff-home | wasn't there a change recently removing 'nmenuselect' etc? |
| 12:07.26 | ctooley | Not that I remember, but I'm not here all the time |
| 12:08.17 | snuff-home | mm kpfleming commited something getting rid of it |
| 12:10.42 | snuff-home | grr.. without the option of 'nmenuselect' it tries to use f'n GTK |
| 12:12.05 | snuff-home | mm.. looks like 'cmenuselect' works still... yey |
| 12:13.42 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:13.42 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:14.21 | snuff-home | ello russellb |
| 12:15.31 | russellb | waves |
| 12:15.55 | snuff-home | i got lovely alignment issue with astobj2 if u feel up to it :P |
| 12:16.35 | russellb | bugs.digium.com i guess |
| 12:17.14 | snuff-home | just wondering if u knew off hand.. per say why this might be.. |
| 12:17.51 | russellb | nope |
| 12:20.07 | snuff-home | p = (struct astobj2 *) ((char *) user_data - sizeof(*p)); |
| 12:20.25 | snuff-home | such a nice line i think :) |
| 12:21.21 | russellb | pointer math ftw |
| 12:22.00 | snuff-home | mm.. another lot of pointer math is wonderful iax |
| 12:23.43 | russellb | yep |
| 12:24.38 | snuff-home | cory tried hard to 'union-ise' the cast heaven on the incoming data packet.. shame didn't work.. |
| 12:25.30 | snuff-home | well on 1st attempt |
| 12:34.23 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.140.193) |
| 12:35.46 | ctooley | well, then consult the Pope. Catholics have tried to unionise the heaven cast for centuries and shame works for them. :) |
| 12:37.19 | seanbright | unions are bad for business |
| 12:37.33 | seanbright | though i would join a developers union if the price was right |
| 12:37.34 | seanbright | heh |
| 12:43.38 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:09.45 | ctooley | Where can I find the "retransmit" time in chan_iax2.c? I'm seeing a "NEW" go out and then roughly every 20ms after that "VNAK" messages before the "AUTHREQ" has a chance to come back from the remote party. |
| 13:10.08 | ctooley | I need to figure out where that timing is and see if I can stretch it out, because this is a highly latent connection (600+ms) |
| 13:28.07 | seanbright | russellb: do the coding guidelines on the asterisk.org site update based on what is in CODING_GUIDELINES? |
| 13:28.17 | russellb | doubt it |
| 13:28.19 | russellb | didn't know they were on ther |
| 13:28.26 | russellb | we should just link to svn ... |
| 13:28.26 | seanbright | http://www.asterisk.org/developers/coding-guidelines |
| 13:28.29 | seanbright | yeah |
| 13:28.30 | russellb | lame |
| 13:28.39 | seanbright | well its prettier on the interweb |
| 13:28.56 | *** join/#asterisk-dev RoyK (n=roy@ti200720a080-1442.bb.online.no) |
| 13:28.58 | russellb | meh |
| 13:30.35 | *** join/#asterisk-dev jeffg (i=7lP6KMtC@pdpc/supporter/active/jeffg) |
| 13:32.03 | russellb | there, added a note to the top. |
| 13:40.14 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 14:00.48 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable156.137-20-96.mc.videotron.ca) |
| 14:02.53 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:02.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:03.08 | snuff-home | hello putnopvut :) |
| 14:03.21 | putnopvut | Hi snuff-home! |
| 14:03.40 | snuff-home | says another day another alignment issue :D |
| 14:04.03 | putnopvut | snuff-home: have you seen kpfleming's recent work wrt that? |
| 14:04.32 | snuff-home | mm.. only part in 'aligned' branch if that's what ur talkin abot? |
| 14:04.41 | putnopvut | snuff-home: yeah, that's what I'm talking about. |
| 14:05.36 | snuff-home | mm i have seen it.. i have about 10 alignment issues atm.. md5.. iax.. astobj2.. |
| 14:07.31 | snuff-home | but we'll get there eventually |
| 14:08.23 | putnopvut | Have you tried compiling the alignment branch to see if it compiles for you? |
| 14:08.37 | snuff-home | yer not even close :P |
| 14:08.42 | putnopvut | heh |
| 14:08.55 | seanbright | upgrade your OS from solaris to something else entirely |
| 14:08.58 | seanbright | that'll fix you up |
| 14:09.01 | seanbright | :) |
| 14:09.26 | snuff-home | mmm technically.. i should get away from SPARC architechure |
| 14:10.02 | snuff-home | but i really want to see asterisk running on a T5240 |
| 14:11.31 | snuff-home | if i can at least get it going on good old ultrasparc III chips.. it should be close to working on one of those.. |
| 14:15.35 | putnopvut | In trunk, ast_answer() calls __ast_answer() with a 500 ms delay. I did an SVN blame on this and found that kpfleming was the one who added this quite a while back. However, his commit message doesn't really state what problem this delay fixed nor does it reference a bug number. He is not around now, so I was wondering if anyone in here knows why this delay was added. This delay, btw is what is causing issue 12924 to occur. |
| 14:16.21 | file | putnopvut: was added to allow time for the audio stream to setup |
| 14:16.25 | putnopvut | I also suspect that it could be the reason that codefreeze-lap and ctooley are seeing a slowdown in trunk over 1.4, but I could be completely wrong on that. |
| 14:18.18 | putnopvut | file: hmm, okay, what was happening prior to adding that delay? |
| 14:19.03 | snuff-home | missing audio as my guess.. ;) |
| 14:19.05 | file | it was possible to lose some audio |
| 14:19.18 | file | although I suspect it is still the case since this is not a two way audio stream yet, only one way... from the device |
| 14:19.27 | file | shrugs |
| 14:20.31 | russellb | expense away i suppose |
| 14:20.43 | russellb | O.O |
| 14:23.06 | seanbright | expenses |
| 14:45.28 | *** join/#asterisk-dev RoyK (n=roy@158.36.187.198) |
| 14:46.22 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 14:56.51 | bbryant | seanbright: pong (from saturday) |
| 14:56.55 | ctooley | file, putnopvut there's no need to do the delay if there's no audio stream, that separation seems like a big project, but one that's very much worthwhile. |
| 14:57.24 | seanbright | bbryant: i forget :) |
| 14:59.17 | file | ctooley: how do you know there is no audio in your scenario? |
| 14:59.37 | seanbright | bbryant: oh... that regex that matches the merge messages should probably match "Merges revisions foo" and "Blocks revisions foo" |
| 14:59.40 | seanbright | bbryant: that was all. |
| 14:59.42 | ctooley | file, no SDP has been sent, ie: no way to set up RTP |
| 15:00.10 | file | ah, could still be SDP later... and the core doesn't know that stuff... hrm |
| 15:00.15 | ctooley | chan_sip.c currently makes no distinction, and it'll be a major challenge to overcome. |
| 15:00.59 | ctooley | file, right, but until there's SDP, or until Asterisk decides it needs to figure out it's side of the audio stream, the RTP stream is just consuming resources. |
| 15:01.05 | ctooley | (specifically in terms of time) |
| 15:01.21 | file | memory/file descriptors aye |
| 15:01.30 | *** join/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 15:01.30 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 15:01.37 | ctooley | 99.99% asterisk channels are supposed to have audio, I understand that part, but not necessarily at the time they're spun up. |
| 15:02.02 | bbryant | seanbright: good catch |
| 15:07.20 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:07.20 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:13.28 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.41) |
| 15:13.34 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 15:13.35 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 15:15.45 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 15:33.26 | *** join/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 15:33.26 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 15:34.03 | *** join/#asterisk-dev hubguruJR (n=hubguruJ@mail.ntegratedsolutions.com) |
| 15:35.49 | *** part/#asterisk-dev KenLee (n=k3leland@bg-fw2out.monmouth.com) |
| 15:44.42 | tzafrir_laptop | any reason not to rename chan_dahdi.conf to dahdi.conf? (in line with the other channel drivers) |
| 15:45.03 | tzafrir_laptop | As there is no /etc/dahdi.conf any more to confuse things |
| 15:45.32 | jsmith | tzafrir_laptop: You've got my vote |
| 15:47.57 | russellb | because i actually prefer the other convention, as it is more explicit |
| 15:48.06 | russellb | there are multiple modules that use dahdi, and that file is specifically for one of them |
| 15:48.22 | russellb | same goes for SIP, it should be chan_sip.conf, because it is easily conceivable that SIP would exist in another module ... |
| 15:48.27 | russellb | same for RTP, etc, etc, etc |
| 15:49.44 | Qwell | then...should we change all of them? |
| 15:49.56 | russellb | shrugs |
| 15:50.07 | russellb | probably not the ones that already exist |
| 15:50.16 | russellb | since they are referred to in 2308947290384723984 places |
| 15:50.53 | russellb | Qwell: fixed _the_ deadlock, btw |
| 15:50.58 | Qwell | orly? |
| 15:51.04 | russellb | yarly. |
| 15:51.11 | Qwell | committed? |
| 15:51.27 | russellb | not yet |
| 15:51.49 | Qwell | did you manage to reproduce it with debug threads? |
| 15:52.13 | tzafrir_laptop | rtp? main_rtp? |
| 15:52.32 | russellb | rtp is going modular |
| 15:52.39 | russellb | so, res_rtp, whatever it's going to be called |
| 15:53.42 | tzafrir_laptop | having res_foo.conf would be strange . |
| 15:53.43 | jsmith | russellb: Details on the deadlock? |
| 15:53.51 | tzafrir_laptop | It's an implementation detail |
| 15:53.57 | jsmith | tzafrir_home: Why? We already have res_odbc.conf, right? |
| 15:54.18 | tzafrir_laptop | and I don't like it |
| 15:54.20 | Qwell | pbx_config.conf |
| 15:54.42 | tzafrir_laptop | res_* might at some point become part of the core |
| 15:54.48 | tzafrir_laptop | or vice versa |
| 15:55.30 | tzafrir_laptop | Or be split to two |
| 15:55.51 | tzafrir_laptop | What will the name mean then? |
| 15:56.44 | ctooley | Asterisk becoming less modular by moving things into core seems... counterproductive. |
| 15:56.52 | tzafrir_laptop | It forces the sysadmin to be aware of implementation details |
| 15:57.33 | russellb | if you'd like to propose policy changes, please do it on the -dev list |
| 15:58.17 | ctooley | tzafrir_laptop, a sysadmin that is mucking with the configs directly needs to be aware of the differences between chan_sip.so and sip.so. While there's not currently a sip.so, the "chan_" prefix means something, and having the config file reflex that makes sense to me as well. |
| 15:58.50 | tzafrir_laptop | ctooley, sip.so? |
| 15:59.19 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.115.150) |
| 15:59.20 | Cresl1n | chan_iax2.c: Auto-congesting call due to slow response |
| 15:59.27 | Cresl1n | the log message of death |
| 15:59.28 | *** join/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 15:59.42 | ctooley | Cresl1n, yes, fighting that myself. :( |
| 15:59.52 | Cresl1n | oh, good to hear someone else it having that problem |
| 16:00.22 | Cresl1n | ctooley: what version of asterisk are you running? |
| 16:00.28 | ctooley | mine has to do with going over a satellite link though. :( |
| 16:00.29 | tzafrir_laptop | ctooley, a sysadmin is not "mucking with config files". A sysadmin needs to know that config files do certain things |
| 16:00.33 | Cresl1n | oh |
| 16:00.39 | russellb | Cresl1n: deadlock? |
| 16:00.43 | Cresl1n | yesx |
| 16:00.43 | ctooley | Cresl1n, 1.4.19.1 |
| 16:00.50 | russellb | Cresl1n: about to commit a fix for it |
| 16:00.50 | Cresl1n | 1.6.0 branch |
| 16:00.54 | Cresl1n | yeS!!!!~!!!! |
| 16:00.56 | Cresl1n | :-) |
| 16:01.32 | Cresl1n | looks like everybody's locked with the following backtrace: |
| 16:01.32 | Cresl1n | [Switching to thread 5 (Thread 1205221728 (LWP 25132))]#0 0x00002adcd5cd5eeb in __lll_mutex_lock_wait () |
| 16:01.32 | Cresl1n | <PROTECTED> |
| 16:01.32 | Cresl1n | (gdb) bt |
| 16:01.32 | Cresl1n | #0 0x00002adcd5cd5eeb in __lll_mutex_lock_wait () from /lib/libpthread.so.0 |
| 16:01.33 | Cresl1n | #1 0x0000000000001b50 in ?? () |
| 16:01.33 | Cresl1n | #2 0x0000000047d62fb8 in ?? () |
| 16:01.53 | Cresl1n | #3 0x00002adcd5cd2dba in pthread_mutex_lock () from /lib/libpthread.so.0 |
| 16:01.53 | Cresl1n | #4 0x0000000000000001 in ?? () |
| 16:01.53 | Cresl1n | #5 0x00002adcd59f7f5a in calloc () from /lib/libc.so.6 |
| 16:01.53 | Cresl1n | #6 0x00002aaaace12983 in iax_frame_new (direction=1205218800, datalen=-1394516991, cacheable=1) |
| 16:01.53 | Cresl1n | <PROTECTED> |
| 16:01.53 | Cresl1n | #7 0x00002aaaace07688 in socket_process (thread=0x2aaab54e1200) |
| 16:01.53 | Cresl1n | <PROTECTED> |
| 16:01.53 | *** join/#asterisk-dev JerJer (n=PhatJ@pdpc/supporter/bronze/jerjer) |
| 16:01.53 | *** mode/#asterisk-dev [+o JerJer] by ChanServ |
| 16:01.53 | Cresl1n | #8 0x00002aaaace11719 in iax2_process_thread (data=0x2aaab54e1200) at chan_iax2.c:9495 |
| 16:01.53 | Cresl1n | #9 0x00000000004da3dc in dummy_start (data=<value optimized out>) at utils.c:917 |
| 16:01.53 | Cresl1n | #10 0x00002adcd5cd0f1a in start_thread () from /lib/libpthread.so.0 |
| 16:01.53 | russellb | that backtrace is screwed up. |
| 16:01.53 | Cresl1n | #11 0x00002adcd5a535d2 in clone () from /lib/libc.so.6 |
| 16:01.53 | Cresl1n | #12 0x0000000000000000 in ?? () |
| 16:01.55 | Cresl1n | ooops |
| 16:01.55 | russellb | and wtf@pastebomb |
| 16:01.55 | Cresl1n | sorry, that was a little longer than I expected |
| 16:01.57 | russellb | :) |
| 16:02.09 | putnopvut | Yeah, no way pthread_mutex_lock is called from calloc |
| 16:02.09 | Cresl1n | yeah, my bad :-( |
| 16:03.09 | Cresl1n | russellb: let me know when you commit it, as I can probably reproduce it REALLY quickly |
| 16:03.18 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 16:03.21 | JerJer | is there any way to tell if a given IAX service is actively running DUNDi or not? seems like it should be available from the iax_control stuff, but so far I haven't figured it out |
| 16:03.37 | Cresl1n | I just brought the system up to call load capacity and it happened within 5 miutes |
| 16:04.00 | jsmith | JerJer: Nope... DUNDi and IAX2 are two separate and independent protocols |
| 16:04.24 | jsmith | JerJer: (and DUNDi is protocol agnostic...) |
| 16:04.27 | Cresl1n | also, if you'd like to take a look at this back trace I can hook you up too |
| 16:04.45 | JerJer | jsmith: thanks |
| 16:04.59 | jsmith | JerJer: No worries... |
| 16:05.13 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) [NETSPLIT VICTIM] |
| 16:05.13 | *** join/#asterisk-dev paravoid (n=paravoid@zebra.cslab.ece.ntua.gr) [NETSPLIT VICTIM] |
| 16:05.13 | *** join/#asterisk-dev LapTop006 (n=laptop00@gemini.chriskaine.com.au) [NETSPLIT VICTIM] |
| 16:05.13 | *** join/#asterisk-dev jets (n=brian@pdpc/supporter/active/jets) [NETSPLIT VICTIM] |
| 16:05.13 | *** join/#asterisk-dev tzanger (n=tzanger@gromit.mixdown.ca) [NETSPLIT VICTIM] |
| 16:05.33 | *** join/#asterisk-dev Daviey (n=dave@ubuntu/member/daviey) [NETSPLIT VICTIM] |
| 16:05.33 | JerJer | blake and I (mostly blake) are working on a new 'tool' |
| 16:06.14 | russellb | commit asterisk 126573 |
| 16:06.21 | MuffinMan | [126573] Committed by russell on 2008-06-30T15:57:56.550889Z: Fix a typo in the non-DEBUG_THREADS version of the recently added DEADLOCK_AVOIDANCE() |
| 16:06.21 | MuffinMan | ..macro. This caused the lock to not actually be released, and as a result, not |
| 16:06.21 | MuffinMan | ..avoid deadlocks at all. This resolves the issues reported in the last while about |
| 16:06.21 | MuffinMan | ..Asterisk locking up all over the place (and most commonly, in chan_iax2). |
| 16:06.23 | MuffinMan | .. |
| 16:06.25 | MuffinMan | ..(closes issue #12927) |
| 16:06.27 | MuffinMan | ..(closes issue #12940) |
| 16:06.29 | MuffinMan | ..(closes issue #12925) |
| 16:06.32 | MuffinMan | ..(potentially closes others ...) |
| 16:06.41 | Qwell | wtfpwnt! I was sort of on the right track |
| 16:07.14 | Qwell | wow |
| 16:07.28 | Cresl1n | nice! |
| 16:07.31 | Cresl1n | this is probably the bug for me |
| 16:07.37 | Cresl1n | was this in 1.6.0 branch too? |
| 16:07.38 | russellb | :) |
| 16:07.40 | russellb | nods |
| 16:07.49 | Cresl1n | runs to update |
| 16:07.55 | russellb | still merging it up though |
| 16:08.00 | Cresl1n | ok |
| 16:08.02 | Cresl1n | waiting |
| 16:08.32 | Qwell | silly recursive locks |
| 16:10.48 | russellb | Cresl1n: done |
| 16:10.50 | Cresl1n | cool! |
| 16:10.50 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.133) |
| 16:10.53 | Cresl1n | updating and installing |
| 16:15.03 | *** topic/#asterisk-dev by jsmith -> Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@pbx.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- Automated Builds, thx file! - http://buildbot.digium.com -=- Yay to russellb for tracking down a nasty deadlock! |
| 16:15.18 | Cresl1n | russellb: updated, now cranking up the calls |
| 16:15.23 | Qwell | oh, so it actually was in 1.4.21 |
| 16:15.24 | Qwell | sucky |
| 16:18.21 | JerJer | jsmith / anyone: does DUNDi have some sort of equivlant function to the 'iax poke' ? |
| 16:19.07 | jsmith | JerJer: Yes... it has a qualify similar to an IAX2 poke or a SIP OPTIONs packet |
| 16:19.28 | JerJer | interesting - i'll have to go scan the code again, closer this time |
| 16:19.37 | JerJer | thanks once again |
| 16:20.44 | JerJer | jsmith: off the top would DUNDi respond to a '3rd party' ? |
| 16:20.47 | Laureano | russellb, your's How-to about writing an asterisk module are excelent. Thank you. |
| 16:20.58 | russellb | Laureano: you're welcome :) |
| 16:21.03 | russellb | thanks for the kind words |
| 16:21.12 | JerJer | jsmith: like not a peer |
| 16:21.18 | Laureano | :-) |
| 16:21.21 | jsmith | JerJer: I'm not sure I'm following you... |
| 16:22.26 | anonymouz666 | Laureano: where I can read? |
| 16:23.11 | Laureano | On the russell's blog: http://www.russellbryant.net/blog/ |
| 16:23.37 | Laureano | It's a 3 part series (by now). |
| 16:24.13 | anonymouz666 | wonderful, didn't know that. |
| 16:24.57 | Laureano | Subscribing to the RSS feed is a good idea. |
| 16:32.39 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 16:32.39 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 16:33.04 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 16:33.04 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:52.01 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 16:52.28 | jpeeler | would it be considered unacceptable for all devices using dahdi to eventually have to be hung up for a restart to complete? |
| 16:52.40 | jpeeler | (dahdi restart) |
| 16:53.40 | Corydon76-lap | jpeeler: If it's necessary for the channel type... do what needs to be done |
| 16:54.08 | jpeeler | well i don't know... it might be possible to not require it |
| 16:54.36 | jpeeler | was wondering if it's worth spending a lot of time on or if what i said was fine |
| 16:54.37 | Corydon76-lap | Maybe set a timer that says "Still waiting... You might want to force some channels to hangup if you want the restart to happen soon" |
| 16:55.02 | russellb | restart now, restart when convenient ... |
| 16:55.21 | putnopvut | restart yesterday |
| 16:55.23 | jpeeler | just dahdi restart |
| 16:55.29 | Corydon76-lap | My guess is that for some channel types (PRI) all the channels have to go down to safely accomplish a restart anyway |
| 16:55.40 | tzafrir_laptop | jpeeler, dahdi restart is a hack |
| 16:55.48 | Cresl1n | yeah |
| 16:55.54 | jpeeler | tzafrir_laptop: well it doesn't even work now |
| 16:55.59 | jpeeler | i've spent a lot of time improving it |
| 16:56.00 | Cresl1n | dahdi restart has got issues, that's for sure |
| 16:56.21 | tzafrir_laptop | getting it to work with PRI would take major changes. Getting it to work with analog only wouldn't take many changes. I think I opeened once a bug on it |
| 16:56.32 | jpeeler | you did |
| 16:56.36 | jpeeler | M11017 |
| 16:56.39 | MuffinMan | [assigned] [Asterisk] Channels/chan_zap 0011017: [patch] zap restart fails to generate channels reported by tzafrir (Karma: +98.00) http://bugs.digium.com/view.php?id=11017 |
| 16:56.56 | jpeeler | changes since then make your patch outdated |
| 16:57.04 | tzafrir_laptop | the alternative is 'module unload chan_dahdi' 'module load chan_dahdi' |
| 16:57.20 | tzafrir_laptop | Frankly I was not aware of it when I first wrote 'zap restart' |
| 16:57.23 | jpeeler | right, but we're trying to restore functionality here |
| 16:57.37 | jpeeler | oh i didn't realize you were the original author |
| 16:58.01 | jpeeler | so it is bad to require all devices using dahdi to be hang up for a restart to complete or not? |
| 16:58.05 | jpeeler | seems like it is |
| 16:58.52 | jpeeler | but i'm having difficulty in the case of when congestion has occurred and executing in the ss_thread is waiting in dahdi_wait_event |
| 16:58.58 | tzafrir_laptop | that's how it works - reconfigures them. I can't think of a better way to do that right now |
| 16:59.03 | Corydon76-lap | jpeeler: I think it depends on the channel types involved |
| 16:59.31 | Corydon76-lap | Like tzafrir said, if it's analog, no restart is needed |
| 16:59.48 | Corydon76-lap | or rather, no downing of all the channels is needed |
| 17:00.34 | tzafrir_laptop | jpeeler, "reload" would work for simpler things. |
| 17:00.35 | jpeeler | i'm saying that i'm having trouble not hanging up all the analog channels |
| 17:01.07 | tzafrir_laptop | and doesn't hang up anything |
| 17:01.36 | Corydon76-lap | it used to be if you ran 'ztcfg', it would hangup all the channels |
| 17:02.14 | Cresl1n | I think that's because it would cause the spans to go into alarm |
| 17:03.07 | jpeeler | specifically my problem is the ioctl call to DAHDI_IOMUX waits for an event and i can't find a clean way of generating an event so that the channel will hangup |
| 17:04.40 | jpeeler | or instead of requiring all analog devices be hung up, i could just put in a sleep which seems to work |
| 17:06.51 | tzafrir_laptop | right. A "sleep" there indeed worked :-( |
| 17:07.18 | jpeeler | my code works without the sleep, but not well in the case of congestion |
| 17:07.23 | jpeeler | and i haven't even tested PRI yet |
| 17:07.24 | jpeeler | tzafrir_laptop: if i put my code in a branch would you take a look at it? |
| 17:07.55 | tzafrir_laptop | with pri there is also the problem that chan_dahdi doesn't really know how to close a D channel |
| 17:08.08 | jpeeler | oh yuck |
| 17:08.09 | tzafrir_laptop | jpeeler, sure |
| 17:09.13 | jpeeler | let me clean it up a bit and i'll ping you with the location |
| 17:21.54 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 17:27.57 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 17:36.24 | JunK-Y | i noticed with the get_ilbc_source.sh , when doing wget -P codecs/ilbc http://www.ilbcfreeware.org/documentation/extract-cfile.awk , that file is in dos format and need to perform a dos2unix with centos 4.6, that should be a good idea if the ilibcfreeware put that file on the right mode. |
| 17:44.56 | seanbright | JunK-Y: that should be fixed already |
| 17:47.13 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.115.150) |
| 17:47.33 | JerJer | is someone motivating 1.4.21.1 to asterisk.org? |
| 17:48.19 | russellb | motivating? |
| 17:48.35 | JerJer | no linkage |
| 17:48.59 | russellb | it's there |
| 17:49.00 | russellb | refresh |
| 17:49.21 | Qwell | the mirroring is a bit silly at times |
| 17:49.24 | jpeeler | tzafrir_laptop: ping, http://svn.digium.com/svn/asterisk/team/jpeeler/dahdi-restart |
| 17:49.27 | seanbright | JunK-Y: in 1.4 and in trunk that get_ilbc_source.sh script handles the DOS line endings correctly... what version are you looking at? |
| 17:49.52 | JerJer | russellb: not seeing it at this point - will give it a while |
| 17:50.09 | tzafrir_laptop | jpeeler, ok. Will look at it later today |
| 17:50.26 | Qwell | stuff gets cached or something.. logging it uses the master server, which makes it show up for you |
| 17:50.27 | jpeeler | tzafrir_laptop: appreciate it |
| 17:50.31 | Qwell | logging in, rather |
| 17:52.02 | putnopvut | "You just got saved from your life possibly sucking" |
| 17:52.07 | putnopvut | That's my kind of warning. |
| 17:52.27 | JunK-Y | seanbright: i was looking in 1.4.21 |
| 17:52.54 | seanbright | JunK-Y: ah. i guess it got fixed too late. |
| 17:53.10 | jpeeler | putnopvut: lol |
| 17:53.29 | Qwell | hey tzafrir_laptop, I'm looking in tools/Makefile, at the kernel/xpp/README.Astribank.html target... |
| 17:53.46 | Qwell | tzafrir_laptop: can you explain what $(@D) and the likes are doing? never seen that syntax.. |
| 17:53.46 | JunK-Y | seanbright: its different in branch 1.4 |
| 17:54.11 | Qwell | cd $(@D); $(ASCIIDOC) -o $(@F) -n -a toc -a toclevels=4 $(<F) |
| 17:54.29 | seanbright | JunK-Y: right. the one in the 1.4 branch takes the \r\n into account |
| 17:55.07 | Cresl1n | russellb: so far so good still |
| 17:55.09 | Cresl1n | 5000 calls |
| 17:55.31 | Qwell | actually, that target wouldn't be valid anymore - it's looking at kernel/, which isn't in tools/ |
| 17:56.16 | Qwell | (along with several other targets in there) |
| 17:56.23 | tzafrir_laptop | Qwell, this is the directory part of $@ . ${@F} is the file-name part |
| 17:56.35 | Qwell | neat - is that GNU make syntax? |
| 17:56.39 | tzafrir_laptop | yes |
| 17:56.46 | Qwell | what about $(<F) ? |
| 17:56.51 | Qwell | oh, nevermind |
| 17:56.57 | Qwell | file part of $< |
| 17:57.01 | JunK-Y | seanbright: yay |
| 18:00.04 | file | runs off |
| 18:03.29 | *** join/#asterisk-dev alexandrekeller (n=Alexandr@189.26.178.61.adsl.gvt.net.br) |
| 18:03.57 | alexandrekeller | does anyone hav implemented a queue through two ou more servers, like a distribute Queue? |
| 18:05.34 | alexandrekeller | or know how to do it? |
| 18:07.49 | jsmith | alexandrekeller: This channel is for Asterisk developers to discuss the source code for Asterisk. I suggest you ask in #asterisk or on the asterisk-users mailing list |
| 18:08.24 | alexandrekeller | sorry....anyone has any idea about it over there...sorry....thanks |
| 18:08.28 | *** part/#asterisk-dev alexandrekeller (n=Alexandr@189.26.178.61.adsl.gvt.net.br) |
| 18:09.22 | seanbright | jsmith: you are such a stern task master |
| 18:10.09 | jsmith | seanbright: That's right! I'm evil... just ask file. |
| 18:10.23 | file | you are not evil |
| 18:10.28 | file | Sokol is evil |
| 18:11.39 | jsmith | file: What does that make me? |
| 18:11.46 | file | Jared. |
| 18:11.48 | jsmith | doesn't want to know the answer to that question |
| 18:12.35 | file | hugs jsmith |
| 18:20.01 | *** join/#asterisk-dev gitguy (n=diego@adsl-133-186.click.com.py) |
| 18:20.03 | gitguy | hi |
| 18:20.09 | gitguy | http://www.digium.com/elqNow/elqRedir.htm?ref=http://downloads.digium.com/pub/asterisk/releases/asterisk-1.4.21.1.tar.gz |
| 18:20.12 | gitguy | the link is broken |
| 18:20.46 | gitguy | there is no file yet |
| 18:22.42 | jsmith | Oh russellb... |
| 18:23.16 | file | The person you are trying to reach is currently unavailable. |
| 18:26.06 | gitguy | waiting... |
| 18:27.14 | seanbright | gitguy: for what? |
| 18:27.36 | jsmith | seanbright: for the tarball to hit the download server |
| 18:27.41 | gitguy | there is no asterisk-1.4.21.1.tar.gz |
| 18:27.53 | seanbright | ahhh |
| 18:28.00 | seanbright | it'll get there |
| 18:28.01 | gitguy | sorry if i'm beign annoying |
| 18:28.02 | seanbright | keep your pants on |
| 18:28.16 | gitguy | thx |
| 18:31.28 | gitguy | res_telepathy? |
| 18:32.01 | gitguy | http://telepathy.freedesktop.org/ ? |
| 18:33.02 | seanbright | gitguy: try this... |
| 18:33.05 | jsmith | gitguy: No, res_telepathy as in "Asterisk can read your mind" |
| 18:33.28 | gitguy | hm |
| 18:33.30 | seanbright | while 1; do wget "http://downloads.digium.com/pub/asterisk/asterisk-1.4.21.1.tar.gz"; sleep 1; done |
| 18:33.51 | *** join/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 18:33.51 | gitguy | lol |
| 18:34.06 | gitguy | that will probably saturate the server |
| 18:34.39 | seanbright | well the other option... and call me crazy... is |
| 18:34.41 | gitguy | there is no file yet |
| 18:34.41 | gitguy | :( |
| 18:34.46 | seanbright | svn co http://svn.digium.com/view/asterisk/tags/1.4.21.1/ asterisk-1.4.21.1 |
| 18:35.39 | gitguy | git > svn |
| 18:35.39 | seanbright | then you can tar -czf asterisk-1.4.21.1.tar.gz asterisk-1.4.21.1/ |
| 18:35.55 | seanbright | and then you can turn around and unpack it |
| 18:36.02 | gitguy | ok |
| 18:36.07 | seanbright | just a thought |
| 18:36.19 | gitguy | what about the rest of the people |
| 18:36.20 | gitguy | omg |
| 18:36.25 | gitguy | they wont be able to update |
| 18:36.32 | seanbright | good point |
| 18:36.36 | jsmith | gitguy: Settle down... the tarball will be on the download server shortly |
| 18:36.40 | seanbright | i don't care about the rest of the people |
| 18:36.43 | gitguy | jsmith: coooool |
| 18:36.47 | seanbright | i care about you, gitguy. |
| 18:36.54 | gitguy | :D |
| 18:37.18 | seanbright | that's not true, actually. |
| 18:37.20 | seanbright | goes to smoke |
| 18:37.26 | gitguy | :( |
| 18:39.24 | gitguy | tell freeswitch people to stfu |
| 18:41.42 | gitguy | they keep trolling |
| 18:42.39 | jsmith | gitguy: Well, everybody wants to tell you that their baby is cuter than anyone elses... My advice is find a baby you think is cutest, and stick with it until something cuter comes along. |
| 18:45.39 | gitguy | asterisk is cute |
| 18:47.04 | gitguy | they keep telling me it has "broken core" |
| 18:47.32 | gitguy | and that is only a "proof of concept" thing now |
| 18:47.33 | gitguy | :( |
| 18:48.11 | seanbright | i haven't kicked anyone from this channel yet (besides myself that once) |
| 18:48.18 | *** kick/#asterisk-dev [seanbright!n=russell@asterisk/developer-and-stable-maintainer/drumkilla] by russellb (gtfo!) |
| 18:48.23 | russellb | download fixed |
| 18:48.26 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 18:48.26 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 18:48.29 | russellb | our mirroring sucks |
| 18:48.29 | russellb | :( |
| 18:48.32 | gitguy | russellb: cool thx man |
| 18:48.33 | *** kick/#asterisk-dev [russellb!n=sean@asterisk/contributor-and-bug-marshal/seanbright] by seanbright (but there is a first time for everything!) |
| 18:48.36 | gitguy | updating now |
| 18:48.38 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 18:48.38 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 18:48.45 | *** mode/#asterisk-dev [-o seanbright] by russellb |
| 18:48.50 | seanbright | :) |
| 18:48.59 | *** mode/#asterisk-dev [+o seanbright] by russellb |
| 18:49.04 | seanbright | i forgive you. |
| 18:49.05 | seanbright | heh |
| 18:49.20 | gitguy | i don't trust what otehrs say but it pisses me off |
| 18:49.36 | russellb | O.O |
| 18:51.26 | gitguy | asterisk rules |
| 18:51.53 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 18:52.32 | seanbright | technically, it rulez |
| 18:53.00 | seanbright | asterisk > freeswitch |
| 18:53.18 | gitguy | k, i just updated it |
| 18:53.35 | gitguy | yeah!! f*** fs |
| 18:53.42 | jsmith | gitguy: To be 100% honest, Asterisk isn't perfect, and has some warts. But what keeps me excited about Asterisk is the amount of development that goes into it. It may not be perfect *today*, but it's certainly got the momentum to overcome a lot of obstacles |
| 18:53.56 | seanbright | blinks |
| 18:53.59 | putnopvut | I've never used FreeSwitch so I can't really comment on it. |
| 18:54.00 | ctooley | russellb, just to be certain, 1.4.21.1 includes your deadlock fix? |
| 18:54.06 | russellb | yes. |
| 18:54.09 | seanbright | did you just say it that asterisk "isn't perfect?" |
| 18:54.12 | Qwell | ctooley: that's the only difference |
| 18:54.20 | gitguy | jsmith: cooool |
| 18:54.26 | gitguy | jsmith: yeah |
| 18:54.38 | russellb | seanbright: have you seen the lock discussion? "locking is broken and there is practically no way to fix it." |
| 18:54.40 | codefreeze-lap | Corydon76-dig: Corydon76-lap: Just did the svn update thing, and reran tests; no, there is no diff in slowdown |
| 18:54.46 | gitguy | jsmith: evolution > good design |
| 18:54.55 | Corydon76-lap | codefreeze-lap: okay |
| 18:54.59 | putnopvut | russellb: where's that quote from? |
| 18:55.25 | ctooley | I've found that neither FS or Asterisk are perfect, and I choose to work on Asterisk purely out of laziness to "learn something new" and having not run into a problem which FS would actually do a better job of. |
| 18:55.25 | russellb | that was my cynical and not quite true summary of -dev |
| 18:55.26 | russellb | :-p |
| 18:55.43 | seanbright | russellb: well right, but other than that, it's perfect. |
| 18:55.49 | Qwell | Asterisk locking is perfect. It's gcc's fault for not being able to optimize it right. |
| 18:56.33 | seanbright | well, as with all things asterisk, it is *DIGIUM'S* responsibility to fix it |
| 18:56.40 | seanbright | man up! |
| 18:56.40 | *** kick/#asterisk-dev [seanbright!n=russell@asterisk/developer-and-stable-maintainer/drumkilla] by russellb (russellb) |
| 18:56.44 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 18:56.44 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 18:56.47 | seanbright | jeez |
| 18:56.51 | russellb | :D |
| 18:56.59 | seanbright | sets mode +SenseOfHumor on russellb |
| 18:57.08 | russellb | you're unfortunately right about that being a common attitude |
| 18:57.39 | russellb | sets mode -SenseOfHumor on russellb |
| 18:57.43 | ctooley | locks are broken in Asterisk purely because they're the wrong thing to use. Locks go on doors, Asterisk, being more of a gate(way), needs to use latches. Much cheaper, easier to work with, and fewer things to mess up. |
| 18:57.45 | putnopvut | device state in app_queue makes me sad. |
| 18:58.19 | seanbright | putnopvut: time to rewrite |
| 18:58.21 | jsmith | app_queue in general makes me sad |
| 18:58.22 | seanbright | putnopvut: annnnnnnnnnnnnnd GO |
| 18:58.25 | ctooley | latch(): somewhat like a lock in that appears to prevent access while latched, but providing no actual protection. |
| 18:58.28 | jsmith | But you already knew that... |
| 18:58.29 | gitguy | what was fixed with 1.4.21.1, a lock? |
| 18:58.35 | seanbright | gitguy: deadlock |
| 18:58.36 | Qwell | gitguy: yes |
| 18:58.41 | gitguy | nice |
| 18:58.41 | russellb | a lock, yes, something like that |
| 18:59.40 | gitguy | maybe this lock fixed this? http://bugs.digium.com/view.php?id=12810 |
| 18:59.48 | seanbright | ctooley: like flock()? |
| 19:00.09 | Qwell | gitguy: nope, that bug was only in 1.4.21 |
| 19:00.29 | ctooley | seanbright, flock sounds like something rather inappropriate |
| 19:00.35 | seanbright | heh |
| 19:00.40 | Qwell | ctooley: You're thinking FLICK() |
| 19:00.45 | gitguy | k |
| 19:01.00 | Qwell | gitguy: unless you posted the wrong version number on this bug |
| 19:01.21 | Qwell | if so, then...probably. try it |
| 19:01.23 | ctooley | f-lock() sounds like something outlawed in more conservative states. |
| 19:01.46 | seanbright | flock(2) places advisory locks only; given suitable permissions on a file, a process is free to ignore the use of flock(2) and perform I/O on the file. |
| 19:01.54 | Qwell | ctooley: my joke doesn't make as much sense if your font is serif |
| 19:02.12 | Qwell | my joke only makes sense in non-fixed width, sans-serif |
| 19:02.16 | russellb | gitguy: your comments are welcome on my blog, but you have _got_ to stop trolling |
| 19:02.25 | russellb | gitguy: "this sucks, asterisk fucking sucks" |
| 19:02.44 | ctooley | Qwell, I got the joke |
| 19:02.48 | russellb | don't bite the hand that feeds you. |
| 19:02.51 | gitguy | russellb: sorry |
| 19:02.55 | putnopvut | Qwell: who uses that sort of font on IRC? |
| 19:03.14 | russellb | and that wasn't the first one of that kind of thing from you |
| 19:03.15 | Qwell | putnopvut: Windows users. |
| 19:03.23 | russellb | please stop. |
| 19:03.38 | russellb | all it does is piss me off and put me in a bad mood |
| 19:03.39 | gitguy | ok |
| 19:04.40 | seanbright | wow, your blog's comment volume = gitguy |
| 19:08.18 | seanbright | goes home. |
| 19:08.47 | russellb | looks at the clock |
| 19:09.05 | Qwell | russellb: he's a windows dev. they go in at like 4am |
| 19:09.10 | russellb | oh, right |
| 19:09.16 | russellb | because they're not actually human |
| 19:09.20 | russellb | they're droids |
| 19:11.45 | seanbright | got to work at 6am |
| 19:11.54 | seanbright | really goes away now |
| 19:11.58 | Qwell | see? :D |
| 19:13.40 | jpeeler | M11189 |
| 19:13.44 | MuffinMan | [assigned] [Asterisk] Channels/chan_zap 0011189: chan_zap causing reset on E1 and eventually crashed asterisk reported by freon1 (Karma: neutral) http://bugs.digium.com/view.php?id=11189 |
| 19:13.51 | jpeeler | i'm about to start work on this issue, but the guy had a kernel oops |
| 19:14.05 | jpeeler | have dahdi drivers ever caused that to happen? |
| 19:14.16 | russellb | yes |
| 19:14.37 | jpeeler | sounds like some fun debugging then, will continue then |
| 19:16.55 | *** join/#asterisk-dev hubguruJR (n=hubguruJ@mail.ntegratedsolutions.com) |
| 19:17.34 | codefreeze-lap | Hmmmm! I found something! At last! Removing one line of code brings down the pthread_create() time to 250 usec from 500-1700 usec. Total pbx_start() time to 600 usec (roughly) from 14-50k usec. But the ramifications.... ugh. |
| 19:18.06 | putnopvut | Don't leave us in suspense! |
| 19:18.20 | Cresl1n | russellb: 14848 calls processed on your locking fix |
| 19:18.29 | russellb | yay |
| 19:18.38 | Qwell | codefreeze-lap: what was the line? |
| 19:18.47 | Cresl1n | System uptime: 3 hours, 4 minutes, 2 seconds |
| 19:19.08 | codefreeze-lap | Hold on, guys, let me check out my logs and I'll be right back... |
| 19:25.10 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 19:31.43 | Corydon76-lap | pokes codefreeze-lap |
| 19:35.08 | Cresl1n | is codefreeze-lap murf? |
| 19:35.15 | putnopvut | Cresl1n: yes sir! |
| 19:35.19 | Cresl1n | good job murf |
| 19:35.30 | Cresl1n | hunting down all these inefficiencies |
| 19:36.07 | ctooley | awaits codefreeze-lap's results impatiently. :) |
| 19:36.15 | Cresl1n | sits on the edge of his seat |
| 19:36.49 | putnopvut | Yeah, I just want to know what the one line was... |
| 19:36.53 | russellb | no kidding |
| 19:36.58 | russellb | pulls it up to try to guess |
| 19:37.08 | Corydon76-lap | coats the edge of Cresl1n's seat with white grease |
| 19:37.11 | putnopvut | ast_random_delay(ast_random()); |
| 19:37.12 | Cresl1n | heh |
| 19:37.21 | Cresl1n | that's kind of redundant |
| 19:37.26 | russellb | increase_call_count? hmm |
| 19:37.54 | putnopvut | Cresl1n: the argument is whether to actually delay or not. |
| 19:38.04 | Cresl1n | oh, ok :-) |
| 19:38.06 | Cresl1n | not so redundant then |
| 19:38.09 | Cresl1n | but almost |
| 19:38.46 | Cresl1n | a very random chance of either delaying or not delaying, dependent on the interpretation of the parameter |
| 19:39.19 | russellb | pokes codefreeze-lap 100 times |
| 19:39.42 | ctooley | blocks all 100 pokes. Don't distract him, it'll only make things slower. |
| 19:39.46 | Corydon76-lap | ast_pthread_create(&thr, NULL, use_random_amounts_of_CPU, NULL) |
| 19:39.48 | Cresl1n | heh :-) |
| 19:39.54 | ctooley | :) |
| 19:40.16 | Cresl1n | switches all his code back to normal pthread_create calls |
| 19:40.37 | Corydon76-lap | Cresl1n: #undef pthread_create |
| 19:40.54 | russellb | actually ... |
| 19:41.16 | russellb | #define pthread_create __use_ast_pthread_create_instead__ |
| 19:42.34 | russellb | i guess the line he removed was ... ast_pthread_create |
| 19:42.55 | Cresl1n | that might do it |
| 19:43.18 | putnopvut | we may never know. |
| 19:43.32 | putnopvut | stares toward wyoming |
| 19:43.46 | Cresl1n | maybe the ether lost his packets |
| 19:43.58 | russellb | the voice under his IP went out :( |
| 19:44.41 | Cresl1n | IP over voice |
| 19:44.48 | Cresl1n | that sounds bizarre |
| 19:44.53 | russellb | VuIP |
| 19:44.55 | Cresl1n | SYN |
| 19:45.02 | Qwell | Cresl1n: dialup internet :D |
| 19:45.04 | russellb | SYN+ACK |
| 19:45.06 | Cresl1n | oooh |
| 19:45.18 | russellb | Qwell: heh, that's one way :) |
| 19:45.25 | Cresl1n | that's a valid situation where the voice under the IP could actually go out |
| 19:45.28 | russellb | probably more efficient than me yelling the bits |
| 19:45.31 | Cresl1n | +1 to Qwell |
| 19:45.40 | Qwell | russellb: wireless |
| 19:45.45 | Qwell | IP over wireless voice. |
| 19:46.18 | putnopvut | I would be curious what a wired voice is. |
| 19:46.25 | Qwell | a phone line |
| 19:46.46 | putnopvut | since when is a phone line a voice? |
| 19:46.58 | Cresl1n | a modem's like a voice |
| 19:47.01 | Cresl1n | it's voice band |
| 19:47.22 | Cresl1n | in my book, that's ip over voice |
| 19:47.22 | russellb | according to his post on -dev, it appears to be logging ... |
| 19:47.31 | Cresl1n | silly logging |
| 19:47.40 | putnopvut | I have not gotten that message. |
| 19:47.43 | russellb | even though i don't see any log messages ... |
| 19:47.49 | russellb | waits for codefreeze-lap to come back |
| 19:48.06 | ctooley | you don't want to know the IP over Voice that wwalker just implemented using Asterisk. |
| 19:48.36 | russellb | modem over SIP/RTP? |
| 19:48.49 | russellb | let's recursively encapsulate data! |
| 19:48.56 | Cresl1n | russellb: over modem |
| 19:49.03 | Cresl1n | modem over SIP/RTP over modem |
| 19:49.05 | Qwell | over ATM |
| 19:49.06 | Cresl1n | that's the way to go |
| 19:49.08 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 19:49.22 | Cresl1n | I heard everybody's doing it |
| 19:49.33 | ctooley | data via DTMF over a voice call |
| 19:49.46 | Cresl1n | ctooley: that's so last week |
| 19:49.47 | ctooley | actually, not even really dtmf, they're single tones |
| 19:49.52 | Qwell | morse code |
| 19:49.57 | russellb | that's ... probably the slowest modem ever |
| 19:49.58 | ctooley | something like that. |
| 19:50.03 | ctooley | 8 bit/sec |
| 19:50.17 | Cresl1n | more than that |
| 19:50.21 | Cresl1n | 16 possible values |
| 19:50.36 | Cresl1n | per key |
| 19:50.41 | Qwell | not real dtmf though |
| 19:50.44 | russellb | if you use dtmf, yeah |
| 19:50.49 | Cresl1n | ~50 ms per digit |
| 19:50.56 | russellb | 4 bits per digit ... |
| 19:51.14 | Cresl1n | 20 * 4 bits per digit = 80 bits per second |
| 19:51.16 | russellb | w00t |
| 19:51.17 | Cresl1n | not terrible |
| 19:51.18 | Cresl1n | :-) |
| 19:51.20 | Qwell | just use dtmf as hex.. encode the binary |
| 19:51.26 | Cresl1n | hello toll bypass |
| 19:51.38 | russellb | Qwell: that doesn't get you any bettter, heh |
| 19:51.45 | Qwell | shut up |
| 19:51.47 | Qwell | :p |
| 19:53.36 | russellb | who's going to write the dialplan to send/recv arbitrary (small chunks of) data using DTMF @ 80bits/sec? |
| 19:53.37 | russellb | :) |
| 19:54.15 | russellb | Cresl1n: we'll need a CRC :-p |
| 19:54.26 | Cresl1n | it'll eat into our payload bandwidth a bit |
| 19:54.28 | Qwell | pfft, data integrity |
| 19:54.33 | russellb | nods |
| 19:54.34 | Cresl1n | we'll just to big data frames |
| 19:54.37 | Cresl1n | *do |
| 19:54.46 | russellb | CRC for 10 seconds of data? |
| 19:54.48 | russellb | heh |
| 19:54.51 | Cresl1n | heh :-) |
| 19:54.53 | russellb | sucks when you have to retransmit |
| 19:55.00 | Cresl1n | or we could use kevin's md5sum idea |
| 19:55.05 | russellb | oh, right |
| 19:55.10 | Qwell | Cresl1n: ooo |
| 19:55.14 | russellb | i've been working on that database ... not done yet |
| 19:55.14 | Qwell | that would be fast. how big is an md5? |
| 19:55.16 | Cresl1n | and use DTMF to transport the MD5sum itself |
| 19:55.37 | Corydon76-lap | Qwell: 32char hex |
| 19:55.49 | Qwell | how many seconds would it take to transmit that? |
| 19:55.52 | Corydon76-lap | 24char base64 |
| 19:55.55 | Cresl1n | we could do that in 1.5 seconds |
| 19:55.57 | Corydon76-lap | 16char binary |
| 19:55.58 | Qwell | sweet |
| 19:56.14 | Qwell | sends Cresl1n a movie in 1.5s, at 80bit/s |
| 19:56.34 | Cresl1n | 's database just blew up |
| 19:56.34 | Corydon76-lap | Oh, you want base 14, then, for DTMF |
| 19:56.44 | Qwell | *# |
| 19:56.52 | wwalker | ctooley: my one way 4 baud 8bps modem is a secret! I'm planning on patenting the data only moves one way part. |
| 19:57.06 | Corydon76-lap | You're not going to use * and # for data synchronization? |
| 19:57.50 | Cresl1n | psssh |
| 19:57.56 | Cresl1n | data synchronization |
| 19:58.02 | Qwell | Cresl1n: can a dtmf detector pickup multiple dtmfs played simultaneously? |
| 19:58.10 | Cresl1n | no, it shouldn't |
| 19:58.15 | Qwell | I guess, if you used a different part of the table |
| 19:58.19 | Cresl1n | it probably "could", but it shouldn't |
| 19:58.21 | Qwell | you could play a third tone as a CRC |
| 19:58.29 | Cresl1n | the same software has to be run anyway to detect all of them |
| 19:58.40 | wwalker | Corydon76-lap: no DTMF. single tones only, because every provider distorts DTMF in a different way making it totally unreliable for the client (he is injecting the tones inband) |
| 19:59.01 | Cresl1n | oh yeah, and we have to do all this over g.729 with DTMF inband gusy |
| 19:59.03 | Cresl1n | *guys |
| 19:59.13 | Corydon76-lap | wwalker: so clearly, you need the message in morse code. |
| 19:59.16 | Cresl1n | and with rfc2833 turned on, even though it's not actually being used |
| 19:59.23 | Corydon76-lap | Luckily, we have just such an application already |
| 19:59.49 | Corydon76-lap | sets DITLEN to 5ms |
| 20:02.01 | Corydon76-lap | Cresl1n: we need a Morse code detector for the other side |
| 20:02.11 | Cresl1n | starts writing some code |
| 20:02.25 | Cresl1n | app_morsecodedetector_withmagictips |
| 20:02.25 | Corydon76-lap | Cresl1n: and then if we use two different tones, we can have full-duplex transmissions... |
| 20:03.37 | Corydon76-lap | Say, 450Hz and 800Hz |
| 20:03.52 | Cresl1n | we should probably use some components of the DTMF tones |
| 20:03.58 | Cresl1n | not valid components |
| 20:04.05 | Cresl1n | like two row frequencies or something |
| 20:04.18 | Corydon76-lap | I meant in opposite directions |
| 20:04.31 | Cresl1n | they picked them deliberately so that there would be minimal spectral harmonics between them |
| 20:04.35 | Cresl1n | understand |
| 20:04.52 | Corydon76-lap | 450 and 800 shouldn't conflict too much |
| 20:05.09 | Corydon76-lap | It's not like using 220 and 440 |
| 20:05.19 | Cresl1n | heh |
| 20:06.26 | Cresl1n | 450 and 800 it is then |
| 20:07.22 | Corydon76-lap | Cresl1n: have you messed with app_morsecode yet? |
| 20:07.28 | Cresl1n | not really |
| 20:07.55 | Corydon76-lap | I'm serious... I wrote it so that everything is controlled by the variable DITLEN |
| 20:08.13 | Corydon76-lap | and everything should be exactly to spec for the lengths of both DIT and DAH |
| 20:08.28 | Corydon76-lap | as well as the timing between characters |
| 20:09.20 | Corydon76-lap | should be possible to start up with absolutely no training... just analyse the first 500ms or so to detect DITLEN, then go back to that 500ms and interpret the message |
| 20:10.26 | Corydon76-lap | so a slight delay at the beginning, but it catches up immediately |
| 20:13.16 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 20:13.16 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 20:23.45 | *** join/#asterisk-dev anthm (n=anthm@mbb0736d0.tmodns.net) |
| 20:24.57 | *** part/#asterisk-dev hubguruJR (n=hubguruJ@mail.ntegratedsolutions.com) |
| 20:32.12 | russellb | codefreeze-lap: you are such a tease |
| 20:33.20 | Cresl1n | maybe he patched the wrong part of the universe |
| 20:33.29 | Cresl1n | got a universe panic and had to reboot |
| 20:34.35 | bkruse | Cresl1n: I have when that happens :/ |
| 20:34.48 | Cresl1n | me too |
| 20:35.06 | Cresl1n | last time it happened to me, they called it "the big bang" |
| 20:37.12 | jpeeler | when is libpri going to make the dahdi transition? |
| 20:39.49 | Corydon76-lap | jpeeler: I wasn't aware that libpri needed any changes... |
| 20:40.00 | jpeeler | maybe it doesn't? |
| 20:40.12 | Qwell | it does (did?) include zaptel.h or something |
| 20:40.22 | jpeeler | yeah it does |
| 20:40.22 | seanbright | offers codefreeze-lap $10 to come back |
| 20:40.26 | Corydon76-lap | Weird, why? |
| 20:40.36 | Qwell | or maybe that was libss7 |
| 20:40.52 | jpeeler | it's in pridump.c |
| 20:41.08 | Corydon76-lap | Oh, for debugging |
| 20:43.04 | jpeeler | switches back to zaptel :( |
| 20:46.36 | russellb | how about just fix it |
| 20:46.43 | russellb | it's a 1 line fix or whatever |
| 20:47.08 | jpeeler | fix just locally? |
| 20:47.24 | russellb | might as well commit |
| 20:47.29 | russellb | i can't see a reason why not |
| 20:47.34 | Qwell | it's gonna have to work with both zaptel and dahdi, no? |
| 20:47.38 | jpeeler | no supporting both? |
| 20:48.40 | russellb | meh, Cresl1n can make that call |
| 20:49.35 | Cresl1n | I switched libss7 over to DAHDI on saturday night |
| 20:50.02 | russellb | but that's only supported in trunk/1.6 |
| 20:50.03 | Cresl1n | goes to look at libpri |
| 20:50.06 | Cresl1n | yes |
| 20:50.12 | russellb | libpri affects 1.4, as well, which for asterisk, supports both |
| 20:50.15 | russellb | hence the dilemma |
| 20:50.15 | russellb | :) |
| 20:50.24 | Cresl1n | which is understandable |
| 20:50.49 | Cresl1n | 25546 calls processed |
| 20:51.00 | Cresl1n | that's for you russellb |
| 20:54.57 | Cresl1n | actually, pridump is not too important |
| 20:55.04 | Cresl1n | I don't know if anyone actually uses it |
| 20:55.06 | Cresl1n | ponders |
| 20:55.23 | ctooley | Cresl1n, make it something they have to manually turn on. :) |
| 20:55.40 | Cresl1n | it's something that no one turns on anyways |
| 20:55.43 | Cresl1n | it's a separate app |
| 20:56.30 | ctooley | yay, unimportant. |
| 20:56.49 | ctooley | never uses pridump and so assumes it's not required. :) |
| 20:57.30 | Cresl1n | there are other problems though with some of the test programs |
| 20:57.44 | russellb | as long as it doesn't cause the build to fail |
| 20:57.48 | russellb | i.e., don't build it by default |
| 20:58.40 | Cresl1n | I'm thinking we're safe as far as that goes |
| 20:59.27 | Cresl1n | I wonder if murf gets GPRS out where he is |
| 21:00.12 | Qwell | does murf even get cell signal out where he is? :p |
| 21:06.53 | *** part/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 21:07.05 | codefreeze-lap | Cresl1n: Qwell: the answers are No, I don't get gprs out here, and No, I don't really get cell signal at all out here. From a certain spot in the house, I can make and get calls if I stay far enough away from the phone. I can sit down in one spot in the front yard and get and make marginal calls. |
| 21:07.29 | ctooley | ack! after all that, that's the question he answers? |
| 21:07.38 | ctooley | :) |
| 21:08.43 | russellb | removes codefreeze-lap |
| 21:08.46 | codefreeze-lap | Oh, yes, you guys are still in suspense, are you? Well, I'm posting the answers, starting now. See the asterisk-dev mailing list, and svn commits to mtprof. We're zeroing in on the problem, methinks. |
| 21:11.14 | codefreeze-lap | and, as a teaser: yes, it seems to end up a locking issue! |
| 21:11.29 | codefreeze-lap | There went the letter |
| 21:11.42 | Qwell | checks his mail in 90 minutes, to read it, once it arrives |
| 21:13.58 | *** join/#asterisk-dev bkruse (n=bkruse@216.207.245.1) |
| 21:13.58 | *** mode/#asterisk-dev [+o bkruse] by ChanServ |
| 21:14.50 | codefreeze-lap | and there went the commit |
| 21:16.51 | putnopvut | codefreeze-lap: I like your #defines... |
| 21:16.56 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 21:18.50 | ctooley | worries irrationally over the proposed solution. |
| 21:20.07 | ctooley | codefreeze-lap, so.... uhhh.... if we don't lock this channel, what would I expect to see if that caused it to break something? |
| 21:20.20 | ctooley | I'm guessing a segfault, but I'm not sure. |
| 21:21.08 | codefreeze-lap | Well, the biggest thing I've found so far is it locks up when you do a "stop gracefully" |
| 21:21.39 | codefreeze-lap | putnopvut: yes, nice #defines, eh? :D |
| 21:22.11 | codefreeze-lap | BTW, the commenting out of the lock & unlock in chan_sip really is the juicy part of the commit. |
| 21:22.31 | ctooley | codefreeze-lap, I'm just taking wild guesses here, but if we don't lock the thread, there's the potential for us to step on other things. |
| 21:22.59 | ctooley | so.... if we go long enough, we might run into a problem, though I am in no way sure how. |
| 21:24.21 | codefreeze-lap | ctooley: the change points out the problem; but it probably isn't the best way to solve it. |
| 21:24.55 | putnopvut | codefreeze-lap: by the way, I just thought I'd point out that that lock is also in 1.4 |
| 21:25.17 | ctooley | codefreeze-lap, I have a break in load testing for Griffin, perfect time for me to slam a couple million calls through the mtxprof branch |
| 21:27.49 | codefreeze-lap | Oh, and sent the letter, but it hasn't appeared yet in asterisk-dev; I'll resend if I don't see it in a while... the juicy part there is that pbx_start() times go from 53.7 msec (worst case in my data) to .5 msec (best case)... and .7 msec (worst case)... not a bad difference! |
| 21:28.30 | ctooley | oh, I got it already |
| 21:28.36 | codefreeze-lap | (and those include a 2 or 3 ast_log statements) |
| 21:29.11 | ctooley | saw it before the message that you had committed. |
| 21:29.25 | codefreeze-lap | Wow, you must be closer to the head of the list than I! |
| 21:29.52 | snuff-home | just cheated... went to the webpage archive of ast-dev |
| 21:30.10 | ctooley | shrugs |
| 21:30.26 | codefreeze-lap | shrugs too |
| 21:31.03 | snuff-home | maybe ur email provider is holding up the email |
| 21:31.38 | ctooley | ARGH! menuselect no longer works |
| 21:31.48 | snuff-home | hehe... i found that too ctooley |
| 21:31.56 | Qwell | 1.4? |
| 21:31.57 | snuff-home | u should use.. make cmenuselect |
| 21:32.03 | ctooley | that segfaults. :( |
| 21:32.13 | snuff-home | mm doesn't for me |
| 21:32.30 | snuff-home | if i now just do make menuselect it defaults to gtk.. not happy jan |
| 21:32.54 | ctooley | fixed |
| 21:33.14 | ctooley | yeah, I wasn't thrilled about the whole gtk bit either. |
| 21:33.36 | ctooley | but, I fixed cmenuselect at least. |
| 21:33.41 | snuff-home | :) |
| 21:33.50 | snuff-home | time to ready self for work |
| 21:36.24 | *** join/#asterisk-dev techie (n=techie@m150e36d0.tmodns.net) |
| 21:50.49 | ctooley | well... its.... better. |
| 21:51.01 | ctooley | logging might be too much for it at this point. |
| 21:51.32 | ctooley | can't get over 100cps |
| 21:56.06 | codefreeze-lap | ctooley: 100 cps with that huge amount of logging? Wow! Tell you what; I'll conditionalize all the logging on MTX_PROFILE or something, so you can make it go away... how's that? |
| 21:56.34 | ctooley | codefreeze-lap, like I said, logging might be a bit much. :) |
| 21:56.55 | ctooley | though... I wonder, I should be able to just comment out those two lines on trunk, correct? |
| 21:56.58 | ctooley | same diff. |
| 21:57.30 | ctooley | BTW, runs just beautifully at 100cps if I stay there. |
| 21:57.51 | codefreeze-lap | ctooley: a **bit** much? :) And, yes, you could comment out those two statements on trunk; (4 lines, actually) |
| 21:57.52 | snuff-home | mm.. if the logging is excessive.. put the logs on tempfs :P |
| 21:59.35 | ctooley | as soon as I jump to 110 cps, it starts getting behind, I have to go back to 90cps just to get it to slowly catch back up. |
| 22:00.51 | codefreeze-lap | ctooley: try it w/o the logging. You should be able to get somewhat higher numbers... I hope. How many cps can you get out of 1.4? |
| 22:01.22 | ctooley | codefreeze-lap, between 200 and 250 |
| 22:02.10 | codefreeze-lap | Well, the trunk improvements were 4x at one point; so 800-1000 is the target. |
| 22:02.57 | ctooley | don't say that out loud, my boss might see it. |
| 22:03.13 | codefreeze-lap | looks both ways |
| 22:12.08 | *** join/#asterisk-dev RoyK (n=roy@ip-196-62-149-91.dialup.ice.no) |
| 22:34.49 | codefreeze-lap | dang. 250 calls and I hit the "too many open files" wall again. Thought we got rid of that... |
| 22:35.10 | ctooley | codefreeze-lap, ulimit |
| 22:35.16 | codefreeze-lap | but I did get rid of all the debugs. |
| 22:35.39 | ctooley | I got up to 130 stable and 140 we start getting behind. |
| 22:36.12 | codefreeze-lap | if 1024 == 250 calls; that 8096k = 2k calls, total before I have probs. |
| 22:36.19 | codefreeze-lap | not good. |
| 22:36.38 | codefreeze-lap | 130 is better, but, some other prob is now biting us, then! |
| 22:37.12 | Corydon76-lap | seanbright: ping |
| 22:44.35 | ctooley | codefreeze-lap, definitely better |
| 22:48.54 | seanbright | Corydon76-lap: pong |
| 23:02.30 | Corydon76-lap | seanbright: on your private branches, please set automerge-email |
| 23:03.17 | seanbright | Corydon76-lap: will do |
| 23:03.45 | seanbright | sorry about that. do you get the bounces? |
| 23:04.11 | Corydon76-lap | We get notifications when automerge fails |
| 23:04.15 | seanbright | gotcha |
| 23:04.25 | Corydon76-lap | and two of your private branches have been failing |
| 23:05.00 | Corydon76-lap | Of course, if you don't need them anymore, you could just delete them |
| 23:05.48 | seanbright | i do need them, actually. |
| 23:13.51 | *** join/#asterisk-dev jcollie (n=jcollie@fedora/jcollie) |
| 23:39.15 | codefreeze-lap | Corydon76-lap: I'm seeing the "Too many open files" again, after 250 calls.... |
| 23:39.47 | *** join/#asterisk-dev isamar (i=1000@voice.maxirede.net) |
| 23:39.58 | *** part/#asterisk-dev isamar (i=1000@voice.maxirede.net) |