Mike Silbersack wrote:
> On the other hand, a higher HZ should create a system which runs a bit
> smoother for interactive programs. And, as you point out, it is necessary
> for good timing in emulators / simulators / dummynet.
Higher hardclock rate. It affects dummynet because most of the
work it does is at NETISR. Software interrupts run when you splx()
back down from a high SPL to one at or below the software interrupt
priority level. More hardware interrupts equal more software
interrupts, in that case, and so dummynet runs faster. You could
achieve the same effect by running multiple dummynet software
interrupts. The real problem is peristalsis; you want the dummynet
code to run number-of-nodes-along-a-graph-edge number of times per
soft interrupt, rather than just once per. So the same effect would
be to put the soft interrupt routine in an encapsulation "for" loop
with number of nodes on longest edge, plus one. For most dummynet
applications, that's basically adding:
int j;
for( j = 0; j< 4; j++) {
... /* normal dummynet software interrupt code */
}
To the dummynet ISR.
For emulators and simulators, the problem is badly written code,
as I stated previously. Rather than adding a bunch of operations
together to get one big operation, the code should use a single
big operation. Thus the overhead is amortized, and the timer
resolution requirements are significantly reduced.
FWIW, my first X11 game I ever wrote, which was similar to the
game "LodeRunner", used a select() timeout for the timing loop
to ensure smooth game operation.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
