Timers Are System Clock-dependent
Warning! This is the old Hercules bugtracker archive, and may not reflect the current state of Hercules. The current bugtracker is on GitHub Issues.
Issue information
Issue ID
#240
Status
Fixed
Severity
Critical
Started
Hercules Elf Bot
Oct 17, 2007 9:22
Last Post
Hercules Elf Bot
Oct 17, 2007 9:22
Confirmation
Hercules Elf Bot - Oct 17, 2007 9:22
Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=240
eAthena's timers advance by retrieving the new 'tick' value from the system and comparing it against the existing value.
On Windows, code that explicitly requests it using GetTickCount() - tick being the number of ms since system start.
On Unix, the 'tick' is derived from the return value of gettimeofday() - tick being the number of miliseconds since 1970, wrapped around 32bit.
The unix approach is defective because it's based on the notion of 'system time'. If you adjust the system time, you adjust the return value.
This will cause the timers to jump forward or even into the past, which is highly undesirable and cannot be compensated for properly.
Windows does not suffer from this problem beacause the "system start" time is a fixed reference point.
Both systems still need a way to guard against timer wraparound, which occurs every ~50 days due to 32bit integer capacity.
Attached is a simple example for Windows that shows what happens to the counter if you manipulate the system time.
This anomaly can lead to server crashes or freezes; on my server with an optime ~2 months, all existing mobs' AI stopped (the mobs just stood there, letting themselves get beaten up). This was FreeBSD.
This is not unrealistic; many OSes have builtin periodic time synchronization. I've got a periodic daily cron job that does "ntpdate pool.ntp.org" for example.
NOTE: the socket engine uses time() instead of asking the tick code. This introduces the abovementioned anomaly on windows as well.
EDIT: Heh... my Opera browser froze when I moved system time back and forwards QQ
This post has been edited by theultramage: Oct 17 2007, 02:27 AM
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=240
eAthena's timers advance by retrieving the new 'tick' value from the system and comparing it against the existing value.
On Windows, code that explicitly requests it using GetTickCount() - tick being the number of ms since system start.
On Unix, the 'tick' is derived from the return value of gettimeofday() - tick being the number of miliseconds since 1970, wrapped around 32bit.
The unix approach is defective because it's based on the notion of 'system time'. If you adjust the system time, you adjust the return value.
This will cause the timers to jump forward or even into the past, which is highly undesirable and cannot be compensated for properly.
Windows does not suffer from this problem beacause the "system start" time is a fixed reference point.
Both systems still need a way to guard against timer wraparound, which occurs every ~50 days due to 32bit integer capacity.
Attached is a simple example for Windows that shows what happens to the counter if you manipulate the system time.
This anomaly can lead to server crashes or freezes; on my server with an optime ~2 months, all existing mobs' AI stopped (the mobs just stood there, letting themselves get beaten up). This was FreeBSD.
This is not unrealistic; many OSes have builtin periodic time synchronization. I've got a periodic daily cron job that does "ntpdate pool.ntp.org" for example.
NOTE: the socket engine uses time() instead of asking the tick code. This introduces the abovementioned anomaly on windows as well.
EDIT: Heh... my Opera browser froze when I moved system time back and forwards QQ
This post has been edited by theultramage: Oct 17 2007, 02:27 AM
Attached File(s)
