From owner-freebsd-hackers Sat Mar 7 21:39:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04037 for freebsd-hackers-outgoing; Sat, 7 Mar 1998 21:39:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA03986 for ; Sat, 7 Mar 1998 21:39:42 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id FAA04388; Sun, 8 Mar 1998 05:09:21 +0100 From: Luigi Rizzo Message-Id: <199803080409.FAA04388@labinfo.iet.unipi.it> Subject: Re: weird problem (lost packets) in iijppp To: brian@Awfulhak.org (Brian Somers) Date: Sun, 8 Mar 1998 05:09:21 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: <199803080056.AAA19541@awfulhak.org> from "Brian Somers" at Mar 8, 98 00:55:53 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Would you be able to try this with the ppp from -current, -stable or > http://www.FreeBSD.org/~brian ? downloading the files right now... in any case i did some more tests yesterday night, and every time i have a lost reply the "miss" or "uncompress" (depending on the direction) counts below increase: PPP ON prova> show compress Out: 780 (compress) / 909 (total) 14 (miss) / 300 (search) In: 819 (compress), 107 (uncompress) 0 (error), 0 (tossed) I have no idea if this only happens with ICMP packets or also with regular traffic. Speaking of ppp, i was wondering if you are also looking at the memory allocation used in the program. It seems to do a few malloc() on each packets (one for the header, one for the payload... and this appears kind of useless since the queues are short anyways and using a fixed array would be probably much more efficient. Also, would you like to help in implementing the 'preemption' feature that i had in mind ? The basic idea would be to define some negotiable mechanism (e.g. HDLC_ESC+something) to suspend/resume transmission of a packet when there is a higher-priority one. This would be used to improve interactive response when you also have background bulk traffic. Of course one has to be careful in the interaction with the "pred1" compression. This mechanism could also be useful (assuming it's not already there) with parallel ppp connections, since it would allow you to spread a packet on a number of parallel links. cheers luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message