Date: Thu, 28 Nov 2002 21:04:12 +0100 From: Florian Kruegl <fk@duese.org> To: Julian Elischer <julian@elischer.org> Cc: freebsd-net@FreeBSD.ORG Subject: Re: pppoe performance problems Message-ID: <20021128210412.7aae42e2.fk@duese.org> In-Reply-To: <Pine.BSF.4.21.0211271213130.52749-100000@InterJet.elischer.org> References: <20021127210449.299ade52.fk@duese.org> <Pine.BSF.4.21.0211271213130.52749-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Nov 2002 12:47:20 -0800 (PST)
Julian Elischer <julian@elischer.org> wrote:
>
>
> On Wed, 27 Nov 2002, Florian Kruegl wrote:
>
> > Hi *,
> >
> > I'm trying to set up some kint of test environment for xDSL devices. before wasting much time trying to explain the environment here is a little picture:
> >
> > | | | | | | | | |
> > | | | | | | | | | XDSL Lines
> > +-+-+-+-+-+-+-+-+
> > | Siemens DSLAM |
> > +-------+-------+
> > |
> > ATM (OC3 SM)
> > |
> > +-------+-------+ fxp0 +---------------+
> > | Brick XL +--------X-Over---------+ FreeBSD 4.6 |
> > +-------+-------+ +-------+-------+
> > | | fxp1
> > Ethernet Ethernet
> > 192.168.64.2 192.168.64.3
> > | |
> > --------+---------------------------------------+-----------
> > _Internet_
> >
> > The BrickXL operates as a bridge and bridges the VPI:VCI combinations intended to be used for PPPoE and DHCP directly over the X-Over link to the FreeBSD Box running pppoed and dhcpd.
> > Using tcp connections for bandwith maessurement show normal values, but when using a Ethernet Test Box (SmartApp / SmartBits), which spits out IP pakets at a defined rate and uses all sent frames where recieved as success criteria to determine the maximum transfer rate, gives rates about 60 f/s. when looking at the logs you can see that at higher rates (2000f/s) there are just one or two frames missing. but it takes till theese mentioned 60 f/s second till all packets are recieved by the testequipment.
> >
> > my pppoe config is nothing special:
> > rc.conf
> > --------------------<Schanipp>--------------------
> > pppoed_enable="YES"
> > pppoed_provider="pppoe"
> > pppoed_flags="-P /var/run/pppoed.pid"
> > pppoed_interface="fxp0"
> > --------------------<Schanipp>--------------------
> >
> > ppp.conf
> > --------------------<Schanipp>--------------------
> > default:
> > set log Phase Chat IPCP CCP tun command
> >
> > pppoe:
> > allow mode direct
> > set timeout 0
> > disable mppe
> > enable pap
> > set ifaddr 192.168.64.3/32 192.168.100.1-192.168.100.127
> > allow users
> > accept dns
> > set dns 192.168.64.3
> > disable lcp
> > accept lqr
> > disable deflate
> > disable pred1
> > disable vjcomp
> > disable acfcomp
> > disable protocomp
> > set vj slotcomp off
> > --------------------<Schanipp>--------------------
> >
> > mpd is not a good alternative in this cas as AFAIK not capable of
> > acting as a PPPoE-Server.
>
> correct.
>
> The question is WHERE are the packets being lost?.
more than a good point, seems that I got some man pages to read, in order to find out who looses those packets.
>
> Are all the generated packets being aimed at a single session?
> are they all session startup packets, or data packets on an
> already set up session?
>
in this case there is only one setup session where only data packets should be transfered in one direction, as this is no tcp it should be a real unidirectional test, I even disabled LCP keepaliving. this is a plain pppoe session.
I added the code to increase buffer size to the Spawn function, but I'll have to wait till tomorrow to plug in the testequipment. Willing to send mail no matter if that already fixed the problem or not.
Something I got in my mind but forgot to put in the last mail is that this testcycle starts with very tiny frames ( 64 Byte ) and pulls them up in seven steps till it reaches the ethernet maximum. I never tested anything more than with theese 64Byte frames ;( perhaps I should let it run once completely )
>
> I would suspect that the socket buffer size on the
> netgraph socket that ppp is using may be too short.
>
> you can try increase the buffer size in pppoed.c using
> int newval;
> int len;
> len = sizeof (newval);
> [...]
> getsockopt( so, SOL_SOCKET, SO_RCVBUF, &newval, &len);
> newval *= 4; /* make it 4 times as big */
> setsockopt( so, SOL_SOCKET, SO_RCVBUF, &newval, len);
>
> This should happen in the function Spawn()
>
> probably about
> if (debug)
> syslog(LOG_INFO, "Sending CONNECT from .:%s -> %s.%s",
> ngc.ourhook, ngc.path, ngc.peerhook);
> if (NgSendMsg(cs, ".:", NGM_GENERIC_COOKIE,
> NGM_CONNECT, &ngc, sizeof ngc) < 0) {
> syslog(LOG_ERR, "Cannot CONNECT PPPoE and socket nodes: %m");
> _exit(EX_OSERR);
> }
>
>
> /* HERE */
> ========new code
> /* make the data socket buffer larger */
>
> getsockopt( ds, SOL_SOCKET, SO_RCVBUF, &newval, &len);
> newval *= 4; /* make it 4 times as big */
> setsockopt( ds, SOL_SOCKET, SO_RCVBUF, &newval, len);
>
>
> /*
> * If we tell the socket node not to LINGER, it will go away when
> * the last hook is removed.
> */
> if (debug)
> syslog(LOG_INFO, "Sending NGM_SOCK_CMD_NOLINGER to socket");
> if (NgSendMsg(cs, ".:", NGM_SOCKET_COOKIE,
> NGM_SOCK_CMD_NOLINGER, NULL, 0) < 0) {
> syslog(LOG_ERR, "Cannot send NGM_SOCK_CMD_NOLINGER: %m");
> _exit(EX_OSERR);
> }
>
>
>
> >
> > DHCP performs fine.
>
> Dhcp is not handling all the traffic, just the setup..
>
> let me know if this helps.
>
sure.
thats why I wasted some short thoughts about mpd it also only mangages the setup and all the encapsulation stuff will be done in kernelspace.
greetings
flo
--
The difference between this school and a cactus plant is that the
cactus has the pricks on the outside.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021128210412.7aae42e2.fk>