On Mon, Sep 09, 2019 at 05:20:25PM +0930, O'Connor, Daniel wrote: > > > > On 8 Sep 2019, at 23:12, Konstantin Belousov <kostik...@gmail.com> wrote: > >> I suppose it would be good to change it to the same structure as the feed > >> forward clock stuff, that way it is much easier to change the number of > >> hands at compile time.. > >> > > > > The reason to not increase it by default is the same as the reason why it > > was reduced. But since I did still not provided the analysis why increasing > > timehands count helps for Ian' and your case, I think that making it easy > > to increase the timehands number is due. > > I am a bit worried (based on your commit log for r303383) that the code now > relies on it being 2 for correct function, although given I increased it to > 10 and this system works fine perhaps not :) > It means that the sliding window where consumer should reach the writer to read the current timehands is larger. I think that in reality the cases where the latency of get*time*(9) KPI increased are very rare.
Still the question is why your system have the negative impact from reducing the number of timehands. Interrupt should never interrupt tc_windup() because it is protected by spinlock. Silly question, are spinlocks functional on this machine ? > > Please see D21563 'Make timehands count selectable at boottime.' > > Looks good to me, I've installed it on the Beaglebone and it seems to be > running OK so far. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > > _______________________________________________ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
