Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's this bit of code:

    while(GetMessage(&msg, NULL, 0, 0) > 0)  
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
The mouse isr would cause a loop like this to execute at some point, processing all the messages on the queue. Win95 had preemption, but it ran at 100hz. Moving the mouse caused additional queue processing on top of the time sliced preemption.


I thought the windows clock defaulted to ~60Hz. I understand it could be pushed up by software to 1Khz for audio players to work correctly. I may be very wrong on the latter point though.


At that time, it was more like the 75mhz range.


Note he said 100hz not mhz. Essentially 100 times per second the message queue would process but if you moved the mouse it would process faster.


And the BSDs and Linux also have the HZ parameter for scheduling and for a long time the default has been as low as 100 Hz.

Not sure what the current status quo is.


Linux's default varies per architecture & platform. For a long, long time on ARM it still defaulted to 100hz. I think it's more like 250hz or 500hz now? You'll also see x86 desktop-focused build set it to 1000hz.

But scheduling happens far more often than this tick rate, too, so it's only preemption for busy threads and controls the timing windows for things like DVFS.


For FreeBSD it's been 1000 for... ages, except for virtual machines, where it seems to be 100 by default.


Some guides for better battery life on FreeBSD recommend setting it to 100 Hz.


Tickless




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: