Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.mel.connect.com.au!news.syd.connect.com.au!gidora.zeta.org.au!not-for-mail From: bde@zeta.org.au (Bruce Evans) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: User PPP connection is s......l......o.......w......! Date: 12 Jul 1996 08:19:18 +1000 Organization: Kralizec Dialup Unix Lines: 45 Message-ID: <4s3ul6$h0c@godzilla.zeta.org.au> References: <01bb6e37.014cfd20$38673fcb@simonh.addease.com.au> <4s1g7h$fr@anorak.coverform.lan> NNTP-Posting-Host: godzilla.zeta.org.au In article <4s1g7h$fr@anorak.coverform.lan>, Brian Somers <brian@awfulhak.demon.co.uk> wrote: > >Have you got a good DTR speed ? It should ideally be about 4 times your >modem speed - ie 115200 for a 28800 modem, 57600 for a 14400. If this >is too slow, you modem will overload the UART and you'll lose characters. Not under FreeBSD. The reverse may be true: at a high modem speed, the UART will overload the modem unless CTS flow control is used. Also, at a high modem speed, the modem may overload the buffers in the upper half of the tty driver (not the UART) unless RTS flow control is used. >Once this starts, you're in trouble. You end up re-transmitting half >the stuff, lose half of that....... Use both RTS and CTS flow control to avoid problems. >Another good reason is if you have a crappy IDE disk that likes >interrupting all the time. Because the IRQ is on the second PIC, >it's *probably* at a higher priority than your UART (disk = 2, UART >= 3/4). Once you start ftp'ing something, you do disk writes and Not under FreeBSD. To begin with, FreeBSD rotates the PIC priorities from 0-7 (0 highest) to to 3-7;0-2 (3 highest). More importantly, it discards the PIC priorities as early as possible (a few microseconds into the interrupt handler) and runs the highest priority interrupt handler (according to software priorities that are independent of the hardware ones). If it didn't rotate the PIC priorities, then this would give UART interrupts higher priority than disk interrupts as follows: suppose that a disk interrupt on irq 14 and a UART interrupt on irq 4 occur concurrently. Irq 14 is slaved to irq 2, so it has the highest priority in the PIC, so its interrupt handler is called first. The interrupt handler will run for a few microseconds before reenabling interrupts in the PIC. Then the interrupt handler for irq 4 will be called. The handler will consult a table and see that it has the highest priority, so it should keep going and not return control to the irq 14 handler. >start to drop packets on the floor. The only way I know to circumvent >this is to either buy a better drive (even a SCSI one...) or get your >UART to interrupt on IRQ 2/9. Running FreeBSD is an easier way. -- Bruce Evans bde@zeta.org.au