Date: Sat, 30 Nov 2002 01:11:47 +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: <20021130011147.26e4c87b.fk@duese.org> In-Reply-To: <20021128210412.7aae42e2.fk@duese.org> References: <20021127210449.299ade52.fk@duese.org> <Pine.BSF.4.21.0211271213130.52749-100000@InterJet.elischer.org> <20021128210412.7aae42e2.fk@duese.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Nov 2002 21:04:12 +0100
Florian Kruegl <fk@duese.org> wrote:
> 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);
> > }
> >
> >
[...]
problem is some kind of solved as not any longer loosing some packets
all the time, performance for a Pentium II Celeron 300 MHz is somewhere
about that:
FrameSize Frames/s percent
64 2650 17.81
128 2559 30.30
256 2731 60.30
512 2350 100
1024 1197 100
1280 962 100
1518 813 100
percent are based on a 10MBit half duplex ethernet link as currently no
DSLAM available. The BSD Box has a quite heavy load but this is possible
to work arround, going to do another test with 100 MBit full duplex
link.
greetings
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021130011147.26e4c87b.fk>