Re: PPPoE Download Performance Woes (Resolved)
I guess this is one of those things that keeps biting into you until you get it resolved. After some experimentation, while I never thought this would have such an effect--especially with net.inet.tcp.rfc1323=1 and net.inet.tcp.sack=1 by default--the following simple additions to /etc/sysctl.conf resolve the issue: net.inet.tcp.recvspace=65536 net.inet.tcp.sendspace=65536 FWIW, analysis of the Windows PPPoE client in action shows this to be set to 65535. Because of my good experience with my cable connection, I never really considered Bandwidth-Delay Product having such an effect on this DSL connection, but, in this case, it clearly does. Another day, another lesson learned and another one for the archives... Danny Melameth, Daniel D. wrote: I think I'm going to leave this as an unresolved case--shame though. I also performed the following: * Replaced my ActionTec gt701 modem with a Cisco 678 (was going to do this anyway) and the same issue--Windows is fast, OpenBSD is not * Replaced xl with fxp and the same issue--however, OpenBSD clearly likes fxp better as I was able to get over 90Mb/s (under 10 percent interrupt usage) doing a crossover ftp transfer (compared to the 40Mb/s on xl) * Took Kevin's suggestion and played with tcpdump -tt, but I wasn't sure what to look for and it seems fine. Here's a snippet: $ sudo tcpdump -ntti fxp0 tcpdump: listening on fxp0, link-type EN10MB 1119059986.989027 PPPoE-Session code Session, version 1, type 1, id 0xb394, length 78 IP: 216.x.x.x.2853 200.144.121.33.123: v4 client strat 0 poll 0 prec 0 [tos 0x10] 1119059987.190136 PPPoE-Session code Session, version 1, type 1, id 0xb394, length 78 IP: 200.144.121.33.123 216.x.x.x.2853: v4 server strat 2 poll 0 prec 0 $ sudo tcpdump -ntti pppoe0 tcpdump: listening on pppoe0, link-type PPP_ETHER 1119059986.989021 216.x.x.x.2853 200.144.121.33.123: v4 client strat 0 poll 0 prec 0 [tos 0x10] 1119059987.190145 200.144.121.33.123 216.x.x.x.2853: v4 server strat 2 poll 0 prec I don't get it. I'm not sure what else to try or look at. Regards, D Melameth, Daniel D. wrote: Kevin wrote: On 6/7/05, Can Erkin Acar [EMAIL PROTECTED] wrote: Melameth, Daniel D. wrote: Prior to migrating to DSL, this same card was used for a cable connection and doing more than 1.5Mb/s. This really does not mean much. It could be a negotiation problem. Was your old cable modem ethernet connection 10BaseT ? 100baseTX full-duplex from a previous post ... xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:04:75:ac:05:48 media: Ethernet autoselect (100baseTX full-duplex) Perhaps your ADSL modem/switch has problems negotiating with your card, or your cable might have problems. The same cable was used with the Windows box. It'd help if the OP can provide the output of 'netstat -in' after the PPPoE has been up for a while. Here is the output from the time I rebooted the OpenBSD box this morning till the time I got home from work (which means it didn't get used much): $ netstat -in NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls lo0 33224 Link 0 00 0 0 lo0 33224 127/8 127.0.0.1 0 00 0 0 lo0 33224 ::1/128 ::1 0 00 0 0 lo0 33224 fe80::%lo0/ fe80::1%lo0 0 00 0 0 pflog0 33224 Link 0 00 0 0 pfsync0 2020 Link 0 00 0 0 enc0* 1536 Link 0 00 0 0 wi0 1500 Link 00:02:6f:09:58:b210227 011042 0 519 wi0 1500 192.168.255 192.168.255.254 10227 011042 0 519 wi0 1500 fe80::%wi0/ fe80::202:6fff:fe10227 011042 0 519 xl0 1500 Link 00:04:75:ac:05:4865278 048429 0 0 xl0 1500 192.168.255 192.168.255.221 65278 0 48429 0 0 xl0 1500 fe80::%xl0/ fe80::204:75ff:fe65278 048429 0 0 pppoe0 1492 Link 65275 048425 3 0 pppoe0 1492 0.0.0.0/32 70.x.x.x 65275 048425 3 0 pppoe0 1492 fe80::%pppo fe80::202:6fff:fe65275 048425 3 0 Full-duplex does not detect transmission errors, so you would not see them on netstat -i output. You could try setting media to 10BaseT half-duplex this usually helps you notice if there is a problem, and can sometimes solve it. ifconfig takes xl0 media 10baseT, but adding half-duplex yields: $ sudo ifconfig xl0 media 10baseT half-duplex ifconfig: half-duplex: bad value Regardless, with ifconfig xl0 media 10baseT, both the modem and OpenBSD box show the connection at 10Mb/s,
Re: PPPoE Download Performance Woes
I think I'm going to leave this as an unresolved case--shame though. I also performed the following: * Replaced my ActionTec gt701 modem with a Cisco 678 (was going to do this anyway) and the same issue--Windows is fast, OpenBSD is not * Replaced xl with fxp and the same issue--however, OpenBSD clearly likes fxp better as I was able to get over 90Mb/s (under 10 percent interrupt usage) doing a crossover ftp transfer (compared to the 40Mb/s on xl) * Took Kevin's suggestion and played with tcpdump -tt, but I wasn't sure what to look for and it seems fine. Here's a snippet: $ sudo tcpdump -ntti fxp0 tcpdump: listening on fxp0, link-type EN10MB 1119059986.989027 PPPoE-Session code Session, version 1, type 1, id 0xb394, length 78 IP: 216.x.x.x.2853 200.144.121.33.123: v4 client strat 0 poll 0 prec 0 [tos 0x10] 1119059987.190136 PPPoE-Session code Session, version 1, type 1, id 0xb394, length 78 IP: 200.144.121.33.123 216.x.x.x.2853: v4 server strat 2 poll 0 prec 0 $ sudo tcpdump -ntti pppoe0 tcpdump: listening on pppoe0, link-type PPP_ETHER 1119059986.989021 216.x.x.x.2853 200.144.121.33.123: v4 client strat 0 poll 0 prec 0 [tos 0x10] 1119059987.190145 200.144.121.33.123 216.x.x.x.2853: v4 server strat 2 poll 0 prec I don't get it. I'm not sure what else to try or look at. Regards, D Melameth, Daniel D. wrote: Kevin wrote: On 6/7/05, Can Erkin Acar [EMAIL PROTECTED] wrote: Melameth, Daniel D. wrote: Prior to migrating to DSL, this same card was used for a cable connection and doing more than 1.5Mb/s. This really does not mean much. It could be a negotiation problem. Was your old cable modem ethernet connection 10BaseT ? 100baseTX full-duplex from a previous post ... xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:04:75:ac:05:48 media: Ethernet autoselect (100baseTX full-duplex) Perhaps your ADSL modem/switch has problems negotiating with your card, or your cable might have problems. The same cable was used with the Windows box. It'd help if the OP can provide the output of 'netstat -in' after the PPPoE has been up for a while. Here is the output from the time I rebooted the OpenBSD box this morning till the time I got home from work (which means it didn't get used much): $ netstat -in NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls lo0 33224 Link 0 00 0 0 lo0 33224 127/8 127.0.0.10 00 0 0 lo0 33224 ::1/128 ::1 0 00 0 0 lo0 33224 fe80::%lo0/ fe80::1%lo0 0 00 0 0 pflog0 33224 Link 0 00 0 0 pfsync0 2020 Link 0 00 0 0 enc0* 1536 Link 0 00 0 0 wi0 1500 Link 00:02:6f:09:58:b210227 011042 0 519 wi0 1500 192.168.255 192.168.255.254 10227 011042 0 519 wi0 1500 fe80::%wi0/ fe80::202:6fff:fe10227 011042 0 519 xl0 1500 Link 00:04:75:ac:05:4865278 048429 0 0 xl0 1500 192.168.255 192.168.255.221 65278 048429 0 0 xl0 1500 fe80::%xl0/ fe80::204:75ff:fe65278 048429 0 0 pppoe0 1492 Link 65275 048425 3 0 pppoe0 1492 0.0.0.0/32 70.x.x.x 65275 048425 3 0 pppoe0 1492 fe80::%pppo fe80::202:6fff:fe65275 048425 3 0 Full-duplex does not detect transmission errors, so you would not see them on netstat -i output. You could try setting media to 10BaseT half-duplex this usually helps you notice if there is a problem, and can sometimes solve it. ifconfig takes xl0 media 10baseT, but adding half-duplex yields: $ sudo ifconfig xl0 media 10baseT half-duplex ifconfig: half-duplex: bad value Regardless, with ifconfig xl0 media 10baseT, both the modem and OpenBSD box show the connection at 10Mb/s, but the issue persists. And do try another ethernet card if possible. Seconded on both points. This is a CardBus card and I only have other 3Coms--I tried another identical 3Com card with the same poor results. One thing I've found very helpful in debugging PPPoE has been to use either the - (time between packets) or -tt (absolute epoch time) options on tpcdump, watching the packets on both the real Ethernet interface and the tunnel (pppoe0) interface, in two side-by-side windows. I was about to give this tcpdump timing a shot, but decided to spend a few more hours trying some other tests. Here is the results of my findings (all devices connected to the DSL modem were directly connected): * Reconfiguring the modem to handle the PPPoE
Re: PPPoE Download Performance Woes
Rod.. Whitworth wrote: On Tue, 7 Jun 2005 12:50:40 -0500, Kevin wrote: On 5/26/05, Rod.. Whitworth [EMAIL PROTECTED] wrote: When you have a modem that will do all the connection stuff I am amazed that anyone feels the need to do PPPoE. I prefer to have control over (and visibility into) the PPP connection and NAT, to this end I'm seriously considering getting rid of the external ADSL modem entirely, migrating to a Sangoma S518 ADSL PCI card. You are either a keen student or a masochist. ;) Dealing with those two issues in reverse order: I have perfect control over NAT because it is done in my OpenBSD firewall and it is way more complex than a modem could do anyway - routing a /29 without wasting a public IP on the $ext_if. So you don't need to move to a card to get NAT control, just turn it off in the modem or, as I do for simple client sites with only one static IP, use double NAT with the firewall $ext_if set as the default DMZ host (or something the same with a different name - depends on modem brand) and then the WAN IP will appear to be the firewall address. NAT too often tends to break new technology, especially where security is a concern... and double (or triple) NAT is sheer masochism--especially when debugging larger networks. I have control over PPP in the modem so that I have PPPoA running where it is common knowledge (wrong) that PPPoE is needed, the modem logs connections in detail and gives me lots of statistics without consuming firewall resources. At least one brand logs to syslog on the firewall. I'll admit, the statistics of the PPPoE/PPPoA connection is nice, but no where near as nice as having a public IP address on your OpenBSD box--many consumer-class large DSL providers in the US dislike providing public IPs to a consumer's own hardware (as opposed to the DSL router/modem provider by the provider). Finally I have several modems with saved configuration files so the death of a modem is not a drama. With a modem that is working fine an OpenBSD upgrade at the firewall doesn't mean that I need to pray that whatever code I would have been using to drive the modem would work with the latest OS. I used to dream of getting an internal ADSL modem. I'm now very glad I ccouldn't. My nightmare is not have a public IP assigned to my OpenBSD box.
Re: PPPoE Download Performance Woes
Kevin wrote: On 6/7/05, Can Erkin Acar [EMAIL PROTECTED] wrote: Melameth, Daniel D. wrote: Prior to migrating to DSL, this same card was used for a cable connection and doing more than 1.5Mb/s. This really does not mean much. It could be a negotiation problem. Was your old cable modem ethernet connection 10BaseT ? 100baseTX full-duplex from a previous post ... xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:04:75:ac:05:48 media: Ethernet autoselect (100baseTX full-duplex) Perhaps your ADSL modem/switch has problems negotiating with your card, or your cable might have problems. The same cable was used with the Windows box. It'd help if the OP can provide the output of 'netstat -in' after the PPPoE has been up for a while. Here is the output from the time I rebooted the OpenBSD box this morning till the time I got home from work (which means it didn't get used much): $ netstat -in NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls lo0 33224 Link 0 00 0 0 lo0 33224 127/8 127.0.0.10 00 0 0 lo0 33224 ::1/128 ::1 0 00 0 0 lo0 33224 fe80::%lo0/ fe80::1%lo0 0 00 0 0 pflog0 33224 Link 0 00 0 0 pfsync0 2020 Link 0 00 0 0 enc0* 1536 Link 0 00 0 0 wi0 1500 Link 00:02:6f:09:58:b210227 011042 0 519 wi0 1500 192.168.255 192.168.255.254 10227 011042 0 519 wi0 1500 fe80::%wi0/ fe80::202:6fff:fe10227 011042 0 519 xl0 1500 Link 00:04:75:ac:05:4865278 048429 0 0 xl0 1500 192.168.255 192.168.255.221 65278 048429 0 0 xl0 1500 fe80::%xl0/ fe80::204:75ff:fe65278 048429 0 0 pppoe0 1492 Link 65275 048425 3 0 pppoe0 1492 0.0.0.0/32 70.x.x.x 65275 048425 3 0 pppoe0 1492 fe80::%pppo fe80::202:6fff:fe65275 048425 3 0 Full-duplex does not detect transmission errors, so you would not see them on netstat -i output. You could try setting media to 10BaseT half-duplex this usually helps you notice if there is a problem, and can sometimes solve it. ifconfig takes xl0 media 10baseT, but adding half-duplex yields: $ sudo ifconfig xl0 media 10baseT half-duplex ifconfig: half-duplex: bad value Regardless, with ifconfig xl0 media 10baseT, both the modem and OpenBSD box show the connection at 10Mb/s, but the issue persists. And do try another ethernet card if possible. Seconded on both points. This is a CardBus card and I only have other 3Coms--I tried another identical 3Com card with the same poor results. One thing I've found very helpful in debugging PPPoE has been to use either the - (time between packets) or -tt (absolute epoch time) options on tpcdump, watching the packets on both the real Ethernet interface and the tunnel (pppoe0) interface, in two side-by-side windows. I was about to give this tcpdump timing a shot, but decided to spend a few more hours trying some other tests. Here is the results of my findings (all devices connected to the DSL modem were directly connected): * Reconfiguring the modem to handle the PPPoE connection, instead of the OpenBSD box, and reconfiguring the OpenBSD box as a workstation (meaning no hostname.pppoe0) yields the same 1.5Mb/s Internet download speed--which would suggest the issue is not with 3.7's kernel pppoe but, perhaps, related to xl * Removing the xl card from the OpenBSD box and putting it into a Windows box yields a 5.5Mb/s Internet download speed--which would suggest the card performs fine * Putting the xl card back into the OpenBSD box and performing an ftp transfer between the OpenBSD box and another box connected via crossover cable yields a 40Mb/s download speed--I'm not sure what this suggests, but it seems, in some way, there is some kind of interoperability issue between xl, OpenBSD and my DSL modem I'm interested in hearing some feedback on the above tests. Also, since it seems xl hardware is not well touted by those in the know, what Ethernet CardBus cards are recommended? I'll assume ne and rl are not one of these and I'll gladly pickup a recommended CardBus card to address this issue--particularly if the price is right (thinking eBay). Thanks again to those who've taken the time to read and respond to this thread, Danny
Re: PPPoE Download Performance Woes
Melameth, Daniel D. wrote: Kevin wrote: On 6/7/05, Can Erkin Acar [EMAIL PROTECTED] wrote: Melameth, Daniel D. wrote: Prior to migrating to DSL, this same card was used for a cable connection and doing more than 1.5Mb/s. This really does not mean much. It could be a negotiation problem. Was your old cable modem ethernet connection 10BaseT ? 100baseTX full-duplex from a previous post ... xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:04:75:ac:05:48 media: Ethernet autoselect (100baseTX full-duplex) Perhaps your ADSL modem/switch has problems negotiating with your card, or your cable might have problems. The same cable was used with the Windows box. It'd help if the OP can provide the output of 'netstat -in' after the PPPoE has been up for a while. Here is the output from the time I rebooted the OpenBSD box this morning till the time I got home from work (which means it didn't get used much): $ netstat -in NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls lo0 33224 Link 0 00 0 0 lo0 33224 127/8 127.0.0.10 00 0 0 lo0 33224 ::1/128 ::1 0 00 0 0 lo0 33224 fe80::%lo0/ fe80::1%lo0 0 00 0 0 pflog0 33224 Link 0 00 0 0 pfsync0 2020 Link 0 00 0 0 enc0* 1536 Link 0 00 0 0 wi0 1500 Link 00:02:6f:09:58:b210227 011042 0 519 wi0 1500 192.168.255 192.168.255.254 10227 011042 0 519 wi0 1500 fe80::%wi0/ fe80::202:6fff:fe10227 011042 0 519 xl0 1500 Link 00:04:75:ac:05:4865278 048429 0 0 xl0 1500 192.168.255 192.168.255.221 65278 048429 0 0 xl0 1500 fe80::%xl0/ fe80::204:75ff:fe65278 048429 0 0 pppoe0 1492 Link 65275 048425 3 0 pppoe0 1492 0.0.0.0/32 70.x.x.x 65275 048425 3 0 pppoe0 1492 fe80::%pppo fe80::202:6fff:fe65275 048425 3 0 Full-duplex does not detect transmission errors, so you would not see them on netstat -i output. You could try setting media to 10BaseT half-duplex this usually helps you notice if there is a problem, and can sometimes solve it. ifconfig takes xl0 media 10baseT, but adding half-duplex yields: $ sudo ifconfig xl0 media 10baseT half-duplex ifconfig: half-duplex: bad value Regardless, with ifconfig xl0 media 10baseT, both the modem and OpenBSD box show the connection at 10Mb/s, but the issue persists. And do try another ethernet card if possible. Seconded on both points. This is a CardBus card and I only have other 3Coms--I tried another identical 3Com card with the same poor results. One thing I've found very helpful in debugging PPPoE has been to use either the - (time between packets) or -tt (absolute epoch time) options on tpcdump, watching the packets on both the real Ethernet interface and the tunnel (pppoe0) interface, in two side-by-side windows. I was about to give this tcpdump timing a shot, but decided to spend a few more hours trying some other tests. Here is the results of my findings (all devices connected to the DSL modem were directly connected): * Reconfiguring the modem to handle the PPPoE connection, instead of the OpenBSD box, and reconfiguring the OpenBSD box as a workstation (meaning no hostname.pppoe0) yields the same 1.5Mb/s Internet download speed--which would suggest the issue is not with 3.7's kernel pppoe but, perhaps, related to xl * Removing the xl card from the OpenBSD box and putting it into a Windows box yields a 5.5Mb/s Internet download speed--which would suggest the card performs fine * Putting the xl card back into the OpenBSD box and performing an ftp transfer between the OpenBSD box and another box connected via crossover cable yields a 40Mb/s download speed--I'm not sure what this suggests, but it seems, in some way, there is some kind of interoperability issue between xl, OpenBSD and my DSL modem I have exactly this setup (xl0 connected to DSL modem on a high speed DSL line, it's a 3c905c card), The modem is an Arescom NetDSL 800 (shitty). The whole thing won't pass over 50kb/s if the xl0 card is 100baseTX full-duplex or even 10baseT full duplex. I have to configure xl0 this way: # cat /etc/hostname.xl0 inet 192.168.0.254 0xff00 NONE media 10baseT for pppoe to work with *this* ADSL modem. Meanwhile xl0 in a crossover cable works up to 60Mbps using media 100baseTX mediaopt full-duplex. The address of xl0 is just there cos I can connect to the modem's local ip address 192.168.0.1 via Arescom's NetDSL remote manager just to watch the speed the ADSL line have in cloudy days, it drops to 2200Kbps
Re: PPPoE Download Performance Woes
Can Erkin Acar wrote: Melameth, Daniel D. wrote: I've looked into this further and still cannot determine where the issue lies. Based on some advice, I unplugged the OpenBSD machine and setup a Windows XP machine instead. The Windows native PPPoE client was able to download at 5.5Mb/s and the OpenBSD machine was still stuck at 1.5Mb/s. My ADSL connection where I do my testing is only 256Kb, so I set up a second OpenBSD machine on the same LAN as a pppoe server and did some tests. I get almost the same performance with or without pppoe. ie. up to 70Mbps, after increasing the socket buffer size in iperf. This is -current, so Marco's comments about idle loop may also apply. Note that, if debugging is turned on, it would not go above 1.5Mb/s, due to excessive amount of logging, make sure that you do not somehow turn debug on by default. It is definitely not on by default. Another thing to try would be to replace your ethernet card. The xl(4) said to be quite crappy. Prior to migrating to DSL, this same card was used for a cable connection and doing more than 1.5Mb/s.
Re: PPPoE Download Performance Woes
You could test fot the idle loop issue by temporarily disabling apm0 on boot. I believe (correct me if I'm wrong0 that apm0 is the source of the idle loop problem? -Original Message- From: Melameth, Daniel D. [mailto:[EMAIL PROTECTED] Sent: 07 June 2005 02:10 PM To: OpenBSD Misc Subject: Re: PPPoE Download Performance Woes I've been hesitant to touch -current especially after a hackathon. Any idea if the idle loop fix is in the i386 6/3 snapshot? Marco Peereboom wrote: Actually I looked at the dmesg and I am almost certain that this machine has the idle loop issue. Try -current or wait until brad@ commits the errata. Melameth, Daniel D. wrote: I've looked into this further and still cannot determine where the issue lies. Based on some advice, I unplugged the OpenBSD machine and setup a Windows XP machine instead. The Windows native PPPoE client was able to download at 5.5Mb/s and the OpenBSD machine was still stuck at 1.5Mb/s.
Re: PPPoE Download Performance Woes
On 5/26/05, Rod.. Whitworth [EMAIL PROTECTED] wrote: When you have a modem that will do all the connection stuff I am amazed that anyone feels the need to do PPPoE. I prefer to have control over (and visibility into) the PPP connection and NAT, to this end I'm seriously considering getting rid of the external ADSL modem entirely, migrating to a Sangoma S518 ADSL PCI card. On 6/7/05, Can Erkin Acar [EMAIL PROTECTED] wrote: Melameth, Daniel D. wrote: Prior to migrating to DSL, this same card was used for a cable connection and doing more than 1.5Mb/s. This really does not mean much. It could be a negotiation problem. Was your old cable modem ethernet connection 10BaseT ? from a previous post ... xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:04:75:ac:05:48 media: Ethernet autoselect (100baseTX full-duplex) Perhaps your ADSL modem/switch has problems negotiating with your card, or your cable might have problems. It'd help if the OP can provide the output of 'netstat -in' after the PPPoE has been up for a while. Full-duplex does not detect transmission errors, so you would not see them on netstat -i output. You could try setting media to 10BaseT half-duplex this usually helps you notice if there is a problem, and can sometimes solve it. And do try another ethernet card if possible. Seconded on both points. One thing I've found very helpful in debugging PPPoE has been to use either the - (time between packets) or -tt (absolute epoch time) options on tpcdump, watching the packets on both the real Ethernet interface and the tunnel (pppoe0) interface, in two side-by-side windows. Kevin Kadow
Re: PPPoE Download Performance Woes
I've looked into this further and still cannot determine where the issue lies. Based on some advice, I unplugged the OpenBSD machine and setup a Windows XP machine instead. The Windows native PPPoE client was able to download at 5.5Mb/s and the OpenBSD machine was still stuck at 1.5Mb/s. A snippet from /var/log/messages after a ifconfig pppoe0 debug/ifconfig pppoe0 down/ifconfig pppoe0 up may be found at http://208.139.201.8/pppoe.debug. Standard output tcpdump captures from a web server capturing connections from the OpenBSD and Windows machines notes above may be found at http://208.139.201.8/openbsd.tcpdump and http://208.139.201.8/windows.tcpdump. I'm kind of at my wits end here and am not certain how to troubleshoot further--any and all help/comments appreciated. Thanks, Danny Melameth, Daniel D. wrote: Just moved from cable to DSL connectivity at home and decided to give 3.7's new kernelized pppoe as shot. My DSL connection trains at 7Mb/s down and 896Kb/s up and testing with Internet speed tests, I generally get 5.5Mb/s down and 715Kb/s up. These tests were done with the DSL router provided by my ISP. Once I switched the router to act as just a modem, doing rfc1483 bridging, and had the OpenBSD box handle the pppoe connection instead, which appears to do the establish, authenticate and network phases flawlessly, the same speed tests show my maximum to be 1.5Mb/s down and 715Kb/s up--even though the modem is training at full speed and the CPU states on the OpenBSD box appear okay, and I am not certain what is causing this. This issue is reproducible from NAT/PAT clients with PF and from the OpenBSD box itself without PF (which I believe rules out MTU issues). I have tried the following without success, am not certain where to look next and am looking for help: * Setting the MTU to 1492 on the physical pppoe interface (as per man 4 pppoe (it's a bit confusing where to actually adjust this)?) * Setting MSS to 1440 on pppoe in pf.conf (as per man 4 pppoe) * Setting the MTU to 1492 or less on the interfaces of NAT clients One thing I noticed of possible interest is a seemingly peculiar round-robin option in: $ sudo pfctl -s nat nat on pppoe0 inet from 192.168.x.x/27 to ! 192.168.x.x/30 - (pppoe0) round-robin As the only nat line I have in my pf.conf is: nat on $ext_if from $int_if:network to ! $wan_if:network - ( $ext_if ) Any thoughts/suggestions appreciated as I CANNOT IMAGINE relying on my ISP's router for WAP, firewall, QoS and other functions. Thanks, Danny $ ifconfig -a lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33224 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 pflog0: flags=141UP,RUNNING,PROMISC mtu 33224 pfsync0: flags=0 mtu 2020 enc0: flags=0 mtu 1536 wi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:02:6f:09:58:b2 ieee80211: nwid methWAP nwkey not displayed -18dBm (auto) media: IEEE802.11 autoselect hostap (DS2) status: active inet 192.168.x.x netmask 0xffe0 broadcast 192.168.255.255 inet6 fe80::202:6fff:fe09:58b2%wi0 prefixlen 64 scopeid 0x5 xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:04:75:ac:05:48 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.x.x netmask 0xfffc broadcast 192.168.255.223 inet6 fe80::204:75ff:feac:548%xl0 prefixlen 64 scopeid 0x6 pppoe0: flags=8851UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST mtu 1492 dev: xl0 state: session sid: 0xee68 PADI retries: 1 PADR retries: 0 time: 14:2:49 inet 70.x.x.x -- 0.0.0.1 netmask 0x inet6 fe80::202:6fff:fe09:58b2%pppoe0 - prefixlen 64 scopeid 0x7 $ dmesg OpenBSD 3.7 (GENERIC) #50: Sun Mar 20 00:01:57 MST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III (GenuineIntel 686-class) 647 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,F XSR,SSE real mem = 133668864 (130536K) avail mem = 115474432 (112768K) using 1657 buffers containing 6787072 bytes (6628K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(63) BIOS, date 12/30/99 apm0 at bios0: Power Management spec V1.2 apm0: battery life expectancy 100% apm0: AC on, battery charge high pcibios at bios0 function 0x1a not configured bios0: ROM list: 0xc/0xc000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 S3 Savage/IX-MV rev 0x11 wsdisplay0 at vga1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 5 function 0 Intel 82371AB PIIX4 ISA rev 0x02
Re: PPPoE Download Performance Woes
Without researching this too much; have you guys tried -current which contains the idle loop fix? On Jun 6, 2005, at 8:41 PM, Melameth, Daniel D. wrote: I've looked into this further and still cannot determine where the issue lies. Based on some advice, I unplugged the OpenBSD machine and setup a Windows XP machine instead. The Windows native PPPoE client was able to download at 5.5Mb/s and the OpenBSD machine was still stuck at 1.5Mb/s. A snippet from /var/log/messages after a ifconfig pppoe0 debug/ ifconfig pppoe0 down/ifconfig pppoe0 up may be found at http://208.139.201.8/pppoe.debug. Standard output tcpdump captures from a web server capturing connections from the OpenBSD and Windows machines notes above may be found at http://208.139.201.8/openbsd.tcpdump and http://208.139.201.8/windows.tcpdump. I'm kind of at my wits end here and am not certain how to troubleshoot further--any and all help/comments appreciated. Thanks, Danny Melameth, Daniel D. wrote: Just moved from cable to DSL connectivity at home and decided to give 3.7's new kernelized pppoe as shot. My DSL connection trains at 7Mb/s down and 896Kb/s up and testing with Internet speed tests, I generally get 5.5Mb/s down and 715Kb/s up. These tests were done with the DSL router provided by my ISP. Once I switched the router to act as just a modem, doing rfc1483 bridging, and had the OpenBSD box handle the pppoe connection instead, which appears to do the establish, authenticate and network phases flawlessly, the same speed tests show my maximum to be 1.5Mb/s down and 715Kb/s up--even though the modem is training at full speed and the CPU states on the OpenBSD box appear okay, and I am not certain what is causing this. This issue is reproducible from NAT/PAT clients with PF and from the OpenBSD box itself without PF (which I believe rules out MTU issues). I have tried the following without success, am not certain where to look next and am looking for help: *Setting the MTU to 1492 on the physical pppoe interface (as per man 4 pppoe (it's a bit confusing where to actually adjust this)?) *Setting MSS to 1440 on pppoe in pf.conf (as per man 4 pppoe) *Setting the MTU to 1492 or less on the interfaces of NAT clients One thing I noticed of possible interest is a seemingly peculiar round-robin option in: $ sudo pfctl -s nat nat on pppoe0 inet from 192.168.x.x/27 to ! 192.168.x.x/30 - (pppoe0) round-robin As the only nat line I have in my pf.conf is: nat on $ext_if from $int_if:network to ! $wan_if:network - ( $ext_if ) Any thoughts/suggestions appreciated as I CANNOT IMAGINE relying on my ISP's router for WAP, firewall, QoS and other functions. Thanks, Danny $ ifconfig -a lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33224 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 pflog0: flags=141UP,RUNNING,PROMISC mtu 33224 pfsync0: flags=0 mtu 2020 enc0: flags=0 mtu 1536 wi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:02:6f:09:58:b2 ieee80211: nwid methWAP nwkey not displayed -18dBm (auto) media: IEEE802.11 autoselect hostap (DS2) status: active inet 192.168.x.x netmask 0xffe0 broadcast 192.168.255.255 inet6 fe80::202:6fff:fe09:58b2%wi0 prefixlen 64 scopeid 0x5 xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:04:75:ac:05:48 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.x.x netmask 0xfffc broadcast 192.168.255.223 inet6 fe80::204:75ff:feac:548%xl0 prefixlen 64 scopeid 0x6 pppoe0: flags=8851UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST mtu 1492 dev: xl0 state: session sid: 0xee68 PADI retries: 1 PADR retries: 0 time: 14:2:49 inet 70.x.x.x -- 0.0.0.1 netmask 0x inet6 fe80::202:6fff:fe09:58b2%pppoe0 - prefixlen 64 scopeid 0x7 $ dmesg OpenBSD 3.7 (GENERIC) #50: Sun Mar 20 00:01:57 MST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III (GenuineIntel 686-class) 647 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX ,F XSR,SSE real mem = 133668864 (130536K) avail mem = 115474432 (112768K) using 1657 buffers containing 6787072 bytes (6628K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(63) BIOS, date 12/30/99 apm0 at bios0: Power Management spec V1.2 apm0: battery life expectancy 100% apm0: AC on, battery charge high pcibios at bios0 function 0x1a not configured bios0: ROM list: 0xc/0xc000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 S3 Savage/IX-MV rev 0x11 wsdisplay0 at vga1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5
Re: PPPoE Download Performance Woes
Melameth, Daniel D. wrote: I've looked into this further and still cannot determine where the issue lies. Based on some advice, I unplugged the OpenBSD machine and setup a Windows XP machine instead. The Windows native PPPoE client was able to download at 5.5Mb/s and the OpenBSD machine was still stuck at 1.5Mb/s. My ADSL connection where I do my testing is only 256Kb, so I set up a second OpenBSD machine on the same LAN as a pppoe server and did some tests. I get almost the same performance with or without pppoe. ie. up to 70Mbps, after increasing the socket buffer size in iperf. This is -current, so Marco's comments about idle loop may also apply. Note that, if debugging is turned on, it would not go above 1.5Mb/s, due to excessive amount of logging, make sure that you do not somehow turn debug on by default. Another thing to try would be to replace your ethernet card. The xl(4) said to be quite crappy. Can
Re: PPPoE Download Performance Woes
On 5/27/05, Melameth, Daniel D. [EMAIL PROTECTED] wrote: For what it's worth, I have been doing this for over a year with my OpenBSD box. Turning on or off the priqing of ACKs here has no affect on the performance decease apparently associated with using the OpenBSD box. ...so I'm open for more thoughts. Tried: scrub out on $pppoe max-mss 1440 in pf.conf? This is suggested in man 4 pppoe. -- Juha
PPPoE Download Performance Woes
Just moved from cable to DSL connectivity at home and decided to give 3.7's new kernelized pppoe as shot. My DSL connection trains at 7Mb/s down and 896Kb/s up and testing with Internet speed tests, I generally get 5.5Mb/s down and 715Kb/s up. These tests were done with the DSL router provided by my ISP. Once I switched the router to act as just a modem, doing rfc1483 bridging, and had the OpenBSD box handle the pppoe connection instead, which appears to do the establish, authenticate and network phases flawlessly, the same speed tests show my maximum to be 1.5Mb/s down and 715Kb/s up--even though the modem is training at full speed and the CPU states on the OpenBSD box appear okay, and I am not certain what is causing this. This issue is reproducible from NAT/PAT clients with PF and from the OpenBSD box itself without PF (which I believe rules out MTU issues). I have tried the following without success, am not certain where to look next and am looking for help: * Setting the MTU to 1492 on the physical pppoe interface (as per man 4 pppoe (it's a bit confusing where to actually adjust this)?) * Setting MSS to 1440 on pppoe in pf.conf (as per man 4 pppoe) * Setting the MTU to 1492 or less on the interfaces of NAT clients One thing I noticed of possible interest is a seemingly peculiar round-robin option in: $ sudo pfctl -s nat nat on pppoe0 inet from 192.168.x.x/27 to ! 192.168.x.x/30 - (pppoe0) round-robin As the only nat line I have in my pf.conf is: nat on $ext_if from $int_if:network to ! $wan_if:network - ( $ext_if ) Any thoughts/suggestions appreciated as I CANNOT IMAGINE relying on my ISP's router for WAP, firewall, QoS and other functions. Thanks, Danny $ ifconfig -a lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33224 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 pflog0: flags=141UP,RUNNING,PROMISC mtu 33224 pfsync0: flags=0 mtu 2020 enc0: flags=0 mtu 1536 wi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:02:6f:09:58:b2 ieee80211: nwid methWAP nwkey not displayed -18dBm (auto) media: IEEE802.11 autoselect hostap (DS2) status: active inet 192.168.x.x netmask 0xffe0 broadcast 192.168.255.255 inet6 fe80::202:6fff:fe09:58b2%wi0 prefixlen 64 scopeid 0x5 xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 address: 00:04:75:ac:05:48 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.x.x netmask 0xfffc broadcast 192.168.255.223 inet6 fe80::204:75ff:feac:548%xl0 prefixlen 64 scopeid 0x6 pppoe0: flags=8851UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST mtu 1492 dev: xl0 state: session sid: 0xee68 PADI retries: 1 PADR retries: 0 time: 14:2:49 inet 70.x.x.x -- 0.0.0.1 netmask 0x inet6 fe80::202:6fff:fe09:58b2%pppoe0 - prefixlen 64 scopeid 0x7 $ dmesg OpenBSD 3.7 (GENERIC) #50: Sun Mar 20 00:01:57 MST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III (GenuineIntel 686-class) 647 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,F XSR,SSE real mem = 133668864 (130536K) avail mem = 115474432 (112768K) using 1657 buffers containing 6787072 bytes (6628K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(63) BIOS, date 12/30/99 apm0 at bios0: Power Management spec V1.2 apm0: battery life expectancy 100% apm0: AC on, battery charge high pcibios at bios0 function 0x1a not configured bios0: ROM list: 0xc/0xc000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 S3 Savage/IX-MV rev 0x11 wsdisplay0 at vga1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 5 function 0 Intel 82371AB PIIX4 ISA rev 0x02 pciide0 at pci0 dev 5 function 1 Intel 82371AB IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: SAMSUNG MP0402H wd0: 16-sector PIO, LBA48, 38204MB, 78242976 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: TOSHIBA, DVD-ROM SD-C2402, 1317 SCSI0 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 uhci0 at pci0 dev 5 function 2 Intel 82371AB USB rev 0x01: irq 11 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered Intel 82371AB Power Mgmt rev 0x03 at pci0 dev 5 function 3 not configured ATT/Lucent LTMODEM rev 0x01 at pci0 dev 7 function 0 not configured vendor Toshiba, unknown product 0x0d01 (class wireless
Re: PPPoE Download Performance Woes
One possibility is that your modem prioritized ACK's... See http://www.benzedrine.cx/ackpri.html
