Date: Tue, 14 Nov 95 10:27 WET From: uhclem%nemesis@fw.ast.com (Frank Durda IV) To: current@freebsd.org Subject: Serial HW flow control [was ISP state their FreeBSD concerns] Message-ID: <m0tFODF-000J1BC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[0]6. Multi-port serial support and even single-port serial support. [0] Seems they feel hardware flow control doesn't work or isn't enabled [0] when it should be (or can't be) or both. This may actually be [0] an issue with the 16550 drivers not setting silo depth to a [0] reasonable level. Most of these guys use terminal servers for [0] the actual users where these local serial ports are used for UPS, [0] router control, serial printers, and other in-house controls. They [0] complain of seeing problems with lost data outbound when flow [0] control was in use, including during UUCP sessions. [1]I use a standard serial port for a 115.2K ISDN connection and it works [1]*great*, even better than a friend of mine who's using a Cisco for the [1]purpose and looks enviously at my 10.5K/sec FTP transfer rates when [1]he's only getting 7K. Not to say that this scales to hundreds of [1]serial ports or anything, but it does work! [2]He didn't identify hardware vs. software flow control. If software, then [2]his observation about SILO depth is well taken. Your ^S could be in limbo [2]for quite some time before it is seen. A ^Q in limbo is a much worse [2]problem, actually. Actually, I thought I did. It is HARDWARE flow control they were talking about that they say isn't working completely right. I have personally not seen the precise problem with outgoing flow control as the ISPs report, but I certainly have seen it with incoming, particularly with modems with BIG buffers, such as the Telebit WorldBlazer in UUCP Spoof mode under Turbo PEP. The fix for me was in 1.1.5.1 (and still is in 2.1) to apply a patch to uucico so that it enables hardware flow control - by default it does not, nor does it seem to have a way to activate it from the config files as was claimed when my suggested patch was pooh-poohed a year or so ago. Patching uucico IS NOT a total fix: even with FreeBSD hardware flow control enabled (verified by stty), I can't set the modem DTE faster than 38400 without overruns in both directions. This is on a 486DX33 8MB system doing little else. (UUCICO speeds are up to 2200CPS on 100K files according to the Stats file. WIthout the patch, speeds fall to 300-400CPS.) Anyway, these guys are seeing overruns driving serial postscript printers and such, which tend to flush the entire job and print a page saying "OFFENDING COMMAND" when an overrun occurs. One of the ISPs is trying to let me borrow his communications monitor so I can see exactly what they are talking about. They claim it will show that they drop CTS and the processor has sent as many as 14 additional characters after CTS was deasserted. If true, it sounds like our hardware flow control does not "call-back" bytes already in the 16550 FIFO like it should. The EIA rules for CTS allow you one more full character plus any partial character to be transmitted before the data must cease (it's been a long time since I read that stuff so that may not be phrased exactly right). I know I have a Terminet printer in the shop at my office (its OLD) and it is completely unforgiving on the issue of flow control. Extra characters overwrite the ones in its buffer when a line is being printed. Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi" or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" ...letni!rwsys!nemesis!uhclem |"A what?" ...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tFODF-000J1BC>