Stijn Hoop wrote:
> > Because it measures the API one way, but the code uses it another.
> > The results you get are not predictive of the code that you are
> > going to be running.
>
> But the code is going to use the _sleep functions as used in the benchmark
> -- to sleep for less than 10 ms (which evidently makes no sense on a default
> FreeBSD system, as pointed out by the results).
Actually, the way it was stated, it's my impression that it's dealing
with frame rate, and only sleeping to add intentional delays. This
matches closely what I did with the select timeout in my own games.
In practice, unless the player was doing nothing, then the timer did
not have an opportunity to fire, since the player provided input
before the timer ended up firing, which made the select come true.
> > Well, really, something that requires RT performance should be in
> > the kernel. That's why we put interrupt handlers there. 8-).
>
> /me ponders having an option XMAME in the kernel.... nah, lets not go there :)
In terms of the video driver requirements, when the video driver
is used in certain modes. Also in terms of display rate for queued
frames to a video driver: the driver ould be set to display at a
steady 10 FPS, for example, and would do so, from queued data from
user space, come hell or high water.
> > Probably the place to do this is in the POSIX RT scheduling; if
> > the RT scheduling is active (meaning a process has called it, and
> > that process is still running), it's probably a reasonable thing
> > to crank up the Hz. This would make it self-adjusting, and also
> > self-healing, so that you could safely degrade the overall system
> > performance by intentionally running your application, but not
> > otherwise.
>
> That's a good suggestion, but how many OSs implement those? Where can I
> learn more about them? Any open standards?
Most modern OS's implement them. In FreeBSD, there's "rtprio", and
there's a kernel module to implement POSIX RT Scheduling (it was
discussed just the other day on the -current mailing list, when someone
was getting an "ENOSYS" because they had not loaded the module). You
can also "man -k scheduling". You are looking for system scope
scheduling priority.
> > Note that if this were implemented, it would mean your benchmark
> > is still broken, because it doesn't call the necessary interfaces.
>
> ? I don't get this.
Does your benchmark make the call to the POSIX RT scheduling? If it
doesn't, then the Hz would not "magically" bump itself up for the
duration of the program.
> > Another alternative would be a nanosleep call with an argument below
> > a certain value. I would hesitate to do it that way, though, since
> > I think that it ought to take a priviledged program to do the evil
> > deed, given the impact on the rest of the system.
>
> And that would sleep less than 10ms on average?
Either way you implemented it, it would dynamically adjust the Hz.
If you are serious about implementing this, you will have to go
through the kernel, and everywhere times are stored in ticks,
multiply the stored value by the new multiplier divided by the
old multiplier. That would be a lot of work.
If you do this, my suggestion would be to implement two new types
for this type of data:
tick_t For a fixed tick rate at boot Hz
hardtick_t For an adjusted Hz tick rate
...and then convert all tick fields to use one of these types,
preferrably tick_t (or clock values instead of ticks, if possible),
and only use hardtick_t where absolutely necessary.
You would also ensure that the adjusted Hz was some integer
multiple of the boot Hz. Then every adjusted_Hz/ boot_Hz
ticks of the adjusted clock, you make a soft tick to handle
tick_t's.
You still get the interrupt overhead, including the softintr
overhead (which can be considerable), but you only end up
paying the price when you absolutely have to do it.
The conversion of tick fields to a tick_t type (at the very
least) is long, long overdue.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
