🚀 go-pugleaf

In <D5IsvF.L2M@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: 

>
>This is an oddball setup -- it claims to support up to 32 ports, each 
at
>up to 115Kbps, off the PC's parallel port!
>
>No host adapter -- the Systech package includes a unit that plugs into
>the LPT1 connector on the PC, as well as drivers for SCO, UnixWare,
>Solaris, AIX and HP-UX. The unit has a parallel connector on it
>allowing "pass-through" of data really destined for /dev/lp. It claims
>full modem control on each port, and "terminal control" software which
>it says is "compatible with Unplug TCS", whatever that means.
>
>This sounds really good if it works, but my gut instinct tells me it's
>too good to be true. What kind of CPU/interrupt load does the parallel
>port put on the system if that many bytes are moving through it?
>
>Is the concept sound on a theoretical level? Would/does such a unit
>perform as well as a typical intelligent host adapter serial unit of
>equivalent number of ports? (The internal CPU of the Systech unit is
>a Motorola 68360, for what that information is worth).
>
>Any suggestions, experiences or advice regarding this unit are welcome.
>Thanks.
>
>-- 
> Evan Leibovitch, Sound Software Ltd., located in beautiful Brampton, 
Ontario
>        Novell Unix Master Reseller / evan@telly.org / (905) 452-0504
>       Those to my right are extremists; those to my left are heretics
>

I tested an eval unit that was an 8 port. I had to have a true 
bidirectional parallel port for operation. I then sent jobs out every 
port and looped them so they would stay busy. I then placed a printer on 
the unit's parallel port and did a nl (number line command) on the 
/etc/termcap file. I didn't receive buffer overflow and the serial ports 
didn't fail. The only drawback is that the originally named /dev/lp is 
ultimately called /dev/htty? and some applications call for the lp0 
name.

evan@telly.on.ca (Evan Leibovitch) writes:

>This sounds really good if it works, but my gut instinct tells me it's
>too good to be true. What kind of CPU/interrupt load does the parallel
>port put on the system if that many bytes are moving through it?

We have tested it (a 4-port unix) at some levels on UW-1.x and it really worked.
(Have not tested the parelle port pass-through)
Never tried to measure the CPU load. Any good suggestion as how to measure
it (svr4mon ?)

Thanh Ma
tma@encore.com

Disclaimer:  I design and build a number of competing products, and
as such, am sure to have some prejudice.

In <D5IsvF.L2M@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes:

>This is an oddball setup -- it claims to support up to 32 ports, each at
>up to 115Kbps, off the PC's parallel port!

>No host adapter -- the Systech package includes a unit that plugs into
>the LPT1 connector on the PC, as well as drivers for SCO, UnixWare,
>Solaris, AIX and HP-UX. The unit has a parallel connector on it
>allowing "pass-through" of data really destined for /dev/lp. It claims
>full modem control on each port, and "terminal control" software which
>it says is "compatible with Unplug TCS", whatever that means.

>This sounds really good if it works, but my gut instinct tells me it's
>too good to be true. What kind of CPU/interrupt load does the parallel
>port put on the system if that many bytes are moving through it?


I haven't personally evaluated the product, but I have pencil 
whipped it.  However, I"m at home right now, so I don't have access
to the notes I'd made.

The PC parallel port isn't a very smart interface at all.  THey're
not buffered at all (single byte).  Most standard PC parallel 
port aren't even bidirectional.  This means that data
coming into the PC would have to be multiplexed into the 3 or 4 
input pins (paper out and it's cousins).  Oh, yeah.  You'll have
to use one of those bits as a strobe.  This takes away some of
it's appeal as an 8 bit device and means the PC will have to reassemble
every byte that comes in.  Presumably there is some protocol overhead
(like "which port does this data belong to" multiplexed in with 
control signals, etc.) so the PC is going to have to mess with
and think about the data a lot.

I'd have to recheck the specs, but I recall the parallel interface being
very half duplex.   I don't think their mpu could write a byte to the 
host at the same time it's writing a byte to the card.     However,
since  you're obviously using different pins for input and output,
you may be able to fanagle this.

>Is the concept sound on a theoretical level? Would/does such a unit
>perform as well as a typical intelligent host adapter serial unit of
>equivalent number of ports? (The internal CPU of the Systech unit is
>a Motorola 68360, for what that information is worth).

My money sez it won't.  Even if we assume the 68360 is doing all the
opost processing and all the input processing that makes sense,
the PC has to tinker with it too much.  A well deisgned dual-ported 
memory mapped card (I won't mention names. :-) should kick it's butt 
for host CPU utilization.  

Which would you rather do to receive raw input: call copyut()
the from the card right to the users process space or call inb
(a slow opcode on current x86's) at least twice for each byte, 
and shift the bytes back together (no rep ins for you).  We'll 
assumme that it assembles them into a buffer which then does i
a copyout right to the process space.  We pray that it doesn't
pass the bytes individually.
 
A staffer at Digiboard benchmarked the product (scs-2032, rev C, 
driver version 01B).  on a Dell P90.    While I won't publish
the detailed numbers (don't ask), they were disappointing on
even a single port doing either input or output.   Expecting 
flat out 115Kbits/sec on 32 simultaneous ports is challenging, 
but not unreachable with other cards.    

I won't publish the full benchmark programs, but they are 
available on my home page at:

   http://www.digibd.com/~robertl

I encourage anyone evaluating async product performance to play 
with these.

However, I think this is still an OK idea in a situation where
performance doesn't matter, or if you have a machine that
has no ISA, EISA, MCA, or Sbus slots.  If you were trying to 
run a UNIX demo or do training sesssions on a portable and 
wanted to demo a couple of live terminals, it would probably 
do incely.

The views expressed herein are entirely those of one loudmouthed
engineer and do not necessarily reflect those of management or anybody
else.....





--
Robert Lipe    Sr. Software Engr.    Arnet Corp.     robertl@arnet.com

Evan Leibovitch (evan@telly.on.ca) wrote:
: This is an oddball setup -- it claims to support up to 32 ports, each at
: up to 115Kbps, off the PC's parallel port!

: No host adapter -- the Systech package includes a unit that plugs into
: the LPT1 connector on the PC, as well as drivers for SCO, UnixWare,
: Solaris, AIX and HP-UX. The unit has a parallel connector on it
: allowing "pass-through" of data really destined for /dev/lp. It claims
: full modem control on each port, and "terminal control" software which
: it says is "compatible with Unplug TCS", whatever that means.

: This sounds really good if it works, but my gut instinct tells me it's
: too good to be true. What kind of CPU/interrupt load does the parallel
: port put on the system if that many bytes are moving through it?

: Is the concept sound on a theoretical level? Would/does such a unit
: perform as well as a typical intelligent host adapter serial unit of
: equivalent number of ports? (The internal CPU of the Systech unit is
: a Motorola 68360, for what that information is worth).

: Any suggestions, experiences or advice regarding this unit are welcome.
: Thanks.

: -- 
:  Evan Leibovitch, Sound Software Ltd., located in beautiful Brampton, Ontario
:         Novell Unix Master Reseller / evan@telly.org / (905) 452-0504
:        Those to my right are extremists; those to my left are heretics

I would advice against using such a product for the exact reason that you
mention, the interrupt load. I have seen SCO systems that had a very fast 
line printer attached to the parallel port run *extremely* slowly 
whenever a job was printing on that printer. Stick with the intellegent 
serial boards.

--
Gerry Gilmore
Employed by (but not speaking for): Health Systems Resources, Inc.
Providing comprehensive UNIX-based Hospital Information Systems
Atlanta, Ga.      E-mail:   gerryg@america.net

**********************************************************************

  Egypt was troubled by a horrible asp......
  Mister Charles Darwin had the gall to ask.....
                                  REM 

**********************************************************************

In article <3kc47f$1q1@peach.america.net>,
	Gerry Frank Gilmore <gerryg@atl1.america.net> wrote:
>I would advice against using such a product for the exact reason that you
>mention, the interrupt load.

I have some grave concerns about the product.

There is something very troubling and cynical about the whole concept.
If a person has difficulty dealing with installing an adapter card,
they've got no business running a multi-user system.  I doubt if there
is any other async controller on the face of the planet that has a
system interface that looks like a single byte-wide I/O port, and a
second control port (some I, some O).  I suspect that if this arrangement
made sense, somebody would have done it already.  Since this arrangement
has never existed before, I can only conclude that it is suboptimal, and
compromises must have been made somewhere in order for this to work.

You cannot, however, a priori, dismiss the product due to interrupt
overhead.  First off, are you assuming that the device is interrupt
driven?  That is not a valid assumption to be made.  It could be, but
it also need not be.  The entire DigiBoard line (intelligent products,
anyway), use polling and not interrupts in their Unix drivers.  The
Systech product might be polled as well.

Further, even in the case of conventional LPT usage, I don't think
interrupt overhead or latency are the greatest problems.  The biggest
problem is the timing and handshake (or lack thereof) in the LPT
hardware.  The typical printer requires a STROBE/ width on the order
of hundreds of microseconds.  The printer driver tends to implement
this with code something along the following:

	outb(PORT_DATA, c);
	outb(PORT_CTRL, STROBE_LOW);
	for (i = 0 ; i < SOME_BIG_NUMBER ; ++i)
		;
	outb(PORT_CTRL, STROBE_HIGH);

That for() loop is called a "spin wait", because the CPU just sits
there spinning (for hundreds of microseconds) not doing anything
productive.  This spin wait overhead (hundreds of microseconds every
character) is several orders of magnitude greater than the interrupt
latency (tens of microseconds every bufferful).

Now, there is no reason why an async controller would need strobe widths
of hundreds of microseconds.  I suspect something along the following
would work perfectly fine to send a byte of data to the controller:

	outb(PORT_CTRL, STROBE_LOW);
	outb(PORT_DATA, c);
	outb(PORT_CTRL, STROBE_HIGH);

So, although you've removed the spin wait, an incredible killer, you've
still had to do three output operations to get a single byte to the
controller.  I can't see any way around this; the LPT port simply
doesn't have any latching/clocking circuitry that would allow a
(more efficient) alternative (that I can think of).

Sorry...but the entire concept of using the LPT port as a peripheral
interface is just plain goofy.  And I should know...I did such a thing
for my previous employer. :-)

I called this product cynical because you need to assume a very cynical
view of the end-user to justify the approach.  This approach has to
incur technical compromises, possibly significant.  The payback is
that the happy-go-lucky system administrator now avoids that troubling
and traumatizing task of opening up the computer case.  This is the
"system admin as incompetent moron" philosophy that gives rise to
really obnoxious products and technologies such as PS/2 MicroChannel.

I suspect there are some cases there the Systech product would be an
incredibly neat solution.  (Imagine a laptop with eight bar code wands
that could be lugged around to temporary events and such.)  I am highly
skeptical, however, as to whether it is appropriate as a general purpose
async controller.
-- 
Chip Rosenthal              "This world is full of creeps like me." -Lyle
Unicom Systems Development  For a good time: http://www.unicom.com/john-hiatt/
<chip@unicom.com>           PGP key: http://www.unicom.com/personal/chip.html