(!) timer drift -- spun 3 minutes

EEggy · Post by **EEggy** » Sat Apr 05, 2003 9:46 pm

Hi,
is there any way to findout what's causing this msg? in the partyline
(!) timer drift -- spun 3 minutes
because i have 2 bots, same version, same scripts
one bot is fine, but 2nd shows this msgs in the partyline.

Thanks

Post by **caesar** » Sun Apr 06, 2003 4:56 am

Look at this topic.

EEggy · Post by **EEggy** » Tue Apr 08, 2003 10:36 pm

Hi, thanks for the reply, but is there anyway to resolve this?? because its affecting on the bot performance and causing the bot a bit slow.. and it shows average 0ver 16 times a day, some time 3 mintues, sometime 2 mintues, sometime 6 mintues....

then i had started a testbot without any scripts, and it showed up as well.

i'll apprecite for the help, and i am sure solution will help someother users as well.

thanks

ppslim · Post by **ppslim** » Wed Apr 09, 2003 4:47 am

There is nothing you can do, other that upgrade the system the bot is on.

Timer drift is caused by the bot not performing operations at its normal rate.

This can be caused by scripts blocking the bot (IE, not continueing until a script is complete, EG, FTP ifo requests, http downloads). Other reasons include the bot not getting enough CPU time to complete a job.

Normaly, it is down to the CPU time and memory (low memory causes swap disk to be used, this can be time and CPU consuming process to perform).

Dereckson · Post by **Dereckson** » Sat Apr 12, 2003 4:58 am

When you change the time of a computer hosting an eggdrop, you get a timer drift spun (but in common, 58 minutes).

So, on a server with instable electrical connexion frenquentily updated with the value returned by a NTP server, this line is very current.

DayCuts · Post by **DayCuts** » Tue Aug 24, 2004 5:12 pm

Dereckson, any chance you could expand a little on that, or anybody else.

I get the '(!) timer drift -- spun 58 minutes' message from time to time, there is no patturn to it and it can happen at any time of the day. I know this is not a problem with a process hogging script or such. As the scripts were wrote by myself with the very implicit intention to keep them simply and fast.

Could somebody please expand on this. I do not ever change the time on the system, and it is not set to use daylight savings (it does not alter for this). Although the system is only a 466mhz w/ 320mb sdram, this setup is more than enough for what is run on it.

So, on a server with instable electrical connexion frenquentily updated with the value returned by a NTP server, this line is very current.

What exactly does this mean? (the instable electrical connexion part)

I dont care about seind the msg, but i have a script that performs a small maintenance check every 20-30 minutes, and spits a line to the consol, when i get the timer spun message, it will initial the proc (called by timer) twice at the same time, which is undesirable.

TIA

awyeah · Post by **awyeah** » Tue Aug 24, 2004 10:06 pm

This problem has been described in the eggdrop.*****.tar.gz package itself.

(!) timer drift -- spun N minutes

This can be caused by one of several reasons.

- Your bot could have been swapped out of memory for a while, or for
some reason the computer could have stopped letting the bot run. Once
a minute, Eggdrop does a few maintenance things, including counting
down any active Tcl timers. If for some reason, several minutes pass
without Eggdrop being able to do this, it logs this message to let
you know what happened. It's generally a bad thing, because it means
that the system your bot is on is very busy, and the bot can hardly
keep track of the channel very well when it gets swapped out for
minutes at a time.

- On some systems (at least Linux), if the DNS your bot is using to
lookup hostnames is broken and *very* slow in responding (this can
occur if the DNS server's uplink doesn't exist), then you will get
4-5 minute timer drifts continuously. This can be fixed by loading
the dns module.

- The clock on your machine has just been changed. It may have been
running behind by several minutes and was just corrected.

Take a look at any of the file:

eggdrop\doc\weird-messages.txt
eggdrop\doc\html\app-weird.html

I suggest, you run both bots from seperate directories.

make install DEST=/home/usr/eggdrop1
make install DEST=/home/usr/eggdrop2

DayCuts · Post by **DayCuts** » Wed Aug 25, 2004 2:07 am

I read that in another thread here and in the package to see if there was any extra, but i dont see how any of them seem to apply to me. And since dereckson specifically mentioned the 58 minutes with there alternate explanation i thought maybe they could expand or be a little clearer on the issue. In any case i guess it really doesn't matter, one var and if statement would take care of the script issue caused, it would just be preferable not to have to use one. Oh, and im only running on bot for that box.

egghead · Post by **egghead** » Wed Aug 25, 2004 10:45 pm

DayCuts wrote:I read that in another thread here and in the package to see if there was any extra, but i dont see how any of them seem to apply to me. And since dereckson specifically mentioned the 58 minutes with there alternate explanation i thought maybe they could expand or be a little clearer on the issue. In any case i guess it really doesn't matter, one var and if statement would take care of the script issue caused, it would just be preferable not to have to use one. Oh, and im only running on bot for that box.

You may also get the problem if the eggdrop uses a blocking operation. Such as writing to a file for a while.

DayCuts · Post by **DayCuts** » Thu Aug 26, 2004 6:15 am

egghead, that is what the timer calls.... it calls a maintenance and backup procedure, which performs a quick regex search to strip out bad entries then re-writes the variable list to file. It is just one simple regex search and then the write to file using 'puts $xpf [join $xpl "\n"]'.

This procedure it called and run every half an hour, and takes about half a second to complete. Could this really be causing such a large timer drift? 48times at day at 0.5 seconds, thats about 24seconds. Could that really somehow cause a 58 minute drift?

If so is there some alternative to my proc, the list is generally about 300 in length. I thought 'puts $xpf [join $xpl "\n"]' was pretty quick and basic, would be suprised if such a short write to file really caused such a large drift.