starseeker (Dec 18 2020 at 13:37): starseeker (Dec 18 2020 at 13:37):Oh - a second pair of eyeballs on the librt timer update would be appreciated. If I have time I'm going to try to complete moving that down to libbu as well, but before I add that layer of change it would be good to make sure I didn't miss anything silly in the approach.
starseeker (Dec 18 2020 at 13:39):In a technical sense that might be user visible, since I think the old timing routines weren't always measuring what the API documentation indicated they should be measuring. Don't know if it's worth calling out.
Sean (Dec 18 2020 at 18:23):Yeah, they were implemented on Windows way back when they didn't have great timing facilities, was a known issue (to me at least)
Sean (Dec 18 2020 at 18:24):there's a todo to push it to libbu, but we'll want to reconcile it with the timers already in there. Definitely don't want to migrate that global state into libbu.. that's gotta go, and that means updating the caller sites.
starseeker (Dec 18 2020 at 18:25):Do we put a bu timer in the rt application struct?
Sean (Dec 18 2020 at 18:25):could make bu's timer just start/record both clocks, and have calling applications request one or the other
Sean (Dec 18 2020 at 18:26):ehm, I dunno -- could belong in the rtip
Sean (Dec 18 2020 at 18:26):maybe the app
starseeker (Dec 18 2020 at 18:26):/me nods. OK, got enough other fish to fry I'll not worry about the libbu move this round - not urgent
Sean (Dec 18 2020 at 18:30):wow, hate to say it ... but looking at the structs, it looks like struct resource may be the most appropriate
Sean (Dec 18 2020 at 18:30):it's already tracking counts, just not time
Sean (Dec 18 2020 at 18:33):that would allow for proper timing if we split work across cores too. struct rt_i says it's its job to track statistics, but it tracks via struct resource.
starseeker (Dec 18 2020 at 18:34):/me nods - sounds reasonable
Last updated: Oct 09 2024 at 00:44 UTC