Date: Thu, 05 Dec 2002 02:26:36 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Stijn Hoop <stijn@win.tue.nl> Cc: hackers@freebsd.org Subject: Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle] Message-ID: <3DEF29DC.43006217@mindspring.com> References: <20021202151816.GJ83264@pcwin002.win.tue.nl> <20021202114019.R31106-100000@patrocles.silby.com> <20021204113154.GA205@pcwin002.win.tue.nl> <3DEE4418.868B4936@mindspring.com> <20021204191125.GG52541@pcwin002.win.tue.nl> <3DEE58C6.19ACF59C@mindspring.com> <20021205085604.GB56010@pcwin002.win.tue.nl> <3DEF2340.C4AEED1A@mindspring.com> <20021205100732.GC56010@pcwin002.win.tue.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DEF29DC.43006217>