[comp.unix.microport] telebit on uBug 286 - update

steve@nuchat.UUCP (Steve Nuchia) (03/31/88)

So, has anyone ever gotten a response to an electronic message
from microport electonically?

I've got a telebit installed on nuchat, my long-suffering AT clone.

Works great - 9600 bps continuous throughput to/from uunet as long
as you sit there and watch it.  More specifically, as long as nothing
else is happening on the system.  Put a user or (gasp!) a 2400 bps
uucp session on one of the other lines and you're instantly hosed.

Throughput drops to <50 cps.  Long timeouts followed by short
bursts of data and then another long timeout.  Part of the
problem, to be fair about it, is that the g protocol is pretty
fragile on lossy connections, but give me a break.

Seriously - the difference is unmistakeable and happens with
any amount of traffic at all on the other lines.  If the hardware
could be conned into diddling RTS or DTR or somethine to indicate
thet its buffer is full that would probably make the telebit work,
but I haven't seen any indication that such a thing is possible.

I will take this opportunity to renew my call for interrupt-driven
driver sources for microbug.  Anything at all would be handy.
(a serial driver would be best :-)  Has anyone started the excersize
of comparing the linkkit/examples/sio.c pseudo-code with a disassembly?
Perhaps we could derive an equivalent source by succesive approximations.
(1/2 :-) -- broken code doesn't deserve legal protection)

completely unrelated ----

	anyone want to buy my copy of merge-286?
	hardly used.  make an offer.
-- 
Steve Nuchia	    | [...] but the machine would probably be allowed no mercy.
uunet!nuchat!steve  | In other words then, if a machine is expected to be
(713) 334 6720	    | infallible, it cannot be intelligent.  - Alan Turing, 1947

hedrick@athos.rutgers.edu (Charles Hedrick) (04/01/88)

>So, has anyone ever gotten a response to an electronic message
>from microport electonically?

Yes, I have sent several messages via UUCP mail, and have gotten
answers to all of them.

learn@igloo.UUCP (william vajk) (04/03/88)

In article <878@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes:

> I've got a telebit installed on nuchat, my long-suffering AT clone.
> 
> Works great - 9600 bps continuous throughput to/from uunet as long
> as you sit there and watch it.  More specifically, as long as nothing
> else is happening on the system.  Put a user or (gasp!) a 2400 bps
> uucp session on one of the other lines and you're instantly hosed.
 
> Throughput drops to <50 cps.  Long timeouts followed by short
> bursts of data and then another long timeout.  Part of the
> problem, to be fair about it, is that the g protocol is pretty
> fragile on lossy connections, but give me a break.

When I started hollaring at microport about this last November, I was
told a series of stories about how "THEIR" machine runs 4800 baud
newsfeeds with 5 other users aboard, pounding the daylights out of
the machine. Note that I refer to them as "stories".

When igloo got a telebit, I also got Karl Deninger's autobaud getty.
I have the updated serial driver from microport aboard. The 9600
newsfeed dominates this little box which has 5.5 meg of ram, 112 meg
HD's, with an entire 40 meg HD dedicated in a single partition to
/usr/spool. Checking sar, with or without other users aboard during
a poll at 9600, shows 0% idle time. The AT clown is 8 mhz 1 wait state.

My combination here doesn't get hosed, though the thruput measured from the
other end shows maybe 500 chars/sec thruput, and they have cpu cycles left
to burn on the other end running a '386 box with sco.

I never get hosed on the newsfeeds any longer. If a user happens to log
in on the other line once a newsfeed is established, they log off promptly,
as any command takes forever to execute.

Before I had this combination which mostly works, I had to change my init
state to kill the other modem, or earlier, plugged a phone in on the other line and went off hook with it to become in effect, a one line system. I am
still, in effect, a one line system during polling. One would think that with
the memory I have available, a large hunk could be cached, and newsfeeds
of say 2 or 3 meg could be dumped to ram, later transferred to the HD at
whatever speed it desires...but NO. Durn it, I'd even add another 5 megs of
ram to the box if it would help.

> I will take this opportunity to renew my call for interrupt-driven
> driver sources for microbug.  Anything at all would be handy.
> (a serial driver would be best :-)  Has anyone started the excersize
> of comparing the linkkit/examples/sio.c pseudo-code with a disassembly?
> Perhaps we could derive an equivalent source by succesive approximations.
> (1/2 :-) -- broken code doesn't deserve legal protection)
 
Someone at igloo is working on such a project. The sudden availability
of a drivers text (Hayden Books) should help. It is obvious from the
example in the link kit just how fouled up microport drivers are. Look
at the mode they select to disable interrupts, and the duration of the
disabling. BTW, uport can protect their broken code all they want. We're
pretty much starting from scratch. The only reason to even look at their
code is to determine what other stupid hooks they have in there that might
make it necessary to attack new code for other regions of the OS. I'm going
to try to get software done that has an option to dump newsfeeds into
dedicated ram, as mentioned above. These phone bills are killing me.


Bill Vajk                                                    learn@igloo

larry@focsys.UUCP (Larry Williamson ) (04/03/88)

From article <878@nuchat.UUCP>, by steve@nuchat.UUCP (Steve Nuchia):
> So, has anyone ever gotten a response to an electronic message
> from microport electonically?
> 

Yes, I've sent quite a number of bug queries to microport over
uucp and usually got a quick response. It has been a couple of
months now since I last mailed them a question, so I can't say
that they are still good about it.

-- 
Larry Williamson                      Focus Automation Systems
UUCP: watmath!focsys!larry    608 Weber St. N, Waterloo, Ontario N2V 1K4
                                          +1 519 746 4918

det@hawkmoon.MN.ORG (Derek E. Terveer) (04/03/88)

> >So, has anyone ever gotten a response to an electronic message
> >from microport electonically?
> 
> Yes, I have sent several messages via UUCP mail, and have gotten
> answers to all of them.

I have also sent several messages and have had about 1/2 of them answered.
-- 
Derek Terveer	det@hawkmoon.MN.ORG	uunet!rosevax!elric!hawkmoon!det

caf@omen.UUCP (Chuck Forsberg WA7KGX) (04/03/88)

In article <878@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
:I will take this opportunity to renew my call for interrupt-driven
:driver sources for microbug.  Anything at all would be handy.

With a few arcane exceptions, all Unix sio drivers are interrupt driven.
The problem with hish speed serial input is that other parts of the
operating system have sections of "critical code".  The usual practice
in "critical code" is to disable interrupts while the kernel is
"dropping its pants".  It takes quite a bit of kernel hacking to keep
these ciritical code segments short.

zeeff@b-tech.UUCP (Jon Zeeff) (04/06/88)

In article <524@igloo.UUCP> learn@igloo.UUCP (william vajk) writes:
>In article <878@nuchat.UUCP>, steve@nuchat.UUCP (Steve Nuchia) writes:
>
>
>My combination here doesn't get hosed, though the thruput measured from the
>other end shows maybe 500 chars/sec thruput, and they have cpu cycles left
>to burn on the other end running a '386 box with sco.
>

Another option might be to use a low cost pc running uucp to receive the
stuff at 9600 bps and the feed it to your unix machine later at a low baud
rate.  Aren't cheap pc's about $800 now?

>to try to get software done that has an option to dump newsfeeds into
>dedicated ram, as mentioned above. These phone bills are killing me.
>
>
AT&T also publishes their device driver code for the 3B things.  Look for
their driver design guide.
--Jon


-- 
Jon Zeeff           		Branch Technology,
uunet!umix!b-tech!zeeff  	zeeff%b-tech.uucp@umix.cc.umich.edu

steve@nuchat.UUCP (Steve Nuchia) (04/09/88)

From article <656@omen.UUCP>, by caf@omen.UUCP (Chuck Forsberg WA7KGX):
> In article <878@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes:
> :I will take this opportunity to renew my call for interrupt-driven
> :driver sources for microbug.  Anything at all would be handy.

> With a few arcane exceptions, all Unix sio drivers are interrupt driven.
> The problem with hish speed serial input is that other parts of the

Perhaps I should have been more clear (or at least less terse).  What
I am looking for is specifically a _microport_ driver of non-trivial
construction.  I have the ramdisk, speaker, and pty drivers.  The
pty driver is some help, since it excersizes the clist access routines
and the ioctl interfacing.  But none of these drivers do any interrupt
munging, and this is where things get wierdest (ie, least commonality
among different unix ports).  The chances of using something like
a 3B2 driver as a go-by and getting a production quality driver
for uBug are pretty slim.  (working, maybe.  good, probably not).

I am installing a machine for a client next week.  It could run
microbug.  I would prefer that it did, since I am very familiar
with microbug.  "The devil you know" and all that.  But, since
they won't support high-capacity disks and don't work properly
with the low capacity disks its out of the question.

I signed a contract with them months ago that was supposed to
get me source for the disk driver so I could make it stop
eating my disks (I'm suffering the two drive problem).  As
an additional excersize I was going to make it handle the
large drives too.  Nothing happened.  To be fair I did start
to work on fsck for them a while back, but that code is so
nasty that I stopped when I found a work-around that worked
for me.  Since then two (different) "engineers" have called
me asking what I knew about it.  I can only assume the first
one is in an assylum, and wish his replacement better fortune.
Fsck.c is a swamp: abbandon all hope, ye who would enter there.

Drivers, on the other hand, are at least shorter and more
steryotyped than fsck.  If they are worried about me not
finishing work on it they could always offer me, say, 5%
of the upgrade charges they will reap when they ship the
fixed drivers.  Of course if they never get them fixed
they can still rape us for a few more placebo updates before
we show up on their lawn with pitchforks and torches.

This stopped being funny over a year ago.  I'm real tired
of having files eaten by their broken driver.  Their defective
serial driver is costing me money - to the tune of about
a hundred dollars a month in communications cost (It won't
let me run my telebit fast).  I have offered to fix these
things for free.  They have ignored me.  If this keeps up
much longer I'll start disassembling.

I've thought about litigation, but as I understand the law
they have only to offer me my money back.  Since I never
used it for anything important (since it never worked)
I don't have any concrete damages, although if I billed them
for all the hours I've spent nursing their broken fsck through
fixing the filesystems their broken driver trashed it would
be a healthy sum.  So the probable outcome of a suit is that
I'd walk away with half as much money as I'd need to buy
the replacement system I'd need because I had to give them
theirs back to get the settlement.  I don't want a wash,
I want what I paid for - "real unix" (remember the adds?).

real unix doesn't eat disks.

So, in the absence of any sign of intelligent life from
microport, I am hoping to collaborate with someone on
writing replacement drivers from scratch.  Anyone with
anything concrete to bring to the discussion please
respond by mail.  If we can avoid contaminating the
project with any AT+T-stained code we'll all be better off,
even if it takes a little longer.
-- 
Steve Nuchia	    | [...] but the machine would probably be allowed no mercy.
uunet!nuchat!steve  | In other words then, if a machine is expected to be
(713) 334 6720	    | infallible, it cannot be intelligent.  - Alan Turing, 1947

learn@igloo.UUCP (william vajk) (04/09/88)

In article <4396@b-tech.UUCP>, zeeff@b-tech.UUCP (Jon Zeeff) writes:
> In article <524@igloo.UUCP> learn@igloo.UUCP (william vajk) writes:


> >My combination here doesn't get hosed, though the thruput measured from the
> >other end shows maybe 500 chars/sec thruput, and they have cpu cycles left
> >to burn on the other end running a '386 box with sco.

> Another option might be to use a low cost pc running uucp to receive the
> stuff at 9600 bps and the feed it to your unix machine later at a low baud
> rate.  Aren't cheap pc's about $800 now?

Well well. The only option we have to patching around the broken OS is
to go out and buy another machine to take on the tasks that microport
cannot handle ? :-) I suppose I should do that, if only to shame microport
into fixing their product. UUCP screams Unix, not ms-dos.

Igloo has been up and running for over a year. I waited, and didn't start
gritching till November 1987, almost 6 months ago. Can it be that an
AMERICAN OEM cannot fix their product in that time, assuming they *really*
wanted to ? With the success that xenix has shown on the '286 family, we know
that unix should work as advertised.

> AT&T also publishes their device driver code for the 3B things.  Look for
> their driver design guide.

Anyone have an idea where I can start looking for this ?


Bill Vajk                                             learn@igloo

zeeff@b-tech.UUCP (Jon Zeeff) (04/12/88)

In article <534@igloo.UUCP> learn@igloo.UUCP (william vajk) writes:
>
>> AT&T also publishes their device driver code for the 3B things.  Look for
>> their driver design guide.
>
>Anyone have an idea where I can start looking for this ?
>

You can get it from AT&T (1-800-432-6600).  Comcode is 305-495 ($75).  There
is also a good book out "Writing a Unix Device Driver" ($25).


-- 
Jon Zeeff           		Branch Technology,
uunet!umix!b-tech!zeeff  	zeeff%b-tech.uucp@umix.cc.umich.edu