From: MERC::"uunet!WKUVX1.BITNET!MacroMan" 16-JAN-1993 15:04:20.41 To: MACRO32@WKUVX1.BITNET CC: Subj: Re: Need faster async board...dlv11-J? Something else? In article <565014@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes: > jeh@cmkrnl.com writes: >> In article <1993Jan13.015901.4885@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes: >> > In article <1993Jan12.074046.1138@cmkrnl.com>, jeh@cmkrnl.com writes: >> > I'd advise against it on the DHV. The DHV is "run" by a pair of 8031 micro- >> > controllers (like in an LK201 - you get the idea). They will wedge up and > > 8051s according to the DHV11 tech manual. > >> The UART chips could handle the increased speed but indeed the DHV can't. In >> fact, according to the DHV manual, you can program it for 38.4 kbps, and it can >> receive at that rate, but the DMA transmit logic on the board can't go that >> fast -- if you program it for 38400 individual characters will be emitted at >> that speed but there will be gaps in between for a net throughput of 2000 >> char/sec. > > By a funny coincidence, I was taking a break from researching this exact > question for someone else when I started reading this thread.... > > Some general info on the DHV11: > > 4xSC2681 DUARTs (serving two ports each) > 2x8051 microprocessors > 256 entry silo (for received chars, dataset status changes and diags) > [...] Gee, Don, sounds like you're reading from the exact same DHV11 manual that I was. > [...] > In practice, this means that 19200 is as fast as the damn thing will go > for output (it'll send at 38400, but there will be gaps between > characters). I believe I said that. In fact, I know I did: > > The UART chips could handle the increased speed but indeed the DHV can't. In > > fact, according to the DHV manual, you can program it for 38.4 kbps, and it can > > receive at that rate, but the DMA transmit logic on the board can't go that > > fast -- if you program it for 38400 individual characters will be emitted at > > that speed but there will be gaps in between for a net throughput of 2000 > > char/sec. > > > > So hacking the DHV is indeed pointless. (Not maybe, but definitely!) Don again: > It'll receive at 38400 OK, but you'd better have those QIOs > ready to take the data real fast.... This is true and it is a major bottleneck with uucp. (lest we lose sight of the fact, I should mention that the original question had to do with running a port fast enough to keep a Telebit WorldBlazer busy. Telebit claims a basic 'data pump' throughput of 2800 char/sec, and it uses V.42bis compression, which can hit up to about 4:1! This means that the modem will can move at least bursts of data at over 100000 bits/sec! Which is why they equipped it with a serial port that'll run at up to 115.2Kbits/sec.) The problem when reading data from the uucp data link is that you have to queue *two* read requests. First you ask for six characters -- the packet header. Then you look at the packet header and see if it's the header for a data packet. If it is, you then do another $qio read to get the data segment of the packet -- using the data length indicated in the header. If not, you queue up another six-byte read to get the header of the next packet. (Control packets consist of just the header.) This means that, without doing some fairly advanced cheating, you can't possibly have multiple reads queued up at once. I do try a read-ahead optimization: When I read the data segment, I use the $QIO sensemode to get the number of characters in the typeahead buffer. If that's at least equal to the data segment size plus the six bytes for the *next* packet header, I then do a $qio read of that many bytes. However with a regular PEP modem at 1400 char/sec throughput, this doesn't "hit" very often. So we end up doing *three* QIOs to read a packet (two to read the packet and one to send the ACK for it). This is even worse than it sounds. According to some of the terminal driver experts in VMS engineering, if you have a read (with no echo, no uppercasing, no terminator character, etc., the simplest type of read, which is what uucp does), queued when data comes in, it gets put directly in the system buffer associated with the read request. But if not -- which is the case with uucp -- the data gets shuffled through the typeahead buffer first. So we are making the terminal class driver do extra work. At present, on even a MicroVAX II-class CPU, we can keep up pretty well with a PEP modem (1400 char/sec), but these new WorldBlazers are going to need better code. What do I mean by "advanced cheating"? I could go on for several pages -- I've looked at a lot of possibilities. There are several ways that we could do this a little better at GREAT cost in code complexity. For starters, we could figure out when we were *probably* going to receive a stream of data segments one after the other, and fetch them with reads with one-second timeouts. Then at the end of the stream of data packets we'd just have a one-second (at most) delay before the driver timed out and gave us the six bytes for the control packet. However, adding this to the uucp protocol engine would NOT be easy, especially when error recovery is allowed for. A much better approach is to do a terminal class driver with a better interface for this sort of work, and switch to it (much as NODRIVER is switched in for dynamic async DDCMP) when uucp grabs the port. Which I'm working on. > Speed settings are a bit funny. The four DUARTs have two groups of > speeds. The speeds supported are: > > 150 B > 300 A & B > 600 A & B > 1200 A & B > [...] > Looking at an old version of YFDRIVER (DHV/DHU port driver)... the only > speeds it will set are the group B ones [which excludes 38400]. To enable > 38400, you'd have to hack the driver. [...] > If you set a port from a group A speed to a group B speed (NB: the speed > values are a four bit value; the group is not set explicitly) and the > other port in the pair is set to a speed not supported in the new group, > it will also change speed as follows: > > Original speed New speed > 50 75 > 75 50 > 150 200 * > 1800 7200 > 2000 1050 * > 7200 1800 > 19200 38400 > 38400 19200 > > * ???? That's what the book says. > > Anyway, I might have a go at fiddling the driver to support 38400 (if I > can find a terminal that will go that fast!) and see how things get on. > > -- > Don Stokes, ZL2TNM (DS555) don@zl2tnm.gen.nz (home) > Network Manager, Computing Services Centre don@vuw.ac.nz (work) > Victoria University of Wellington, New Zealand +64-4-495-5052 I really don't see the point. Even if you do this the actual throughput for writes won't exceed 19.2kbps. This is (according to the manual) a limitation of the on-board DMA logic, so nothing you do to the UART chips will get around this. You certainly can't test read throughput to 38,400 bps unless you are planning to type VERY damn fast. --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA drivers, internals, networks, applications, and training for VMS and Windows NT uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG Internet: jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com Uucp: ...{crash,eisner,uunet}!cmkrnl!jeh