pengfork-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pengfork-devel] ANNOUNCE: pengfork working


From: Nicolas Burrus
Subject: Re: [Pengfork-devel] ANNOUNCE: pengfork working
Date: Fri, 13 Sep 2002 13:32:28 +0200
User-agent: KMail/1.4.3

On Thursday 12 September 2002 21:29, Jean-Charles Salzeber wrote:
> On Thu, Sep 12, 2002 at 18:01, Nicolas Burrus wrote:
> > On Thursday 12 September 2002 17:17, Jean-Charles Salzeber wrote:
> > > The problem seems located somewhere in the tun interface because some
> > > IP packets are cut/broken and I don't see an easy mean to be sure we
> > > have a good IP packet to send, I could explain a bit more if you wish.
> >
> > Yes, I'd like to have more explanations :)
>
> OK
>
> Normally the input buffer of the tun interface contains raw IP packets.
> I take them packet by packet to transmit them into the tunnel.
> So normally, the start of the buffer is always the start of an IP
> packet.
>
> What it seems to happen when the message "engine - an input buffer is
> full" appears that the start of the buffer is not an IP packet. So
> because I wait for the packet to be entire and the IP length field point
> to arbitrary data that could be > MTU which is normally not possible.
>
> This happens only when you explicitly flood the interface with packets
> (like a 'ping -f www.microsoft.com' command) or when you send many
> packets doing an upload (or CVS commit for example).
>
> So I believe, that when the interface receive more data that the client
> read, some data is lost and especially IP header. I could be wrong since
> pengaol use the tun interface without such problem, but it use
> synchronous read/write with a multi-threaded design, pengfork use
> asynchronous read/write with a multiplexing design, so there may be a
> difference.
>
> It could also simply be some memory overwriten by something, but I don't
> believe it.
>
> I hope to be clear enough.

Ok, I understand, it needs a small investigation :)

> PS: It seems that pengfork is also less CPU intensive than pengaol (it
> have never overflowed 0.3%, pengaol can reach 10.0% on my Pentium 200
> computer)

On my PII 400 with -O2 and no debug, it doesn't even take 0.1% while 
downloading at 7400bps ! (RNIS). However I always found curious pengaol took 
so much CPU only extracting and building packets on a so small data flow (it 
used generally around 10% of CPU).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]