| 01:36.52 | *** join/#asterisk-dev eliel (~eliels@186.18.108.106) |
| 01:36.52 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 01:50.01 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 01:50.01 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 02:15.06 | *** join/#asterisk-dev pabelanger_ (~pabelange@CPE0013f7abc09a-CM0013f7abc096.cpe.net.cable.rogers.com) |
| 07:18.00 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:18.00 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:12.32 | *** join/#asterisk-dev drachenfels2 (~king@91.142.34.51) |
| 12:13.13 | drachenfels2 | anyone about today |
| 12:18.30 | tzafrir | infobot, tell drachenfels2 about ask |
| 12:18.59 | tzafrir | drachenfels2, I suppose rob is not here |
| 12:24.46 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:24.46 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:36.33 | kpfleming | Corydon76-dig: how are things up your way right now? we've just got a large amount of wind, no rain |
| 12:49.52 | snuff-home | morning kp |
| 12:53.09 | kpfleming | morning |
| 12:53.20 | kpfleming | how is your sunday evening? |
| 12:54.49 | snuff-home | not bad.. got a cat for lap warmer |
| 12:56.07 | file | bazinga! |
| 12:57.20 | snuff-home | so anyone have fun stuff planned for the sunday? |
| 12:57.43 | kpfleming | our plans are to avoid the damaging winds and 6" of rain that are expected |
| 12:58.15 | file | I plan on mowing my lawn |
| 12:58.25 | snuff-home | ah.. more storms.. |
| 12:58.58 | kpfleming | yes, nashville to the north of us had major flooding yesterday |
| 12:59.19 | snuff-home | mm.. mowing lawns.. depends how much there is to count if its 'fun' in any sense.. |
| 13:00.26 | kpfleming | file: youtube videos work on my laptop now after the reinstall |
| 13:00.37 | file | kpfleming: ooh yay |
| 13:03.50 | kpfleming | and i could swear my laptop feels dramatically more responsive |
| 13:03.58 | kpfleming | i don't know how that could be true, but it sure feels that way |
| 13:05.08 | drachenfels2 | I'm trying to troubleshoot a problem with the scheduler which might be related to a number of bugs. Does anyone know what the correct behaviour of the scheduler should be. With DUMP_SCHDULER turned on, I'm seeing entried like this: [May 2 04:12:42] DEBUG[7327] sched.c: |3044 | 0x241e19 | 0xc618410 | -000019 : 481171 | |
| 13:05.18 | drachenfels2 | i.e. run 19 seconds ago..? |
| 13:05.27 | snuff-home | its funny how OS re-installs make it 'feel' like that ;) |
| 13:06.02 | drachenfels2 | why on earth would the schduler not be running this task? |
| 13:06.04 | kpfleming | yeah, i used to experience that all the time with Windows, but this is Ubuntu |
| 13:06.29 | snuff-home | newer version of ubuntu? |
| 13:06.32 | snuff-home | 10.04 lts? |
| 13:08.44 | drachenfels2 | Looking at the code, I can see that the task schduler is using calls to ast_tvnow(), is this accurate enough? |
| 13:10.44 | drachenfels2 | I can think of various things that might cause tasks to not run, e.g. running ntpd on the server could cause schduler to mess up, if running in Virtual env, this could cause problems as well. |
| 13:11.01 | kpfleming | snuff-home: yep |
| 13:11.28 | kpfleming | drachenfels2: ast_tvnow() returns time in milliseconds... accuracy should not be an issue |
| 13:11.59 | drachenfels2 | but ast_tvnow is making a call to gettimeofday |
| 13:12.18 | kpfleming | it could be that the thread that is supposed to watching that scheduler queue is no longer running, or is blocked, or something, so nothing is checking the list that includes that scheduler item |
| 13:12.20 | drachenfels2 | which means that if the clock on the computer moves around too much, it would completely mess up the schduler code |
| 13:12.28 | kpfleming | that is correct |
| 13:12.39 | snuff-home | well.. 9.10 wasn't exactly super stable / fast... intel video driver saga... |
| 13:12.58 | kpfleming | i have wanted to replace that with a tick counter for a long time... but at least it could be switched to CLOCK_MONOTONIC, which would avoid the issue |
| 13:13.06 | kpfleming | snuff-home: 9.10 was very good for me, never had any serious issues |
| 13:13.47 | snuff-home | they did concentrate on boot speed in 10.04.. my fav linux related news site.. phoronix.com :) |
| 13:15.14 | drachenfels2 | I was just about to suggest a monotonic clock |
| 13:15.39 | kpfleming | yes, unfortunately there arent any truly portable monotonic clock sources |
| 13:16.29 | kpfleming | but there is one on Linux, which is a start at least, and i'm sure other platforms have something similar |
| 13:17.12 | kpfleming | well, actually CLOCK_MONOTONIC is part of Posix Realtime, so maybe it's more widely supported than i thought |
| 13:17.34 | drachenfels2 | During the times that the timer is going negative on some of the scheduled items, I can see multiple calls to run the queue, but they items don't seem to be getting executed... |
| 13:18.32 | drachenfels2 | So the queue item should be getting run, but it's not... |
| 13:19.45 | drachenfels2 | I can't see any locks that would prevent it running. |
| 13:19.47 | kpfleming | keep in mind that there is not just one scheduler queue |
| 13:19.59 | kpfleming | many modules have one |
| 13:20.37 | kpfleming | so you have to look at the 'context' value of the entry to know which module created it, assuming you have tracked the context pointers created by the various modules |
| 13:25.48 | snuff-home | has anyone played with new virtualbox 3.2 beta? |
| 13:29.10 | drachenfels2 | hmm, ok, didn't realise this. |
| 13:46.26 | drachenfels2 | The problem I'm trying to troubleshoot is that for some reason, a few extensions qualifies just stop.. and don't restart until the box receives a register from the device again. |
| 13:49.00 | kpfleming | you mean device qualify... there is no extension qualify |
| 13:49.37 | kpfleming | that could indicate that the registration has expired, and so chan_sip has intentionally 'forgotten' where the device is located |
| 13:49.45 | drachenfels2 | yes, device qualify |
| 13:50.42 | kpfleming | if you do a 'sip show peer' that peer while it is in that state, does it show a remote IP/port number for the peer? |
| 13:50.47 | drachenfels2 | but the queue items i've been talking about going negative, are for the device qualify scheduled items |
| 13:51.08 | drachenfels2 | no it says unknown |
| 13:51.14 | drachenfels2 | 0 |
| 13:51.26 | kpfleming | well, it can't send a quality to a peer that it doesn't have an address for |
| 13:51.39 | kpfleming | so the scheduler item you are seeing is probably a leftover that should have been removed |
| 13:53.04 | kpfleming | and now i need to eat breakfast and read the newspaper... good luck :-) |
| 13:55.34 | file | lawn mowing completed, at least the parts I can mow without potentially losing my feet |
| 14:18.02 | drachenfels2 | Right, I can see that the sip_queue is running |
| 14:18.04 | drachenfels2 | [May 2 15:11:13] DEBUG[23318] sched.c: ============================================================= |
| 14:18.05 | drachenfels2 | [May 2 15:11:13] DEBUG[23318] sched.c: |ID Callback Data Time (sec:ms) | |
| 14:18.05 | drachenfels2 | [May 2 15:11:13] DEBUG[23318] sched.c: +-----+-----------------+-----------------+-----------------+ |
| 14:18.05 | drachenfels2 | [May 2 15:11:13] DEBUG[23318] sched.c: |1448 | 0x1afe19 | 0xb751a380 | -000027 : 589093 | |
| 14:18.15 | drachenfels2 | [May 2 15:11:13] NOTICE[23318] chan_sip.c: chan_sip: running sip queue |
| 14:18.15 | drachenfels2 | [May 2 15:11:13] DEBUG[23318] sched.c: ast_sched_runq(&con->schedq_ht:) |
| 14:18.15 | drachenfels2 | [May 2 15:11:13] DEBUG[23318] sched.c: time of callback id:1448 1272809473:357302 |
| 14:18.15 | drachenfels2 | [May 2 15:11:13] DEBUG[23318] sched.c: end time of callback id:1448 1272809473:357342 |
| 14:18.15 | drachenfels2 | [May 2 15:11:13] DEBUG[23318] sched.c: END ast_sched_runq() |
| 14:18.53 | drachenfels2 | [May 2 15:11:12] NOTICE[23318] chan_sip.c: chan_sip: running sip queue |
| 14:18.54 | drachenfels2 | [May 2 15:11:12] DEBUG[23318] sched.c: END ast_sched_runq() |
| 14:19.19 | drachenfels2 | But why didn't the item get run on the call at 15:11:12 ? |
| 14:23.38 | kpfleming | look at the time in the entry |
| 14:23.45 | kpfleming | -27 seconds plus 589093 milliseconds |
| 14:23.58 | kpfleming | 589093 milliseconds is 589 seconds |
| 14:24.37 | kpfleming | if that's accurate, the scheduler entry is not due to run for a long time |
| 14:25.11 | kpfleming | now... the time in the scheduler entry should have been normalized so it wouldn't look like that, but the result is the same either way |
| 14:26.00 | drachenfels2 | but it does, ay 15:11:13 |
| 14:26.06 | drachenfels2 | ay =at |
| 14:26.21 | kpfleming | umm... that's not what i was talking about |
| 14:26.42 | kpfleming | the Time column in the scheduler entry shows when it is due to be run |
| 14:28.34 | drachenfels2 | with you on that, the time entry is in seconds and micro seconds |
| 14:28.50 | drachenfels2 | not milliseconds |
| 14:29.04 | kpfleming | ahh... it should be labeled as 'us' then |
| 14:29.12 | kpfleming | that's a but |
| 14:29.19 | kpfleming | s/but/bug/ |
| 14:29.34 | kpfleming | so... i have no explanation for you then |
| 14:29.44 | kpfleming | you might be best to bring this up tomorrow, when there will be a lot more developers around |
| 14:31.28 | drachenfels2 | k, thanks for your help |
| 15:16.03 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 15:56.50 | Corydon76-dig | kpfleming: Yesterday, we had more rain than is normal for the entire summer |
| 15:57.10 | kpfleming | yeah, i saw the pictures on facebook |
| 15:58.06 | Corydon76-dig | Oh, and as for the closest named creek... Mill Creek... records go back to the 1930s |
| 15:58.30 | Corydon76-dig | The level now IS the record |
| 16:00.14 | kpfleming | we have been told to prepare for major rain here too, but nothing so far |
| 16:02.43 | Corydon76-dig | http://www.facebook.com/group.php?gid=115531931813861#!/group.php?gid=115531931813861&v=photos |
| 16:03.00 | Corydon76-dig | A group of amateur photos of the floods in TN |
| 16:09.37 | *** join/#asterisk-dev drachenfels (~king@91.142.34.1) |
| 17:59.25 | *** join/#asterisk-dev pabelanger_ (~pabelange@CPE0013f7abc09a-CM0013f7abc096.cpe.net.cable.rogers.com) |
| 18:17.00 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 18:31.18 | *** join/#asterisk-dev jmls (~jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 19:17.48 | *** join/#asterisk-dev eliel (~eliels@186.18.108.106) |
| 19:17.48 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 19:36.13 | *** join/#asterisk-dev atis_work (~atis_work@193.238.212.171) |
| 22:04.20 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 22:04.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:31.34 | *** join/#asterisk-dev jameswf (~james@unaffiliated/jameswf-home) |
| 22:34.00 | *** join/#asterisk-dev frawd (~francois@193.153.19.72) |
| 22:35.49 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-101-155-51.cinci.res.rr.com) |
| 22:42.01 | *** join/#asterisk-dev JT (~j@unaffiliated/jt) |