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