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?
