darrell@eeocdt.UUCP (Darrell Tschakert) (02/03/91)
HELLO,
I have just recently connected to USENET. This will
be my first posting. I hope that I have the protocal correct, but
I guess that I will be happy if this message gets out at all.
I work for a small goverment agency. We collect data from
one hundred or so field offices over 1200 baud modems. I want to
improve throughput without spending a lot of money. I have suggested
that we start to use 2400 bps modems with V.42/V.42bis.
There are, however, a few things that I must both understand and
work out. I hope that I can get some help here.
These are the problems and questions:
1) BNU uucp Protocals (x,g,f,e) on an NCR Tower 600 OS 2.01.02
- O'Reilly Nutshell books say:
a) 'x' A stream of data, no packetizing and no EC
b) 'f' A stream of data with a single checksum
However in the debug output I see packetization like below:
935/1024 945/1024 989/1024 ...
The audit side seems to block 1024 and send in smaller
yet packets of 4 - 40.
At the end of transmitting the file I see a check sum sent
and the letter G like below:
-----------------
checksum: 123a
ack - 'G'
{timeing info}
G
-----------------
c) 'e' Not mentioned.
- QUESTION:
1) If 'f' is a solid stream, then what is the grouping that I see
in my debug output.
2) I have never seen 'e' documented. What is it supposed to be. I notice
that it is a lot like 'f' but a bit faster. However it fails more
often than 'f'.
3) Better yet can anyone define then next four?
a) 'x'
b) 'f'
c) 'e'
d) 'g'
- My FINDINGS WITH RESPECT TO UUCP'S PROTOCALS:
* I find that f usually works sending and receiving files.
* I find that e failed sending certain files on older Multi Techs
2400 modems using MNP5 or LAPM. (Didn't try MNP4 alone). Short
ascii file make it but some 68020 executables don't make it.
* I find that e fails recieving files on Couriers HST's and MultiTechs
old and new (MNP5 and V.42/V.42bis).
NOTE: Although the protocals seem to fail it is at least
sometimes the case that the file is actually sent
and built in the spool directory. I can do a
sum on the temp file and I see that it is OK.
But the final 'C' is never sent.
The local computer waits until it times out at
which time I ultimatly loose the file.
* Both 'e' and 'f' seem to send data in 1024 byte blocks.
* What follows is an edited example of the uucico -x9 output
using 'e':
I have listed both the local and remote end's output.
***************************************************************
BEGINNING OF THE TAIL END OF UUCICO -X9 OUTPUT USING PROTOCAL 'e'
***************************************************************
setline - R
wrktype - R
wmesg 'R' /usr/bin/uuset /tmp/uuset darrell -dc dummy 777 darrell
rmesg - 'R' got RY 777
PROCESS: msg - RY 777
RCVFILE:
ask 20 erdblk timeout
cntrl - -1
omsg "OOOOOO"
send OO 0,omsg "OOOOOO"
imsg >^M^JNO CARRIER^M^Jexit code -1
Conversation Complete: Status FAILED
TM_cnt: 1
tm_name: /usr/spool/uucp/mr_ed/TM.06082.000
*******************************************
BELOW IS THE AUDIT FROM THE OTHER END
*******************************************
RCVFILE:
Remote Requested: mr_ed!/usr/bin/uuset --> eeoca!/tmp/uuset (darrell)
msg - R
W_FILE1 - /usr/bin/uuset
requestOK for Loginuser - nuucp
chkpth ok Loginuser - nuucp
wmesg 'R'Y 777
ewrdata write 293
ewrmsg ret 293
-> 293 / 0.016 secs, 18312 bytes/sec
rmesg - 'C' erdmsg read failed
got FAIL
cntrl - -1
omsg "OOOOOO"
send OO 0,omsg "OOOOOO"
imsg >^POOOOOO^@ret restline - 0
exit code -1
Conversation Complete: Status FAILED
TM_cnt: 0
*******************************************
END OF AUDIT FILE
*******************************************
Note that the file was sent and the transmit timings were
even calculated.
QUESTION:
1) Why does UUCP hang waiting for the 'C' in the above example.
Put another way, why is the 'C' not send.
1) Does anyone use an NCR Tower 600 or similar system with
BNU UUCP and 2400 baud modems providing V.42/V.42bis?
If so what protocal. Does it ever hang for you?
2) Does any one use Multi Tech 2400E's or 2400H7's with UUCP?
3) Where can I get the definitions of all the terms used in
uucico's debug output? Terms like rmesg, wmesg, imsg, ... ?
2) Maybe there is a better way.
When I first started looking into data compression in
modems, MNP4 was just being replaced by MNP5. By the time I got
some MNP5's tested, V.42/V.42bis modems were available. Perhaps
there is now a still faster protocal that I could use without
spending extra money. I know about V.32 and V.32bis but I don't
have that kind of money for all the offices. I had hoped to put
V.32's with V.42/V.42bis on the central computer and 2400 bps
Multi Tech's with V.42/V.42bis on the field office computers.
I could then slowly replace the field offices modems with V.32's
as the price drops and the need arrises. I am quite certain that
V.32's will sell for $300 and less in a year or two.
My understanding was that all these modems should talk
to each other but I seem to have been wrong. I call our V.32
Courier with a Multi Tech 2400H7 at 2400 bps and get LAPM at
1200. I call th Courier V.32 with a Hayes V series 2400 and get
LAPM 2400 but when I call Mult Tech 224E7 with V.42/V.42 bis
I get MNP at 2400. If I call one of our Courier HST 14400's
with the Hayes V series 2400 using V.42, I get MNP at 2400.
QUESTIONS:
a) Can someone tell me what I should expect. Should I
not expect modems with different brand names to connect
using what are concidered standard protocals.
b) What can a Multi Tech 224E7 using V.42/V.42bis at 2400
talk to in V.42/V.42bis mode. The people at Mult Tech were
of very little help. They told me to disable the error
correction bacause the UUCP 'g' will handle it for me.
True but ... .
c) I have one Itel V.32 for evaluation. Has anyone
ever connected at 2400 V.42/V.42bis to an Invel V.32?
d) Can I get more bang for my bucks. I intend to spend
about $300 each for 50-100 2400 V.42/bis field modems
and $700 each for 3-6 V.32 modems with V.42/V.42bis.
Any suggestions on another technology, method, standard,
etc. that would cost roughly the same and give me more.
I could go on and on but this will do for now. Send mail
or reply here. I usually read this group's news and will
watch closely for a couple of weeks. Or call me in D.C.
if you are local. If you are not local, then I could
call you if you like.
Thank you for your time.
Mail to uunet!eeocdt!darrell
or call (202) 663-4436
Darrell of Washington D.C. EEOC Fed Gov.