| 00:27.32 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 00:27.32 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 01:43.38 | *** join/#asterisk-dev droemel (~droemel@p4FCAD195.dip.t-dialin.net) |
| 02:48.56 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 02:58.41 | *** join/#asterisk-dev tonylyliu (~tonylyliu@183.3.153.248) |
| 04:02.56 | Juggie | jmls, was cel ever finished? |
| 06:10.46 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 06:10.47 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 06:30.10 | jmls | Juggie: unsure about what you mean |
| 06:30.33 | jmls | finished by digium ? Not sure - docs are not entirely accurate :) |
| 06:49.19 | snuff-work | cel was put out... not too many using that u hear of |
| 07:11.35 | jmls | apparently ;) |
| 07:57.47 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:57.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:04.20 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 08:27.20 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:c9ac:e6a4:80f3:9b7b) |
| 10:32.51 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 10:36.09 | bombev | hi all :) I have problem with skype for asterisk, the call goes to wrong route... |
| 10:43.43 | snuff-home | i thought skype for ast was discontinued.. |
| 10:43.53 | snuff-home | aka m$ kiboshed it |
| 10:44.36 | bombev | PLEASE NOTE: Skype for Asterisk is no longer available for sale. Skype for Asterisk will be supported for two more years, until July 26, 2013. |
| 10:44.51 | bombev | I think I can use skype until 2013 |
| 10:45.33 | snuff-home | mm.. also may be that skype upgraded their protocol to foil it sooner? |
| 10:47.04 | bombev | hm if is that true.. |
| 10:47.53 | snuff-home | isnt skype user |
| 10:48.28 | bombev | this is my asterisk log |
| 10:48.28 | bombev | http://pastebin.ca/2250922 |
| 10:49.17 | bombev | actually the skype call getting in into the phone server |
| 11:24.37 | *** join/#asterisk-dev weinerk (~user@unaffiliated/weinerk) |
| 11:25.30 | *** part/#asterisk-dev weinerk (~user@unaffiliated/weinerk) |
| 13:59.33 | seanbright | rmeyerriecks: you're a dahdi guy yeah? |
| 13:59.46 | file | he is |
| 14:00.29 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-yeyygrsnpfmcamfa) |
| 14:00.31 | seanbright | just upgraded ubuntu lucid to 2.6.32-45 and it seems to break timing |
| 14:01.35 | seanbright | running 'timing test' from the asterisk CLI spews out "poll() timed out! This is bad." |
| 14:01.42 | seanbright | rolling back to -44 seems to resolve it |
| 14:01.50 | seanbright | not sure if you have seen this in your dev/testing |
| 14:07.12 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:07.13 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:31.11 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-gdjpflyhzbycrleg) |
| 14:31.11 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:38.10 | *** join/#asterisk-dev serafie1 (~erin@76.73.167.231) |
| 14:41.15 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 15:02.11 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 15:02.11 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:18.46 | rmeyerriecks | seanbright: That's correct |
| 15:20.55 | seanbright | rmeyerriecks: did you see my messages relating to lucid's latest kernel update? |
| 15:21.12 | seanbright | i am in the process of setting up a test machine to test dahdi-linux trunk to make sure i'm not wasting your time |
| 15:23.17 | rmeyerriecks | seanbright: oh, huh |
| 15:23.45 | rmeyerriecks | seanbright: how is your timing configured? |
| 15:24.27 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:24.43 | seanbright | res_timing_dahdi with the dahdi kernel module |
| 15:24.53 | seanbright | no hardware timing |
| 15:26.00 | seanbright | we're running 2.6.0 everywhere in production, so i'm building a test machine to test 2.6.1 and HEAD to make sure it's actually a problem and that simply updating won't fix it |
| 15:26.04 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:26.23 | seanbright | wasn't expecting anyone to look into it, was just hoping that you had seen it before |
| 15:27.15 | rmeyerriecks | seanbright: I have not, doesn't mean it's not a legit bug though |
| 15:28.44 | seanbright | rmeyerriecks: in their changelog for -45 it looks like some changes were made to epoll |
| 15:29.00 | seanbright | let me test and i'll submit a bug if it's actually a bug |
| 15:29.32 | rmeyerriecks | seanbright: was this a distro kernel update, or did you roll your own? |
| 15:29.39 | seanbright | distro update |
| 15:30.01 | rmeyerriecks | seanbright: released recently? |
| 15:31.54 | seanbright | ummm |
| 15:33.26 | seanbright | 11/08 |
| 15:33.31 | seanbright | nov 8 |
| 15:42.13 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-mnwcgnxralfgjxyj) |
| 15:50.07 | putnopvut | seanbright: curious, does res_timing_timerfd also fail the timing test? |
| 15:51.36 | seanbright | putnopvut: i'll test that too |
| 15:51.46 | seanbright | this is interesting. dahdi_test output: |
| 15:51.47 | seanbright | Opened pseudo dahdi interface, measuring accuracy... |
| 15:51.48 | seanbright | 4.692% 4.696% 4.691% 4.691% 4.691% 4.691% 4.691% |
| 15:51.49 | seanbright | heh |
| 15:52.11 | seanbright | that is dahdi 2.6.0, testing 2.6.1 now |
| 15:54.24 | seanbright | similar results with 2.6.1 |
| 15:54.49 | rmeyerriecks | seanbright: investigating |
| 15:57.21 | seanbright | rmeyerriecks: dahdi trunk works |
| 15:57.49 | seanbright | so go ahead and release 2.6.2 so i can upgrade :D |
| 15:59.51 | seanbright | actually, i'm basing that on dahdi_test output, not asterisk 'timing test' |
| 15:59.57 | seanbright | let me test with asterisk while i'm at it |
| 16:00.46 | mjordan | opticron: re ASTERISK-20676 |
| 16:01.08 | mjordan | I think at the very least we need to confirm that all of the ways in which we can 'dial' a channel will result in some hangup cause information being tracked |
| 16:04.17 | mjordan | opticron: what would it take to report hangup cause information for a channel with a pbx thread? |
| 16:04.25 | mjordan | regardless of actually dialing |
| 16:06.42 | opticron | that would probably take some kind of filter for frames being passed to the pbx thread (framehooks) |
| 16:06.54 | opticron | attached to every single channel ever |
| 16:07.07 | opticron | that's executing a pbx, anyway |
| 16:08.10 | mjordan | opticron: so say I create a channel and call Dial. How does Dial gather the information for the calling channel currently? |
| 16:09.22 | opticron | dial doesn't, it's the code in channel.c that handles it when the channel claims it can't handle the indication |
| 16:10.09 | opticron | and dial can't appropriately handle it (multiple levels of local channel dials would break it) |
| 16:12.31 | mjordan | Okay. So why would we not trigger that for a given channel that simply hangs up? |
| 16:17.01 | seanbright | putnopvut: to answer your question, no res_timing_timerfd passes with flying colors: |
| 16:17.04 | seanbright | Using the 'timerfd' timing module for this test. |
| 16:17.06 | opticron | local channels never generate the type of information that goes into that dictionary, so that could be part of it |
| 16:17.07 | seanbright | It has been 1000 milliseconds, and we got 50 timer ticks |
| 16:17.33 | putnopvut | seanbright: okay. I just wanted to be sure the problem was localized to res_timing_dahdi and not something more system-wide that we needed to be concerned about. |
| 16:17.38 | putnopvut | thanks for testing |
| 16:21.14 | leifmadsen | seanbright: thanks for turning down the suck |
| 16:23.24 | seanbright | leifmadsen: thanks for your contribution to irrelevance and inanity |
| 16:23.32 | leifmadsen | bows |
| 16:52.21 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:52.21 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:57.41 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-53-120.user.veloxzone.com.br) |
| 17:01.32 | seanbright | rmeyerriecks: i think i found the patch that fixes the problem |
| 17:02.02 | seanbright | but i'm testing to be sure. |
| 17:02.54 | *** join/#asterisk-dev Corydon76-home (eight@c-69-137-80-31.hsd1.tn.comcast.net) |
| 17:02.54 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 17:06.22 | seanbright | rmeyerriecks: ok. 100% sure. r10482 is what fixes the problem for me with the latest ubuntu kernel. |
| 17:06.48 | seanbright | the patch in that commit is not in 2.6.0 or 2.6.1 |
| 17:07.27 | seanbright | which is odd since 2.6.1 (rc1) was tagged some time after it was committed |
| 18:19.57 | seanbright | sruffell: do you maintain a database of specific-hardware-that-has-timing-problems? |
| 18:20.08 | seanbright | like... for fun |
| 18:20.16 | seanbright | heh |
| 18:20.45 | sruffell | no..not really…..most of the problems can be fixed with configuration changes. |
| 18:21.06 | sruffell | like turning off PIO mode on a disk controller, disabling a framebuffer, etc... |
| 18:21.20 | sruffell | removing your HDTV encoder card... |
| 18:21.41 | file | *G* |
| 18:21.57 | seanbright | so with core timing, why would a dell PE 2850 "fire" at 40ms intervals instead of 20ms intervals? |
| 18:22.36 | seanbright | and would wall clock vs monotonic make a difference? |
| 18:23.39 | sruffell | hmm…they should all fire at 4 ms intervals…. |
| 18:23.53 | sruffell | is your "DAHDI_CHUNKSIZE" modified? |
| 18:24.08 | seanbright | would that have to be done at compile time? |
| 18:24.11 | sruffell | yes |
| 18:24.15 | seanbright | then no |
| 18:24.27 | sruffell | does NTP keep accurate time on this server? |
| 18:24.32 | seanbright | ntp isn't running |
| 18:24.52 | sruffell | does the server know how much time is really passing? ie. there isn't a general problem with the clocks on the server? |
| 18:25.12 | seanbright | checks |
| 18:25.12 | sruffell | The coretimer needs an accurate "Wall clock" to function. |
| 18:25.29 | seanbright | does that still apply after r10482? |
| 18:25.47 | sruffell | the monotonic is primarily to prevent problems when the time changes…..since DAHDI doesn't care…it only cares how much time is passing not what the "Real" time is . |
| 18:26.03 | seanbright | the server time seems to be close to what i manually set it to yesterday |
| 18:26.16 | sruffell | yeah, I miss spoke…not really wall clock ..but accurate determination of real time passing. |
| 18:26.28 | seanbright | yeah, i think the clock is keeping up |
| 18:26.29 | sruffell | what is the output of dahdi_test -vvv |
| 18:27.34 | seanbright | http://pastebin.com/raw.php?i=4RkkQGwE |
| 18:29.38 | sruffell | that looks good….so what problem are you seeing? |
| 18:29.50 | sruffell | If it was really firing at 40ms intervals..there would be more jitter than what you're seeing there. |
| 18:30.05 | sruffell | so it's most likely nothing in the kernel... |
| 18:30.06 | seanbright | well i hate to mention it the protocol by name... |
| 18:30.16 | seanbright | (iax2) |
| 18:30.24 | sruffell | think of the children! |
| 18:30.31 | seanbright | it's sending trunk frames every 40ms instead of every 20ms |
| 18:30.46 | sruffell | and only with res_timing_dahdi? res_timing_timerfd doesn't? |
| 18:30.58 | seanbright | haven't tried with res_timing_timerfd |
| 18:31.05 | seanbright | i don't hear good things about it |
| 18:31.16 | sruffell | I would be *very* surprised if dahdi timing is the root cause here... |
| 18:31.22 | seanbright | fair enough |
| 18:32.14 | sruffell | and you really haven't heard good things about res_timing_timerfd? I'm not aware of any issues with the later releases on 1.8... |
| 18:32.35 | seanbright | well, i've heard of more problems with timerfd than dahdi timing |
| 18:32.41 | seanbright | and we've had success with the latter |
| 18:32.48 | sruffell | fair enough. |
| 18:32.50 | sruffell | :) |
| 18:33.20 | seanbright | going to install dahdi linux trunk as a last ditch effort |
| 18:33.38 | seanbright | although if you are correct that won't make a difference |
| 18:33.53 | seanbright | and unfortunately you're usually right |
| 18:33.54 | seanbright | heh |
| 18:34.05 | sruffell | Yeah…and if you want to run a test to convince yourself…one sec.. |
| 18:36.14 | sruffell | in coretimer_init change core_timer.interval to something like HZ/100 (for 10ms intervals) and you should see the jitter go up, but the cummulative still trend towards 99.9%. |
| 18:36.30 | sruffell | to convince yourself that the timer is really firing at 4ms intervals. |
| 18:37.11 | seanbright | will do |
| 18:37.19 | seanbright | for what it's worth, i hope you're wrong |
| 18:37.26 | seanbright | it would make my life easier |
| 18:37.27 | seanbright | :-) |
| 18:37.42 | sruffell | Well…it sounds weird to say I'll cross my fingers for you... |
| 18:38.43 | seanbright | the whole thing is weird. same rev of asterisk with the same patches we install on all servers. |
| 18:38.54 | seanbright | identical config |
| 18:39.05 | file | blames seanbright |
| 18:42.27 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:42.27 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:45.35 | seanbright | sruffell: you know what would help? if i read these pcap files correctly. |
| 18:45.44 | sruffell | doh! |
| 18:46.04 | seanbright | i stole 20 minutes of your life that you will never get back |
| 18:46.27 | file | seanbright, nub level supreme? |
| 18:46.28 | sruffell | eh…I'm "off" today. Schools closed so I'm home with my daughter |
| 18:47.19 | seanbright | if i /ignore someone does that mean they can't see what i type? or just that i can't see what they type? |
| 18:48.21 | Corydon76-home | Just the second. I trust you won't be able to see this, then, though. |
| 18:48.59 | seanbright | don't be silly |
| 18:49.42 | Corydon76-home | That's quite impossible for me. |
| 19:03.22 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:03.22 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:45.33 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 20:45.33 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 21:28.25 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 21:28.26 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:59.24 | mjordan | jsmith: ping |
| 23:29.25 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |