Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!gatech!news.mathworks.com!news.kei.com!nntp.coast.net!dispatch.news.demon.net!demon!awfulhak.demon.co.uk!awfulhak.demon.co.uk!awfulhak.demon.co.uk!not-for-mail From: brian@awfulhak.demon.co.uk (Brian Somers) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: User PPP connection is s......l......o.......w......! Date: 15 Jul 1996 06:09:16 +0100 Organization: Coverform Ltd. Lines: 64 Message-ID: <4scjps$92@anorak.coverform.lan> References: <01bb6e37.014cfd20$38673fcb@simonh.addease.com.au> <4s1g7h$fr@anorak.coverform.lan> <4s3ul6$h0c@godzilla.zeta.org.au> NNTP-Posting-Host: localhost.coverform.lan X-NNTP-Posting-Host: awfulhak.demon.co.uk X-Newsreader: TIN [version 1.2 PL2] Bruce Evans (bde@zeta.org.au) wrote: : 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. I don't seem to understand your response. If you've got a DTR speed that's greater than the modem speed, then yes, you need HW compression - but without HW compression, and with an equal DTR & modem speed, you've got a situation where by the time you read your character from the UART, it's already been overwritten. In the other direction, you've got a situation where your modem is being starved. : >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. Yep. : >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). I'm glad to see it :-) : 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). [reasons for UART interrupt getting in first deleted] Does this mean that FreeBSD allows the interrupt handler to get preempted ? If so, I'm *very* impressed. Or is it a FreeBSD standard that says that interrupt handlers need as many preemption points as possible ? : >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. Doing both is the best way :-) I've actually seen this IRQ priority problem on Windows NT - *not* FreeBSD. But I also had reasons to believe that FreeBSD didn't use PIC priorities and *assumed* that interrupt routines didn't get preempted. Hence my original suggestion. This is clearly not the case. -- Brian <brian@awfulhak.demon.co.uk> Don't _EVER_ lose your sense of humour....