response 25 of 73:

Mar 9 08:26 UTC 1995

My experience has been the other way around. MNP modems have trouble 
establishing a connection to non-MNP modems. The MNP tickler is seen
as a break by the non-MNP modem. That's why I turn off MNP when 
connecting to Grex. I would stop doing this if I had a shot at
establishing an MNP connection and saying goodbye to line noise.

response 27 of 73:

Mar 10 08:17 UTC 1995

I thought the reverse of #26 was true? I have to turn off extra
stuff or I can't connect. I've never had a lick of problem using
other of my modei (really plain) connecting to any of the high
power stuff - even at 300/1200.

response 29 of 73:

Mar 11 21:09 UTC 1995

 
re#17:  great!!!

re MNP/non MNP modems -
I have not had problems on my work machine (2400 non mnp) connecting to
any modems, 2400 - 14400.
at home, however, I have had to disable error corrections when connecting
to some 2400-only modems.  I don't know if I have this problem with grex,
I use two dial strings (one which includes a turn-on command, the other
a turn-off command) and just select the appropriate one depending on the
speed of the modem I'm calling, I don't bother waiting to see if I have
a problem anymore.

so I'd say go for the MNP modems - the protocols can usually be 
successfully turned off if there are any problems.

anyway, if people did have these problems connecting 2400 modems to HS
modems, it would possibly preclude going to 14400 at all here.

response 31 of 73:

Mar 19 00:40 UTC 1995

I'd like to ask board members to re-read response 17 of this item.
It contains the minutes from the plan-the-budget meeting.  We will
be voting on these items at Wednesday's board meeting.

I'll send email to chelsea and tsty asking them to link this to newcoop.

response 33 of 73:

Mar 22 13:56 UTC 1995

I urge that serious consideration be given to a terminal server.

The ALM-2 card is definitely not a viable long-term solution,
and even in the short-term, it's not clear it's a good
solution.

Modems with MNP or other forms of compression/error correction
will need RTS/CTS, yet these lines are only present on the first
four ALM ports.
[1]     Even if the ALM card *does* work, it can't
        be expanded past 4 ports.

The ALM board has little intelligence on it;
it's essentially just dma channels, counters, receive fifo,
and uarts, and that's it.  Receiving characters is essentially
character-at-a-time, it eats into CPU time, but the
time is not readily apparent, because it's accounted to the
currently running process, not the process that will
ultimately read the data.  I did measurements on a sun-3
a long time ago to measure this load (caveat: grex may
perform differently):
                raw     cooked
        input   319     546
        output  41      46
                (microseconds per character)
Assuming 28.8k connections on all 4 ports, and
disregarding any 2400 baud connections, that means
50% of the system will be spent merely in
writing output out.  In essence, the 28.8k ports
will be equivalent to throwing half of the CPU away.
Only one kermit transfer (raw input mode) will suffice
to eat 90% of the system, which may be regarded
as a feature by those people wishing ill of grex.
While output processing can be, to some extent,
postponed, the same cannot be said of input.
I leave it to your imagination what 2 incoming
kermit transfers will do.
[2]     High speed modems will burden the overloaded system.

Some of this overhead is already visible - here's
one crude experiment I tried.  I held the space
bar down on the console.  The visual characteristics
of the ambassador terminal are such that, if
the characters are echoed in a timely fashion
they'll generate a smooth "comet"s trail across
the screen following the cursor - the ghost
of where the cursor was.  In fact, the ghost
is jerky, with weird random skips.  The much
more primitive console usart driver can only
respond when the tty interrupt latency permits
on the system.  Those delays are due to the current
2400 baud modems, incoming ethernet traffic, and
disk.  High speed lines will make those delays
worse, they will increase load visible to every
user, and they will, especially, show those delays to the
users on the high speed modems.
[3]     High speed modems will make current & future system load
        much more visible.

There is no reason to expect the ALM-2 card will
necessarily work at all well.  The CTS/RTS support
was not designed for high speed modems, but instead,
for a variety of high speed printers & terminals.
When you push software beyond its design limits,
you start to show the true mettle of its designers.
Sometimes, it just stops working entirely.  Sometimes,
it just does random weird twitches.  And sometimes, it
just keeps on working.  We can see that today on gryps,
which is still not as reliable as we would like.
We can see that today on grex, where the 2 gig drive
(much larger than any the designers of SunOS had
envisioned) doesn't quite work right.  Sun has sort of
a reputation for botching serial cards - it took them
a long time to get the zs driver working right, and
you'll note we have an ALM-2 card (want to guess what
happened to the ALM-1?)  There are some incredibly
ugly wait loops that have to do with terminal settings
and waiting for output to drain.  There could *easily* be
timing windows w/r/t ioctl & rts/cts flow control that could
hang the system.
[4]     High speed modems may not work at all,
        or may break the system.

A terminal server helps on all these grounds.
It scales better (buy more).
It offloads much character overhead.
It transfers additional load from preemtive hardware
        interrupts, to postponable user load.
It does not exercise existing equipment in new and "interesting"
        ways, so is less likely to break.
If it does break, it's just the terminal server, not all of grex.

One other recommendation.  Put the high speed modems on their
*OWN* separate trunk group.  High speed modems will not answer
2400 baud lines the same; it is highly probable that existing 2400
baud users will get bizarre or ugly behavior that may be difficult
to deal with.

response 35 of 73:

Mar 22 15:07 UTC 1995

Just for your information Marcus, you asked "want to guess what happened
to the ALM-1?". I can tell you, we were using 1 on the old Sun-2.
The Multibus Systech card, mounted in a Multibus/VME adapter and installed
in a VME Sun-2 or Sun-3 is what Sun designates as an ALM-1.

response 37 of 73:

Mar 22 22:46 UTC 1995

At 2400 baud, MNP still buys a share in the rts/cts game.  That means
all but the loading problems I mentioned above.  I don't think the
tradeoff of lag for noise is worth the headache.  Having incompatible
modems on one trunk hunt sequence is a Bad Thing.  It's one those
lose-lose propositions.  If we're going to buy fast modems expecting to
limit them to a slow speed, we had better make sure that the modems we
buy can, in fact, do that.  On the other hand, if we're buying modems
with the expectation of buying more and more, it's kind of silly to stop
half-way.  It makes more sense to buy the fastest modems we can now, so
we can keep buying more of the same and stay on that plateau with many
of the same thing.

I guess, what I'm saying here, is before just going out and buying new
technology, we ought to stop and ask:
        where do we want to be a year from now?
        how can we get there most efficiently?
Here is where I'd like to see us:
        one or two terminal servers
        8-16 high speed modems
        single trunk hunt group
        sun-4 cpu & etc.
I think this is both nearly ideal, and very doable.  With the direction
I see people talking about, I see us instead spending that same effort,
or indeed, probably *even more* effort, to get:
        no terminal server
        4-6 low speed modems
        2-4 high speed modems
        sun-4 cpu maybe.
I think that would a waste and shame.

response 39 of 73:

Mar 23 09:12 UTC 1995

There are 2 costs with a heterogeneous modem pool: (1) support and
configuration - each new kind of modem (in general) requires slightly
different switch settings, the dumb mode strap is in some new dumb
location, and sometimes cabling can be a problem.  Asssuming workable
modems, these are not big problems, but they are not optional or
insignificant, and having multiple kinds of modems definitely increases
the chances of a screw-up.

The other cost is in terms of incompatibilities for users.  Not all
modems work the same - but if you have a homogeneous pool of modems, the
only users you lock out, are the small set of users who can't talk to
that one brand of modem.  If you have 3 brands, then you are limited to
that set of users who can talk to all three brands reliably.  Now, we
all know there are modem standards, and any modem that follows the
standard should, in theory, be able to talk to any other modem that
meats the standard, but in this case, practice isn't as nice as theory.

Let me give you a practical example from history: once upon a time,
M-net had a mixture of 2 kinds of 300/1200 baud modems: Hayes smartmodem
1200's, & Vadic 3451's.  Both excellent modems, for the times.  And both
different.  The hayes was programmed with 8 dip switches from the front.
The vadic was programmed with at least 3 banks of dip switches contained
inside the modem.  The hayes tied pins 6 & 8 together - and the initial
batch of null modem cables we made up tied 6-20 both directions.  The
vadic did pin 6 & 8 differently, and pin 8 was the one you wanted to
use.  The vadic, now, was much more different than anything on the
market today - but it did contain some nifty options - such as the
ability to disable test mode, that the Hayes 1200 of the time simply did
not allow.  So, to make any use of the Vadic at all, it was necessary to
read *carefully* through the whole manual, before setting the switches.
*And*, it was necessary to use the Right Cable.  I got to be the lucky
person who read through the manuals and figure out what kinds of cables
to use.  And so things Worked, more or less.  Inevitably, there were
problems.  Cables would get swapped around, and modems would get hooked
up wrong, such that Vadics would end up on 6-20 connects, and spew their
login prompt out before carrier was established.  Ok, so that's just
ugly.  Every so often, a user would be found who had tried to connect to
m-net, really wanted to be on m-net, but couldn't - because 50% of the
time, her el cheapo import modem couldn't connect.  Chances are, there
was something about either the Hayes or the Vadic that her modem didn't
like.  Since it didn't connect, it wasn't even really possible to tell
which kind was the bad combination.  The situation *did* work, but it
was *clearly* sub-optimal.  It was twice the administrative headache,
for somewhat worse useability.

M-net has ever since flip-flopped.  Subsequent to that, it got upgraded
to all Courier 2400's.  Subsequent to that, it got a mixture of Supras
2400's, which were mostly not too bad.  Somewhat after that, it got a
mixture of some hodge-podge of other types - which is about the time I
went in other directions.  I gather today that M-net is running a
homogeneous pool of all GVC's - which makes me think they got disgusted
with the hodge-podge, and upgraded everything to all one type.

response 41 of 73:

Mar 23 22:48 UTC 1995

The story behind the GVC modem is that GVC is an EOM for several different
companiies, so they have not been too consistent with how the modems look.

That being said, the GVC modems seem to miss an occasional bell/whistle, but
have some very extensive configuration options.  There is a dumb jumper
hidden behind a front panel (you can hide you dope in there too, man !!! :))
and the various soft settings are quite extensive.  It should be no trouble
to configure them for 2400 stupid mode, w/o any MNP or V. protocols.  If 
I get the time I may copy the quick-ref card and give it to somebody on a
Grexwalk, although not this weekend.

response 43 of 73:

Mar 24 03:28 UTC 1995

   While I share at least some of Marcus's concerns about putting
higher speed modei on the ALM-II card, I think we should try it out,
and see what happens.
   I think it's likely that we're going to want to keep them at
2400bps until we get a terminal server, but if we put one or two
modei at the end of the trunk hunt at high speed, we can always
test things and really see what happens.  If it fails miserably,
fine!  We can drop back down to 2400bps and keep it there.  Even
at 2400bps, I think we'll have people who are glad to be able to get
on that way rather than fight a busy signal for the extra 39 minutes
it would have taken with only six dialin lines.
   But I agree what getting a terminal server is an important thing.
Getting the faster SPARC up is higher priority I think, but after
that and news gets up, the terminal server needs to be up there.

response 45 of 73:

Mar 24 05:59 UTC 1995

   I've spent up to 1:12 trying to dial into Grex.  The third time
I saw that I'd spent 39 minutes attacking dialing, that number sunk
into my head.

   Another comment, about getting te GVC modei: they're $100 now,
and we know they have a good track record overall.  I'm not so sure
about V.34 yet, although we're approaching the point (I hope) where
that won't be much of an issue anymore.  So, we can spent $100/modem
right now for potential 14.4Kbps access, and a year or so, spend
another $100/modem for V.34.  And, if we continue to add dialins,
I think we could quite reasonably have two banks, one at 14.4K and
one at 28.8K.

response 47 of 73:

Apr 10 19:53 UTC 1995

Thank you for the clarification, jep.  Sorry, mdw, but the consensus seems
to be to wait on th eterminal server.  I hope that those latest posts there
have alleviated the bulk of your concerns.  I view you as a aluable member of
the Grex community, and I hope you continue to add your views to the
discussions here.  The fact that you seem to disagree with the prevailing
views so often forces us to think carefully about the problems with our
ideas, and to plan for the various doomsday predictions, or variations thereof.

response 49 of 73:

Apr 11 02:40 UTC 1995

        I hope I haven't said anything to make anyone believe I disagree with
Marcus about the value of terminal servers.  I wish we'd gotten terminal
servers for M-Net, rather than internal 8 port cards.  We would have, if
we could have afforded them two years ago when we were spending ourselves
broke replacing the Altos because it didn't work any more.  We now have 3
free serial ports; when we use those up, we will have to go with 16 port
boards or else terminal servers, and we are well-nigh certain to go with
terminal servers.  We are out of slots in the 486.