Date: Wed, 27 Nov 2002 12:47:20 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Florian Kruegl <fk@duese.org> Cc: freebsd-net@FreeBSD.ORG Subject: Re: pppoe performance problems Message-ID: <Pine.BSF.4.21.0211271213130.52749-100000@InterJet.elischer.org> In-Reply-To: <20021127210449.299ade52.fk@duese.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?.
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?
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.
>
> greets
>
> flo
> --
> God isn't dead -- he's been busted.
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
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?Pine.BSF.4.21.0211271213130.52749-100000>