Date: Fri, 11 Jul 1997 07:35:10 -0400 From: "Brian J. McGovern" <mcgovern@spoon.beta.com> To: bde@zeta.org.au Cc: hackers@freebsd.org Subject: RE:Re: Trigger for received PPP packets? Message-ID: <199707111135.HAA22291@spoon.beta.com>
next in thread | raw e-mail | index | archive | help
[IVAN @ Cyclades. thought you'd like to see this (you might have some ideas). Also, scan for "FIRMWARE ENHANCEMENT" for a neat idea] > >>I asked this question once before a week or so ago, and didn't get a great >>response about it, so I'll try it from a different angle. > >It's probably too technical for -hackers. > Too technical for -hackers? Ick... Thats a scary thought.... >>I'm playing with serial device X, for which the driver is in a prototype >>stage... Its working fine, except for receiving PPP packets. Basically >>the data is being stowed in the clists via the l_rint routine. The problem > >ppp doesn't use clists for input. > Ok. Silly me :) But, if thats the case, and it doesn't use clists, how many characters can be l_rint'ed at a time before I have to take a break? It might just be possible that I'm sucking in partial-frames at a time. >>that I'm seeing is that a received packet is taking quite a long time >>(roughly 100 - 150ms) to get processed. A ping, for instance, on a 115200 >>serial link, takes about 347-380ms round trip. > >Apparently the driver is not delivering characters to ppp promptly. I >guess it uses huge buffers and doesn't get interrupted for packet framing >characters. > Hmm... Smells like FIRMWARE ENHANCEMENT :) Realistically, however, I don't think the RX interrupt is that far apart, and if it is, it should level itself out over time. The device will interrupt when the buffer is full, or after 3 character wait-times if no new data comes in. Therefore, for slow traffic, such as pings only, the latency should only be increased by 3 character times. For heavy-load traffic, interrupts will be generated every time the buffers fill, but then (at 8K), a handful of packets should be available, assuming I l_rint them all (see note on number of characters I can move if it doesn't use clists). Even if I don't, additional interrupts will occur when the buffer refills, or 3 character times elapse. Anyhow, this may be the core problem, and I guess I need to understand how PPP wants the data delivered a little better. (Hints, please?) >>Using 16550s, it takes about >>47-80ms round trip. Connecting the device to a 16550 yields fast throughput >>from board to 16550, but much slower from 16550 to the device (hence why >>I believe its the receive side). > >sio delivers characters to ppp within one fifo full time of receipt of >a packet framing character. This gives a maximum additional latency at >115200 bps of 14 character times (1.2 msec) for 16550's and 1 character >time (87 usec) for 8250's and 16450's. On a local line with 16550's, >ping latency should be about 16 msec for cslip, 17 msec for pppd -bsdcomp, >and 8 msec for pppd with the default of bsdcomp enabled and used. > Again, my driver should develiver within either a.) A full RX buffer, which means multiple PPP packets will be ready, or 3 character times of no reception, which will put it in line between a 16550 and the lower end UARTS (Will atually put it at 3x an 8250). I think the problem may be in that I assume I can move no more than TTYHOG bytes on an clist. But, again, this shouldn't affect small packets (ie -pings), either. -Brian >Bruce > >------- End of Forwarded Message >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707111135.HAA22291>