andyd@pogo.wv.tek.com (Andy Davidson) (07/14/90)
What is the maximum speed at which one can use the serial port on a Sun (particularly the 4/65 if that matters)? We have heard 19.2 Kbaud and 38.4 Kbaud --- both from Sun people --- and would like to know what has actually been done successfully. (We would actually like much higher speeds, but....) Andy Davidson Toolsmith-in-residence Tektronix (503) 685-3033 Internet: andyd@pogo.WV.tek.com uucp: ...!tektronix!pogo!andyd
bob@morningstar.com (07/17/90)
Under 4.0.3, termio(4) and <sys/ttydev.h> agree that 38400 is as high as you can go unless you get more clever with EXTA or EXTB than getty may be able to handle. 4.1's termio(4) says the same, but I don't have the 4.1 <sys/ttydev.h> on line to check for agreement.
ballen@csd4.csd.uwm.edu (Bruce Allen) (07/17/90)
>What is the maximum speed at which one can use the serial port on a Sun >(particularly the 4/65 if that matters)? We have heard 19.2 Kbaud and >38.4 Kbaud --- both from Sun people --- and would like to know what has >actually been done successfully. (We would actually like much higher >speeds, but... I looked into this about a year ago for my 4/60. I noticed that my printer (Apple LaserWriter IINTX) was rather slow at printing 1 Mbyte postscript files. It took about 15 minutes. After a bit of head-scratching, I realized that this was almost entirely due to the slow 9600 baud serial link. I reset the printer baud rate to 38,400 baud and set port a to run at the same speed, and sure enough I can now print the same file in four minutes. When I told some people at Sun that this was possible, I got several suprised messages. Apparently no one had tried to do it... The printer will go up to 56Kbaud, so if one can run the port even faster, I would like to know about it. Bruce Allen
neil%zardoz.uucp@ics.uci.edu (Neil Gorsuch) (07/18/90)
In article <9920@brazos.Rice.edu> andyd@pogo.wv.tek.com (Andy Davidson) writes: >What is the maximum speed at which one can use the serial port on a Sun >(particularly the 4/65 if that matters)? We have heard 19.2 Kbaud and >38.4 Kbaud --- both from Sun people --- and would like to know what has >actually been done successfully. (We would actually like much higher >speeds, but....) With our SCSI based serial port expander, baud rates can be any arbitrary value up to almost 150K baud. And that limit is there only because the particular RS232 drivers that it uses starts to produce triangle waves rather than square waves 8-). [[Ed's Note: Please note that Neil is an employee of Uninet and as such, his opinions may be biased :). You can contact him directly for more information on this product. -bdg]] Neil Gorsuch INTERNET: neil@uninet.cpd.com UUCP: uunet!zardoz!neil MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705 PHONE: +1 714 546 1100 Uninet, a division of Custom Product Design, Inc. FAX: +1 714 546 3726 AKA: root, security-request, uuasc-request, postmaster, usenet, news
guy@uunet.uu.net (Guy Harris) (07/20/90)
>Under 4.0.3, termio(4) and <sys/ttydev.h> agree that 38400 is as high as >you can go unless you get more clever with EXTA or EXTB than getty may be >able to handle. EXTA is another name for 19.2; EXTB is another name for 38.4. The speed field is 4 bits long; what you see is what you get, and there ain't any more speeds supported by the asynchronous-mode CPU serial port driver, nor by the ALM-2 driver (I think the ALM-1 driver is stuck - the board doesn't even support 38.4).
henry@zoo.toronto.edu (07/24/90)
>With our SCSI based serial port expander, baud rates can be any arbitrary >value up to almost 150K baud. And that limit is there only because the >particular RS232 drivers that it uses starts to produce triangle waves >rather than square waves 8-). If one is being picky, one should note that that speeds beyond about 38400 are violations of the RS232C spec, which sets a limit on the speed of the transitions from positive to negative. Even 38400 is marginal, actually. Old RS232C drivers seldom implement the transition-rate-limiting, though, and with short cables and forgiving conditions the high rates generally will work. Henry Spencer at U of Toronto Zoology henry@zoo.toronto.edu utzoo!henry
gnu@toad.com (08/05/90)
In the effort to merge BSD and Sys V, many things were done right, and a few were botched. Serial port speeds are one of the botches. Sun allocated a 4-bit field for the speed (both incoming speed and outgoing speed -- they're required to be the same). The speeds you can pick among are the same as on the PDP-11 serial ports that Unix was first written on. POSIX defined an interface that would let you set the speeds in a more portable fashion, though they too botched it by requiring portable code to use #define's like "B1200" rather than simply asking for "1200" baud. But their approach, which uses functional macros, permits the implementer to store the speed any way they want (one 4-bit field or two longwords, or any other way) and allows the transmit and receive speeds to be set separately if desired. UC Berkeley implemented the functional macros such that the "B-defines" are just the integers, e.g. B1200 == 1200, B19200 == 19200, etc. The speeds are passed in longwords and the hardware drivers see them that way. If the hardware is capable of running at 7 baud, you can set that rate; if you want 56000 baud, it's there; if you want 1500000 baud, it's there too. For hardware that only supports a fixed set of baud rates, the attempt to set 1203 baud (or whatever) can simply fail and return an error. The botch with Sun's approach is that even companies who care about providing the ability to set arbitrary speeds, cannot do so in a portable fashion. This is because Sun defined the interface between the user program and the kernel, and does not allow the information to be passed. When I asked Guy Harris about this in '88, he couldn't think of any reason that you might want to set a 'nonstandard' serial port speed, and didn't want to change it. If you have an application for baud rates beyond the PDP-11 ones, or higher speeds than 38400 baud, please send a "Request for Enhancement" in to Sun. An RFE looks just like a bug report, except they get ignored for ten releases instead of for one or two. But by mid-2005 we should have a software interface that lets us use the capabilities of the built-in hardware. John Gilmore
mo@bellcore.bellcore.com (Michael O'Dell) (08/06/90)
Now John, don't be so cynical. There are tales from the mists.... For one large procurement Sun was fiercely competing for, there was a requirement to do 5-bit characters, theoretically so they could do Baudot interfacing. The then-current stty interface couldn't do that, but the dark lore tells of a shell script cobbled-up using dd and adb and other mystical incantations applied to the live system which directly tickled the uarts and enable that particularly antique mode. The demo worked and the sales force went on to victory. So, while it ain't a particularly handsome way to get it done, it CAN be done, given a big enough hammer and if you don't mind the splatter. -Mike PS - yes yes yes, a particuarly base example of Turing Equivalence. But then, how many jobs for Turing Machine Programmers do you see in the newspaper????
guy@uunet.uu.net (Guy Harris) (08/10/90)
>When I asked Guy Harris about this in '88, he couldn't think of any reason >that you might want to set a 'nonstandard' serial port speed, and didn't >want to change it. Err, no, he didn't say he couldn't think of a reason why you wouldn't want to set a 'nonstandard' serial port speed, he said that the example you gave of a reason why you might want to do so - a MIDI port - might also want a different line discipline and perhaps even changes in the low-level serial port driver (does MIDI use the same character framing as an asynchronous serial line?). Part of the concern was with getting AT&T to buy into the interface; if the price of getting S5R4 to have a reasonably pleasant tty driver was to keep the way speeds were stored similar to the way S5 did them, it's a price I have no problem paying.... I don't know that AT&T wouldn't have bought into an interface like that, but frankly I was too fatigued to even contemplate trying to hard to get them to do so.