In message <20041122102202.GD6225@drowsy.duskware.de>, Martin Husemann writes:
>On Sun, Nov 21, 2004 at 07:45:45PM -0500, David H. Gutteridge wrote:
>> Moving date forward six months: 26 second freeze
>> Moving date forward one year: 84 second freeze
>> Moving date forward two years: 175 second freeze
>
>Wow, I couldn't believe this - but I can reproduce it on -current.
>
>Please file a PR in the bin category against date(1) - and in the xsrc
>category against X (this is probably a X server bug, since during the freeze
>all X output stalls).
>

I wonder if this is really a bug at all.  Does cron try to catch up?  
An X server is just an application (unlike, say, ping replies or 
console output without X); if it's competing for CPU with other, 
high-priority processes, it's not a surprise that it would freeze.

There may be some component to X itself -- if it's in a select() loop 
trying to make something move smoothly, it may be running through a lot 
of steps catching up to the current time, even if no draw events are 
pending.  But let's try to understand whether or not the CPU is 110% 
busy.  What is the accumulated CPU time of X before and after the change?
What about other processes?  Does lastcomm show anything? 


		--Steve Bellovin, http://www.research.att.com/~smb