From owner-freebsd-questions Thu May 20 7:14:31 1999 Delivered-To: freebsd-questions@freebsd.org Received: from plains.NoDak.edu (plains.NoDak.edu [134.129.111.64]) by hub.freebsd.org (Postfix) with ESMTP id 548F115072 for ; Thu, 20 May 1999 07:14:30 -0700 (PDT) (envelope-from tinguely@plains.NoDak.edu) Received: (from tinguely@localhost) by plains.NoDak.edu (8.8.8/8.8.8) id JAA28383; Thu, 20 May 1999 09:13:12 -0500 (CDT) Date: Thu, 20 May 1999 09:13:12 -0500 (CDT) From: Mark Tinguely Message-Id: <199905201413.JAA28383@plains.NoDak.edu> To: brian@Awfulhak.org Subject: Re: Number of TUN devices Cc: questions@FreeBSD.ORG Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FYI: I am playing with the idea of a direct-insert PPP for future SONET/ATM/DSL PPP connections. here compression/ACCM are not a concern but higher data rates make the kernel/user space copying (x2 once on each device inteface) and the prcessing copying can be a concern for throughput. I am not bad mouthing the tun driver; it is an excellent driver for serial devices that needs to PROCESS the packets from/to the PPP link. In the SONET/ATM/DSL world, the PDUs will already be in mbufs from the device driver. The MRU/MTU can be much larger. The data packets do not need to compressed/encrypted/ACCM-ed, so the for those opened NCPs, the data packets can be placed directly into the appropriate kernel protocol stacks. the diagnostic, and control packets can still be processed in user space via a protocol socket. Have you experimented what kind of through-put the NOS-TUN can handle? I suspect that this model would be good enough for DSL speeds. --mark tinguely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message