Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!gargoyle!ddsw1!igloo!learn
From: learn@igloo.UUCP (william vajk)
Newsgroups: comp.unix.microport
Subject: Re: telebit on uBug 286 - update
Message-ID: <524@igloo.UUCP>
Date: 2 Apr 88 16:48:42 GMT
References: <878@nuchat.UUCP>
Organization: igloo, Northbrook, IL
Lines: 62

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