11.5.3.1. Request to schedule in the past?!?!
1) Mar 11 12:38:04 NOTICE[1204820784]: sched.c:218 sched_settime: Request to schedule in the past?!?!
2) NOTICE[1100258240]: res_musiconhold.c:260 monmp3thread: Request to schedule in the past?!?!
If you know of any other possible reason and of course solution, please post them here.
If you are getting messages such as the one above, then there could be two reasons (or at least these are the known)
1. Check your CPU usage If your machine is heavily loaded, this could be one of the reasons.
Probably the reason is that the thread could not complete a task fast enough because of the lack of system resources.
It seems that this is not a crucial error, but it could make the audio streams to get choppy.
So what could you do? Upgrade you machine. Although, there are no standard minimum requirements to run Asterisk, we recommend you to use at least 500MHz 256RAM, but remember. We are using 800MHz, 256 RAM for testing and so far it works without this message.
However, the lack of system resources is not the only reason. The message could appear even on 2.5Ghz machines. So let's check the other reason.
Probably the reason is that the thread could not complete a task fast enough because of the lack of system resources.
It seems that this is not a crucial error, but it could make the audio streams to get choppy.
So what could you do? Upgrade you machine. Although, there are no standard minimum requirements to run Asterisk, we recommend you to use at least 500MHz 256RAM, but remember. We are using 800MHz, 256 RAM for testing and so far it works without this message.
However, the lack of system resources is not the only reason. The message could appear even on 2.5Ghz machines. So let's check the other reason.
2. May be the system clock and the hardware clock are drift out of synch.
Rebooting the machine has to sync the two clocks. However, obviously this is not the best solution. So you could use NTP servers to sync your time up, which is the more often used practice.
In any cases in is a good idea to sync up the clocks on your Asterisk servers, PCs and hardphones.
Rebooting the machine has to sync the two clocks. However, obviously this is not the best solution. So you could use NTP servers to sync your time up, which is the more often used practice.
In any cases in is a good idea to sync up the clocks on your Asterisk servers, PCs and hardphones.
2) NOTICE[1100258240]: res_musiconhold.c:260 monmp3thread: Request to schedule in the past?!?!
As you could see this one is related to music on hold.
The sound become very choppy, slow, even metallic
The sound become very choppy, slow, even metallic
1. The reason could be in the mpg123 package. It has a bug that prevents it from freeing up memory that it no longer needs. This is the so called memory leak. What actually happen is that the program steals more and more memory and finally the system will crashes, because the lack of memory.
Possible solution is to use the Native Asterisk format_mp3 for the Music on Hold instead of mpg123
The format_mp3 comes with the asterisk-addons package. Also if you decide to use it, first be sure that you have been removed mpg123 from your system.
Other options is to use rawplayer instead of mpg123.
Rawplayer is a simple replacement, which could be used to stream raw music files, in place of the mpg123
It is the most efficient way to implement Music On Hold, because it does not have the problem with the memory leaking
Rawplayer comes with the asterisk package
Installing rawplayer
* go to asterisk source dir and then to 'contrib/utils/' and compile the player
o gcc -O2 rawplayer.c -o /usr/bin/rawplayer
+ This will compile and install rawplayer at /usr/bin
* edit /etc/asterisk/musiconhold.conf and change
o default => custom:/var/lib/asterisk/mohraw,/usr/bin/rawplayer
+ in /var/lib/asterisk/mohraw we will store raw MOH files
For the converting of the files we will use sox
* convert MP3 to RAW
o sox -c 1 filename.mp3 -t raw -r 8000 -c 1 -s -w filename.raw
* copy RAW file to mohraw dir
o cp filenam.raw /var/lib/asterisk/mohraw
Possible solution is to use the Native Asterisk format_mp3 for the Music on Hold instead of mpg123
The format_mp3 comes with the asterisk-addons package. Also if you decide to use it, first be sure that you have been removed mpg123 from your system.
Other options is to use rawplayer instead of mpg123.
Rawplayer is a simple replacement, which could be used to stream raw music files, in place of the mpg123
It is the most efficient way to implement Music On Hold, because it does not have the problem with the memory leaking
Rawplayer comes with the asterisk package
Installing rawplayer
* go to asterisk source dir and then to 'contrib/utils/' and compile the player
o gcc -O2 rawplayer.c -o /usr/bin/rawplayer
+ This will compile and install rawplayer at /usr/bin
* edit /etc/asterisk/musiconhold.conf and change
o default => custom:/var/lib/asterisk/mohraw,/usr/bin/rawplayer
+ in /var/lib/asterisk/mohraw we will store raw MOH files
For the converting of the files we will use sox
* convert MP3 to RAW
o sox -c 1 filename.mp3 -t raw -r 8000 -c 1 -s -w filename.raw
* copy RAW file to mohraw dir
o cp filenam.raw /var/lib/asterisk/mohraw
2. Other possible reason for the message Request to schedule in the past?!?! could be a timing issue, as a Zaptel timing issue.
Especially if you want to use MeetMe with Music On Hold you will need a timing source, regardless of the kernel.
If you do not use Digium hardware and you are using kernel earlier then 2.6, you need to have either ztdummy or zaprtc module running.
If you are using kernels 2.6.x and up, the ztdummy module will use the processor as a timing source
If you use Digium hardware, then you do not need ztdummy or zaprtc module.
Especially if you want to use MeetMe with Music On Hold you will need a timing source, regardless of the kernel.
If you do not use Digium hardware and you are using kernel earlier then 2.6, you need to have either ztdummy or zaprtc module running.
If you are using kernels 2.6.x and up, the ztdummy module will use the processor as a timing source
If you use Digium hardware, then you do not need ztdummy or zaprtc module.
If you know of any other possible reason and of course solution, please post them here.
| Add Comment |
Latest Headlines:
-
T.38 faxing with Zoiper 2.15 is now easier than ever
section: voip software
-
Asterisk 1.4.21 Released
section: Asterisk
-
Asterisk 1.4.20 Released
section: Asterisk
-
Asterisk 1.4.20-rc2 Released
section: Asterisk
-
Asterisk 1.4.20-rc1 Now Available
section: Asterisk
- News Archives (older news)
Latest Tutorials:
-
Sending Fax from Zoiper to Zoiper using T.38
added 08/Dec/2008 18:16
-
VMAuthenticate (dialplan application)
added 01/Mar/2008 15:57
-
Siptronic ST-530
added 06/Nov/2007 17:57
-
Siemens C455 IP hardphone
added 05/Nov/2007 10:24
-
Zoiper
added 22/Oct/2007 17:53
Latest Comments:
-
nice...
tutorial: X-Lite - SIP softphone
-
Badly need your help. Things are only im...
tutorial: Grandstream HandyTone-486 - SIP Analog Telephone Adapter (ATA)
-
how do i rectify this problem? all incom...
tutorial: Troubleshooting
-
How are you. Summer afternoon - Summer a...
tutorial: Cisco 7960 IP Phone - SIP firmware version
-
where is the tar file you mention above ...
tutorial: Cisco 7960 IP Phone - SIP firmware version