Date: Sat, 07 Apr 2007 11:33:17 -0700 From: Nate Lawson <nate@root.org> To: Max Laier <max@love2party.net> Cc: freebsd-current@freebsd.org, freebsd-pf@freebsd.org Subject: Re: call for testers: altq in current Message-ID: <4617E3ED.9090400@root.org> In-Reply-To: <200704071945.51273.max@love2party.net> References: <4617D3A6.8000201@root.org> <200704071945.51273.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Max Laier wrote: > On Saturday 07 April 2007 19:23, Nate Lawson wrote: >> A few weeks ago, I committed a change to ALTQ that I was only able to >> compile-test. What I need is someone with a laptop or other >> cpufreq-capable system that is also using ALTQ to verify that with >> powerd running, the queuing timing is now reliable. >> >> Previously, altq would just cache the first value of the CPU freq it >> saw (based on tsc_freq) and use that forever. Now it gets updated each >> time the freq changes. I want to make sure the edge cases (i.e., freq >> changes while a packet is being timed) work ok. > > I will try to give it a spin over the long weekend. Other testers please > note that you should test this without ALTQ_NOPCC. Looking at the patch > now, it seems that the eventhandler should take this into account, too. > i.e. when ALTQ_NOPCC is defined we emulate a 256Mhz clock with > microtime - this shouldn't be dependent on the real cpu frequency > (eventhough things will get strange when the clockspeed drops below > 256Mhz). Sorry for not paying attention when you posted the patch. > > CC'ing freebsd-pf@ ... laptop anyone? Thanks Max. Yes, the microtime clock will be mostly unaffected by the CPU frequency. However, we may need to look into that case. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4617E3ED.9090400>