[comp.sys.3b1] Update - trying to get HFC to work at 19200

mhw@fithp (Marc Weinstein) (05/06/91)

To all those who are still interested...

In my last postings, I stated that a friend of mine and I had tried to get
two Practical Peripherals 9600SA modems to talk, transferring files with
a port rate of 19200.  We were only able to talk consistently at 9600 baud
port rates, but had a lot more to try.  As stated before, we use the UUCP
'e' protocol and V.42bis, so we get a consistent 960Bps transfer, not bad,
but not the best.

[BTW: If anyone has purchased one of these modems, do yourself a favor and
call the company to get the latest PROMs.  We obtained some V3.31 PROMs from
them, and they make a world of difference - quicker connects (protocol
negotiation) and less DCD problems causing lost lines.]

Well, my friend installed 3.51m (giving us 3.51m on both ends) and we gave
things a try at 19200.  No luck - same problem.  UUCP would get hung during
file transfer - it appeared as though the connect bit stream was still too
fast for the 3b1 port to keep up (tty000).  We had almost given up.

Then, just to see what was going on, we wrote a program to check the port
configuration using an ioctl() call.  We would run it before, during, and
after various types of calls.  What we found was that the Hardware Flow
Controroruse the  the  em to auencwas NOT getting set!!!  Even if we checked immediately
after calling the /etc/hfc_ctl program, the use was NOT set.  This is a
bit surprising, since I've seen postings which say that this program does
its job.  What we're seeing is that it either has no effect, or is doing
something whicici
buffer.  Rave revi f f vo208 (t (t ine ine ipesT
tl aldecallng ng nag2bienne).'Impouldouldo@fi1m1m1
rom
rn ubaIwas NOwas NOwce otine i

YBart rat rate t
t st st92alk  wi g sZ;ZratjoMo!208ONNE
the state of the bit, since if it's polset to begin with, it does NOT
set it at this point).  The bit would remmn set n)Pg the call and would
remamposet followiRa

We then tried the same for incoming calls.  No luck.  Apparento wo uugetty
reconfigures the portudu it does NOTZrcognize the Cem CD paramet
the gettydefs file (rur
getty seems to recognize this bit, but that does us po good.  hat  , our only
option at this point was to  (t e a daem!2running whic
bi).very ten seconds or so.  That wouldnne) be bad, but it couldnnt 
guarantee that the bit w

hat  , we've now gotten hold of the new getty which was posted to the net
(thank you, Paul Sutcliffe).  This getty apparently suppor.3i Ceon:! and
a number of other goodouldongs, so we're wor
as though once the bit is set (by getty, rather thalli	ur kluge) it will f tay shrough outyVg calls.  h frid HFC would always ;Zon.  The other
thiRa
modem, whic
connection to the rate of the incomiV
matched DTE-DCE speeds for incomiV

The other possibility is a patch to the kernel we just got hold of whic
increases the frequency of the kernrur's polling of the I/O interrupt
buffer.  Rave reviews accompae m
markings all over it.

I'll post more when we find um morer.nless sllsnone tells me to shut up.

-- 
Marc Weinstein
{simon,royk fridtellab5}!linac!fithp!mhw		Elmhurst, IL
-or- {internet host}!linac.fnal

guest@geech.ai.mit.edu (Guest Account) (05/07/91)

In article <1991May6.021315.25208@fithp> mhw@fithp (Marc Weinstein) writes:

   something whicici
   buffer.  Rave revi f f vo208 (t (t ine ine ipesT
   tl aldecallng ng nag2bienne).'Impouldouldo@fi1m1m1
   rom
   rn ubaIwas NOwas NOwce otine i

   YBart rat rate t
   t st st92alk  wi g sZ;ZratjoMo!208ONNE
   the state of the bit, since if it's polset to begin with, it does NOT
   set it at this point).  The bit would remmn set n)Pg the call and would
   remamposet followiRa

What?  I don't understand this language.  The only two languages I
know are english and pig latin.  Can we have a translation?

ostroff@Oswego.EDU (Boyd Ostroff) (05/08/91)

In article <GUEST.91May6143614@geech.ai.mit.edu> guest@geech.ai.mit.edu (Guest Account) writes:
>In article <1991May6.021315.25208@fithp> mhw@fithp (Marc Weinstein) writes:
>   something whicici
>   buffer.  Rave revi f f vo208 (t (t ine ine ipesT
>   tl aldecallng ng nag2bienne).'Impouldouldo@fi1m1m1
>
>What?  I don't understand this language.  The only two languages I
>know are english and pig latin.  Can we have a translation?

I think it says "this is a sample of how well the 3B1 serial ports
work at 19200 baud with hardware flow control."  :-)

||||  Boyd Ostroff / Tech Director / SUNY Oswego Dept of Theatre / 315-341-2987
||||  Sys Admin at cboard.UUCP / Serving the Performing Arts / 315-947-6414/8N1
||||  ostroff@oswego.oswego.edu / cboard!ostroff@natasha.oswego.edu

rhaar@albert.cs.gmr.com (Robert L. Haar CS50) (05/08/91)

In article <1991May7.204341.15825@oswego.oswego.edu>, ostroff@Oswego.EDU
(Boyd Ostroff) writes:
|> In article <GUEST.91May6143614@geech.ai.mit.edu>
guest@geech.ai.mit.edu (Guest Account) writes:
|> >In article <1991May6.021315.25208@fithp> mhw@fithp (Marc Weinstein) writes:
|> >   something whicici
|> >   buffer.  Rave revi f f vo208 (t (t ine ine ipesT
|> >   tl aldecallng ng nag2bienne).'Impouldouldo@fi1m1m1
|> >
|> >What?  I don't understand this language.  The only two languages I
|> >know are english and pig latin.  Can we have a translation?
|> 
|> I think it says "this is a sample of how well the 3B1 serial ports
|> work at 19200 baud with hardware flow control."  :-)
|> 

To me, it looks like the original author was confusing the backspace
character with the rubout.

	Bob Haar  InterNet : rhaar@gmr.com 
	Computer Science Dept., G.M. Research Laboratories
DISCLAIMER: Unless indicated otherwise, everything in this note is
personal opinion, not an official statement of General Motors Corp.

bdb@becker.UUCP (Bruce D. Becker) (05/12/91)

In article <52686@rphroy.UUCP> rhaar@gmr.com writes:
|
|In article <1991May7.204341.15825@oswego.oswego.edu>, ostroff@Oswego.EDU
|(Boyd Ostroff) writes:
||> In article <GUEST.91May6143614@geech.ai.mit.edu>
|guest@geech.ai.mit.edu (Guest Account) writes:
||> >In article <1991May6.021315.25208@fithp> mhw@fithp (Marc Weinstein) writes:
||> >   something whicici
||> >   buffer.  Rave revi f f vo208 (t (t ine ine ipesT
||> >   tl aldecallng ng nag2bienne).'Impouldouldo@fi1m1m1
||> >
||> >What?  I don't understand this language.  The only two languages I
||> >know are english and pig latin.  Can we have a translation?
||> 
||> I think it says "this is a sample of how well the 3B1 serial ports
||> work at 19200 baud with hardware flow control."  :-)
||> 
|
|To me, it looks like the original author was confusing the backspace
|character with the rubout.


	The type of junk you're seeing is most
	likely the result of a damaged compressed
	file. This sometimes happens on a full
	system when blocks run out while the
	batcher is compressing an outgoing news
	batch. The compresed batch is therefore
	missing some blocks, so upon decompression
	not all of the tokens are available to
	correctly decode the data past the point
	of the missing blocks.


-- 
  ,u,	 Bruce Becker	Toronto, Ontario
a /i/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `\o\-e	 UUCP: ...!utai!mnetor!becker!bdb
 _< /_	 "It's the death of the net as we know it (and I feel fine)" - R.A.M.

mhw@fithp (Marc Weinstein) (05/15/91)

From article <100233@becker.UUCP>, by bdb@becker.UUCP (Bruce D. Becker):
> In article <52686@rphroy.UUCP> rhaar@gmr.com writes:
> |In article <1991May7.204341.15825@oswego.oswego.edu>, ostroff@Oswego.EDU
> |(Boyd Ostroff) writes:
> ||> In article <GUEST.91May6143614@geech.ai.mit.edu>
> |guest@geech.ai.mit.edu (Guest Account) writes:
> ||> >In article <1991May6.021315.25208@fithp> mhw@fithp (Marc Weinstein) writes:
> ||> >   something whicici
> ||> >   buffer.  Rave revi f f vo208 (t (t ine ine ipesT
> ||> 
> ||> I think it says "this is a sample of how well the 3B1 serial ports
> ||> work at 19200 baud with hardware flow control."  :-)
> |
> |To me, it looks like the original author was confusing the backspace
> |character with the rubout.
>
> 	The type of junk you're seeing is most
> 	likely the result of a damaged compressed
> 	file.

Nice tries, all, but the winner is...None of the above!!!

I do apologize for confusing the neters and getting people's hopes *down*!

I discovered that my posting looked fine on my machine, AND fine on my
news neighbor's machine.  We talk via 9600 baud V.42bis.  However, it was
garbled on the next machine down, which we talk to at 2400 baud MNP!!  We
discovered that this machine, a Sun Sparcstation (with plenty of disk)
didn't have Hardware Flow Control working on incoming calls.  Outgoing 
calls were fine, apparently.  We've since fixed the problem.

My guess is the lack of HFC garbled the article, but not badly enough for
the unbatcher to get confused.

-- 
Marc Weinstein
{simon,royko,tellab5}!linac!fithp!mhw		Elmhurst, IL
-or- {internet host}!linac.fnal.gov!fithp!mhw

dnichols@ceilidh.beartrack.com (DoN Nichols) (05/16/91)

In article <1991May14.232222.9790@fithp> mhw@fithp (Marc Weinstein) writes:

	[ ... ]

>I discovered that my posting looked fine on my machine, AND fine on my
>news neighbor's machine.  We talk via 9600 baud V.42bis.  However, it was
>garbled on the next machine down, which we talk to at 2400 baud MNP!!  We
>discovered that this machine, a Sun Sparcstation (with plenty of disk)
>didn't have Hardware Flow Control working on incoming calls.  Outgoing 
>calls were fine, apparently.  We've since fixed the problem.
>
>My guess is the lack of HFC garbled the article, but not badly enough for
>the unbatcher to get confused.

	So, what did the rest of the article say?


-- 
Donald Nichols (DoN.)		| Voice (Days):	(703) 664-1585
D&D Data			| Voice (Eves):	(703) 938-4564
Disclaimer: from here - None	| Email:     <dnichols@ceilidh.beartrack.com>
	--- Black Holes are where God is dividing by zero ---

mhw@fithp (Marc Weinstein) (05/19/91)

From article <1991May16.015104.21908@ceilidh.beartrack.com>, by dnichols@ceilidh.beartrack.com (DoN Nichols):
> In article <1991May14.232222.9790@fithp> mhw@fithp (Marc Weinstein) writes:
> 
>>I discovered that my posting looked fine on my machine, AND fine on my
>>news neighbor's machine.  We talk via 9600 baud V.42bis.  However, it was
>> ...
>>
>>My guess is the lack of HFC garbled the article, but not badly enough for
>>the unbatcher to get confused.
> 
> 	So, what did the rest of the article say?

Actually, what was posted then no longer applies.  Take a look at the
more recent postings.

-- 
Marc Weinstein
{simon,royko,tellab5}!linac!fithp!mhw		Elmhurst, IL
-or- {internet host}!linac.fnal.gov!fithp!mhw