On Fri, Jul 27, 2007 at 06:53:27PM -0600, Daniel Melameth wrote: > On 7/22/07, Daniel Melameth <[EMAIL PROTECTED]> wrote: > > On 7/22/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: > > > On 2007/07/20 15:20, Daniel Melameth wrote: > > > > then go back to the broken behavior sometime later. A reboot of the > > > > box or > > > > removing altq is the only way to resolve the issue, temporarily. I've > > > > tried > > > > both priq and cbq, adjusting tbrsize, recompiling the kernel with a > > > > higher > > > > HZ value and using different hardware and different Internet > > > > connections, > > > > but the issue persists. > > > > > > Try a snapshot, i386 moved to the new timecounter code after 4.1. > > > > > > Though I note there is also an XXX about variable cpu frequency (in > > > sys/altq/altq_subr.c) which might affect you if you adjust cpu speed > > > (manually or by apmd). > > > > > > > Full detail on the issue is available from my gnats post at > > > > # Attempt to account for overhead of RFC 1483 bridging, ATM, PPPoE and > > > > TCP > > > > > > For this you might like to try a diff of mine and report back > > > (http://spacehopper.org/openbsd/altq_tbradapt.diff). > > > It won't help the other problem though. > > > > Thanks for taking the time to reply. I can't readily do a snapshot > > now, but since I am using apmd, I'll try this avenue first and see > > what happens. I also went ahead and incorporated your diffs into my > > currently running 4.1-stable and it appears to be working quite well, > > but I'm not certain if I'm piloting these changes the correct way--so > > if there's an ideal way you'd recommend piloting this, let me know. > > Regardless, I'll monitor the result of these diffs this week and give > > you a heads up at the end of the week. > > Stuart, > > I did some simple piloting of your diffs and they work quite nicely. > The details: > > Without altq, I get a fairly consistent roundtrip latency of 58ms to a > known good host when there is no congestion--and when the upstream is > saturated, latency to the same host goes up to ~220ms. If I use altq > without your diffs and specify my maximum upload bandwidth of 896Kb, > as expected the overhead of PPPoE tramples this and I still get ~220ms > under saturation even with a high priority queue. In order to get > decency latency in this case, I have to artificially estimate a > bandwidth of ~716Kb--and this provides for a high priority queue > latency of ~68ms while saturated, which is pretty good. > > With your diffs though, not only do I get ~68ms for a high priority > queue while using a bandwidth of 896Kb on a saturated connection, but > my maximum upload speed is, consistently, a bit higher as well when > compared to using a bandwidth of 716Kb without your diffs. I > continued to pilot your diffs further by seeding and downloading > multiple torrents simultaneously--to more heavily expose small TCP > ACKs to the stream--and I continued to get these consistently good > results. > > I have been using your diffs for almost a week now with nary an issue. > So, my next question is: > > HOW DO WE GET YOUR GREAT DIFFS INTO -CURRRENT OR A SNAPSHOT?
The problem with this diff is that it assumes an ADSL link. While 'vcmux' is obviously ADSL terminology, I assume having 'pppoe' or 'bridge' would confuse others trying to use non-adsl pppoe connections or even real bridges. While altq is not my area, I think the diff would be more useful if it allowed an 'overhead' and a 'scale' to be set on an interface. You could then document suitable values for commonly used setups (pppoe/vcmux/whatever).
