Timekeeping in stable/9
Joe Holden
lists at rewt.org.uk
Thu Jan 19 21:09:28 UTC 2012
Joe Holden wrote:
> Chuck Swiger wrote:
>> On Jan 19, 2012, at 12:18 PM, Joe Holden wrote:
>>>> Sounds like you were looking for commercial support, since unpaid
>>>> volunteers don't have an obligation to promptly leap out and provide
>>>> solutions within your ETA.
>>> Not really, just an acknowledgement would be fine. It is what it is,
>>> everyday I try to argue in favour of the project, I still use it for
>>> myself everywhere but increasingly things happen that just don't on
>>> other volunteer projects... it's rather difficult to argue the case
>>> when they can install Ubuntu or whatever nonsense distro is the
>>> current favourite and it just works. Just a bit more accurate info
>>> would solve it, if it doesn't do X reliably, or Y has changed, note it.
>>
>> You asked a question and got two or three responses back in a day.
>> You mentioned trying different timekeeping choices, but I don't recall
>> seeing what your kern.timecounter sysctl values looked like; without
>> that, folks are missing info that is likely to be relevant.
>>
>> Ah, well....
>>
>> Regards,
> Yeah my gripe isn't with having no responses, the handful of people that
> have responded have been helpful but ultimately no responses from anyone
> involved. Just a one liner saying "we changed the timecounter stuff in
> 9, look at sysctl tree X" would have been more than sufficient, this
> sort of thing should really be mentioned in the relnotes though...
>
> For the record though, setting kern.eventtimer.periodic to 1 fixes the
> problem on all affected machines (returns my virtualbox guest to
> normality, reduces the drift on physical machines to 8.2 figures).
>
> FWIW, I can't even see any notes relating to this in UPDATING either.
I should probably clarify here that some responses were received from
the maintainers (eg: Qing for mpath) for a couple of bits of code but
the wider issues weren't discussed further. I'm not trying to say that
no effort is made, but as a whole for the project to be comparable to
the alternatives this sort of thing shouldn't happen.
More information about the freebsd-stable
mailing list