> Trevor Talbot wrote ... > > I did some playing around and discovered something. It seems that > someone forgot to fully ALTQify tun0. Specifically, select() > always returns read-ready if there's any data in the internal queue, > whether ALTQ's discipline is ready to release it or not. > > The theory is that when the queues start filling, ppp's non-blocking > I/O loop starts spinning on tun0, trying to pull packets off when > they aren't ready. Once it starts spinning, pppoe will be adversely > affected and lose throughput. > > As I don't have a PPPoE setup to work with, I did my own testing with > just tun0, and saw the spin effect. Below is a patch for if_tun.c, > which fixed the problem I observed. I'd like to know if it fixes > pppoe queueing for anyone brave enough to try patches from me. I've > been known to make things explode.
As far as I'm concerned, this patch works just great. I can finally queue on tun0 with my _upload_ bandwidth (minus the pppoe overhead). PPPoE hasn't blown up yet and computer still processes packets correctly. Download works much better over the saturated link now. The only weird thing I have noticed is that the download started at 127 KB/s (full DL bandwidth of my ADSL link), but then slowly dropped to the 60 KB/s and stabilized there. During that slowdown, pppoe CPU% raised to the 26% and then stabilised. When download completed, pppoe CPU% normalized back to the < 1%. This could, of course, be the result of the user-landness of OBSD ppp. Now I'll recompile the kernel on the second firewall with faster ADSL (4Mb/768Kb) and test (and report, of course). Best regards and thanks, Primoz
