Re: timeouts too long bug again...
On Jan 26, 2012, at 11:08 AM, Luigi Rizzo wrote: > In sep.2009 i noticed that usleep() select() and friends (including > the in-kernel callouts) would consistently take one tick longer > than they should, and committed a fix to sys/kern/kern_timeout.c > to HEAD and RELENG_8 Sounds like the tvtohz() issue described here: http://www.dragonflybsd.org/presentations/nanosleep/ ...and the prior discussion you had with Peter Wemm: http://www.mavetju.org/mail/view_message.php?list=freebsd-stable&id=3022641 Regards, -- -Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
timeouts too long bug again...
In sep.2009 i noticed that usleep() select() and friends (including the in-kernel callouts) would consistently take one tick longer than they should, and committed a fix to sys/kern/kern_timeout.c to HEAD and RELENG_8 http://svnweb.freebsd.org/base?view=revision&revision=197137 http://svnweb.freebsd.org/base?view=revision&revision=200510 Now it seems that the bug is there again, in some form: on 9.0 (and someone reported this also no HEAD) the minimum sleep interval is now 2 ticks. Callouts seem to be correct (at least, dummynet delays are exact, and the sysctl net.inet.ip.dummynet.tick_adjustment: 2770 now does not grow at 500 HZ as it did in the past. Any idea on what might have reintroduced the problem ? (please spare us the story that usleep gives no guarantees etc etc - we all know that, but FreeBSD is consistently 1 tick above the minimum guaranteed interval) cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
