Date: Sat, 13 Jan 1996 15:52:56 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, nate@sri.MT.net Cc: hackers@FreeBSD.ORG Subject: Re: PPP transfer rates (was Re: pppd vs ijppp) Message-ID: <199601130452.PAA10221@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> I get > 2KB/s for /kernel with a lowly 14400 bps modem with DTE at >> 57600 bps connected to a Linux system with a better modem: >First of all, how are we measuing throughput? I'm using ftp transfers, >which is what I'm assuming both of you are using. Yes. I would prefer to use ttcp, but it wasn't available on the Linux system. >Using kernel-ppp with VJ compression to a host on the same network as >the Livinston I'm getting: 795794 bytes sent in 1.7e+02 seconds (4.6 >Kbytes/s) >Using CSLIP to my home workstation (direct connect) I'm getting: >795794 bytes sent in 1.6e+02 seconds (4.9 Kbytes/s) >I'm actually suprised that CSLIP is faster than PPP with VJ compression >(essentially the same header compression as in CSLIP). I do know that >the latency is lower with SLIP vs. PPP. Cslip has a smaller packet overhead (in bytes) (except when full compression is used with ppp, IIRC). Cslip has about twice as much protocol overhead as termios in the current kernel implementation and 3 times as much in the current user mode implementation. This is without compression; compression adds one or two multiples of the termios overhead. E.g., on a 486DX2/66 ISA 16550A to a 486DX33 ISA 16450 at 115200 bps uncompressed: - %overhead - protocol read write throughput (K/s) -------- ---- ----- ---------------- cat 6.7 2.9 11.25 cslip 6.7 3.6 10.78 ppp (kernel) 9.1 4.3 10.74 ppp (user) 11.3 6.6 10.80 zmodem 11.4 5.8 10.73 >However, I'm seeing 'real' numbers using netscape and other ftp's in the >2-2.7K range, but I see much bigger numbers if I'm on my ISP site >machines. Heh. I see numbers in the range stalled-600 for netscape (often about 30, always low for netscape's home page). This may be related to the ping latency of 400-700ms and netscape's i/o strategy and the overloadedness of the ISP. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601130452.PAA10221>