boneill@hawk.ulowell.edu (SoftXc Coordinator) (04/14/88)
With the recent posting of Mr. Petersen of DSZ 03-29, I was wondering if
anyone else has encountered a problem I've come across with every version of
DSZ I've used so far.
When using sz on our Dynix system, and DSZ (2-08 was the last one I tried)
on my PC running at 2400 baud, and I download a binary file, I get many CRC
fail errors, some timeout errors, and bad data errors every 8K or so. This
tends to slow down the progress of the download, especially when enough
errors arise to cause it to switch to 256 byte packets. Sometimes it even
aborts the download.
Is this normal for DSZ (at least the constant errors)??
============================================================================
Brian O'Neill, MS-DOS Software Exchange Coordinator
ArpaNet: boneill@hawk.ulowell.edu
UUCP : {(backbones),harvard,rutgers,et. al.}!ulowell!hawk!boneillgrandi@noao.arizona.edu (Steve Grandi) (04/14/88)
In article <6208@swan.ulowell.edu> boneill@hawk.ulowell.edu (SoftXc Coordinator) writes: >When using sz on our Dynix system, and DSZ (2-08 was the last one I tried) >on my PC running at 2400 baud, and I download a binary file, I get many CRC >fail errors, some timeout errors, and bad data errors every 8K or so. This >tends to slow down the progress of the download, especially when enough >errors arise to cause it to switch to 256 byte packets. Sometimes it even >aborts the download. > >Is this normal for DSZ (at least the constant errors)?? No, I don't think it is normal...Perhaps Dynix is doing strange and wonderful things to the serial line? Do YMODEM transfers work (128 or 1k packets)? I haven't had any trouble downloading using sz on a VAX 750 running 4.3BSD to a PC clone running DSZ. Uploading to rz on the VAX over a 9600 bps line is another story since the zmodem protocol tries to use longish packets which get trashed when the poor 750 is busy. Use the pl128 flag on dsz or use 128 bype packet YMODEM transfers. -- Steve Grandi, National Optical Astronomy Observatories, Tucson AZ, 602-325-9228 UUCP: {arizona,decvax,ncar,ihnp4}!noao!grandi or uunet!noao.arizona.edu!grandi Internet: grandi@noao.arizona.edu SPAN/HEPNET: 5356::GRANDI or DRACO::GRANDI
ritzenth@bgsuvax.UUCP (Phil Ritzenthaler) (04/19/88)
In article <6208@swan.ulowell.edu>, boneill@hawk.ulowell.edu (SoftXc Coordinator) writes: > > When using sz on our Dynix system, and DSZ (2-08 was the last one I tried) > on my PC running at 2400 baud, and I download a binary file, I get many CRC > fail errors, some timeout errors, and bad data errors every 8K or so. This > tends to slow down the progress of the download, especially when enough > errors arise to cause it to switch to 256 byte packets. Sometimes it even > aborts the download. > Brian, This is DEFINITELY NOT normal behavior. I unfortunately do not have exactly the same operating system as you, I have a standard, plain old 4.3 BSD on a Vax 11/785. We have been running zmodem on the machine for about a year now with no problems. The ONLY time I have encountered problems like the one you mention is when I was on another machine and telnetted over to the machine that had rz/sz on it and then tried to upload. The phone/VMS/ethernet/Unix connection had timing problems galore then . . . -- Phil Ritzenthaler UUCP :.!cbosgd!osu-cis!bgsuvax!ritzenth ARPA : ritzenth@andy.bgsu.edu "Remember, OPRAH spelled backwards is HARPO (toot-toot)!" -- Anonymous
bobmon@iuvax.cs.indiana.edu (RAMontante) (04/20/88)
boneill@hawk.ulowell.edu (SoftXc Coordinator) writes:
.>
.> When using sz on our Dynix system, and DSZ (2-08 was the last one I tried)
.> on my PC running at 2400 baud, and I download a binary file, I get many CRC
.> fail errors, some timeout errors, and bad data errors every 8K or so. This
.> tends to slow down the progress of the download, especially when enough
.> errors arise to cause it to switch to 256 byte packets. Sometimes it even
.> aborts the download.
I just tried DSZ0414 the other day, connecting to an 8800/Ultrix machine.
When I go in through a directly-attached modem, dsz works extremely well.
(But through this modem, Procomm can use ymodem and do about as well as dsz.)
When I login to the same machine, through a modem onto a campus-wide network
called the Sytek cable, dsz shows the same poor performance that boneill
describes -- a file transfer that was estimated at 12 minutes took over 75
minutes! -- but Procomm is completely unable to establish a ymodem handshake,
much less any transfer. I know little about the Sytek cable (Sytek is a
brand name), but I do know that it thinks it's 8-bit and it processes some
characters including ctrl-S and ctrl-Q. I'm kind of impressed that dsz got
a binary through at all, in light of the performance degradation. (Kermit
works okay for text transfers over this line.)
So maybe it's your connection to your machine.boneill@hawk.ulowell.edu (SoftXc Coordinator) (04/21/88)
In article <8036@iuvax.cs.indiana.edu> bobmon@iuvax.UUCP (RAMontante) writes: >boneill@hawk.ulowell.edu (SoftXc Coordinator) writes: >.> [My original article deleted] > >I just tried DSZ0414 the other day, connecting to an 8800/Ultrix machine. >When I go in through a directly-attached modem, dsz works extremely well. >(But through this modem, Procomm can use ymodem and do about as well as dsz.) >When I login to the same machine, through a modem onto a campus-wide network >called the Sytek cable, dsz shows the same poor performance that boneill >describes -- a file transfer that was estimated at 12 minutes took over 75 >minutes! -- but Procomm is completely unable to establish a ymodem handshake, >much less any transfer. I know little about the Sytek cable (Sytek is a >brand name), but I do know that it thinks it's 8-bit and it processes some >characters including ctrl-S and ctrl-Q. I'm kind of impressed that dsz got >a binary through at all, in light of the performance degradation. (Kermit >works okay for text transfers over this line.) > >So maybe it's your connection to your machine. As a matter of fact, we use the Sytek Broadband system here, allowing me to connect to as many as 14 different systems. ProComm's kermit has been the only good performer, either with text or binary transfers. YModem is useless, xmodem (either sx or xmodem 3.4) spew forth errors, and ZModem gives the problems mentioned before. MSKermit doesn't do too badly, but I prefer ProComm for my communications. It seems that this is a limiting drawback of at least Sytek BBand systems, and possibly others. I only wish I could direct connect to one of these babies... P.S. Anybody have any problem uploading using DSZ0414?? I tried to get it to upload itself so I could post it, but at byte 20248, or something like that, it stopped, and went into an endless loop of pausing, and then ERROR RECOVERY. ============================================================================ Brian O'Neill, MS-DOS Software Exchange Coordinator ArpaNet: boneill@hawk.ulowell.edu UUCP : {(backbones),harvard,rutgers,et. al.}!ulowell!hawk!boneill
fujiirm@yendor.UUCP (Roger Fujii) (04/21/88)
From article <8036@iuvax.cs.indiana.edu>, by bobmon@iuvax.cs.indiana.edu (RAMontante): > boneill@hawk.ulowell.edu (SoftXc Coordinator) writes: > .> > .> on my PC running at 2400 baud, and I download a binary file, I get many CRC > .> fail errors, some timeout errors, and bad data errors every 8K or so. This > .> tends to slow down the progress of the download, especially when enough > .> errors arise to cause it to switch to 256 byte packets. Sometimes it even > .> aborts the download. > > much less any transfer. I know little about the Sytek cable (Sytek is a > brand name), but I do know that it thinks it's 8-bit and it processes some > characters including ctrl-S and ctrl-Q. I'm kind of impressed that dsz got This is most of the problem. The best that I can figure, the reason why you die at about 8K or so is because the host overruns the sytek's internal buffer. A good way to stop making it bomb is to set zmodem's output buffer to 2-4k. This prevents the 8K problem. If you are unfortunate, then you have additional problems with the mux. The above is correct. The sytek can be configured to nuke the 8th bit and process LOCALLY an XOFF sent to it (This is really great if the HOST sends the mux an xoff.... this effectively locks the line until you hang up because the host is waiting for an XON/char, but the SYTEK will NOT pass any characters back to the host unless the host sends it a XON. Can you say deadlock?) Anyway, I hacked up a zmodem so that the crc/block numbers wouldn't send 8-bit stuff (it's gross. Translates crc/block # to ascii HEX). -- Roger Fujii - ACT, Reston, VA Phone: (703)471-9433 Internet: fujiirm@cml.rpi.edu UUCP: ..!{mimsy,sundc}!{prometheus,hqda-ai}!yendor!fujiirm -- Roger Fujii - ACT, Reston, VA Phone: (703)471-9433 Internet: fujiirm@cml.rpi.edu UUCP: ..!{mimsy,sundc}!{prometheus,hqda-ai}!yendor!fujiirm
caf@omen.UUCP (Chuck Forsberg WA7KGX) (04/26/88)
In article <8036@iuvax.cs.indiana.edu> bobmon@iuvax.UUCP (RAMontante) writes:
:describes -- a file transfer that was estimated at 12 minutes took over 75
:minutes! -- but Procomm is completely unable to establish a ymodem handshake,
:much less any transfer. I know little about the Sytek cable (Sytek is a
:brand name), but I do know that it thinks it's 8-bit and it processes some
:characters including ctrl-S and ctrl-Q. I'm kind of impressed that dsz got
:a binary through at all, in light of the performance degradation. (Kermit
:works okay for text transfers over this line.)
Sounds like a problem with flow control, or more exactly the lack of
effective flow control. The "Flow Control" chapter in the ZCOMM manual
deals with this in some detail. (The discussion is not included in
DSZ.ARC because of length).
Try using the "w" option with the sz command to restrict the window
size.. This is poor man's flow control.
If that doesn't work, setting the zmodem "l" parameter should help.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla BBS: 621-3746 CIS: 70007,2304 Genie: CAFofer@TAURUS.BITNET (05/02/88)
I tried using the DSZ0414 to download from BIX via Tymnet calling from a PAD in Israel that only allows 7 bit even parity and it didn't work. The pathnames passed ok but no data packets. The DSZ software doesn't say how to work on 7 bit paths. Procomm 2.4.2 , on the other hand performed wonderfully... Over half a meg of binaries using YMODEM with no error. +--------------------------------+-------------------------------------------+ | Ofer Lapid 4X6OJ | AX.25: 4X6OJ @ 4X1GP | | Internet: ofer@MATH.Tau.Ac.IL | AMPR : ofer@4x6oj.ampr.IL [44.138.40.04] | | Bitnet : ofer@TAURUS | Phone: 972-4-721257 | +--------------------------------+-------------------------------------------+
caf@omen.UUCP (Chuck Forsberg WA7KGX) (05/06/88)
In article <720@taurus.BITNET> <ofer%TAURUS.BITNET@CUNYVM.CUNY.EDU> writes:
:
:I tried using the DSZ0414 to download from BIX via Tymnet calling from a
:PAD in Israel that only allows 7 bit even parity and it didn't work.
:The pathnames passed ok but no data packets.
:The DSZ software doesn't say how to work on 7 bit paths.
:
:Procomm 2.4.2 , on the other hand performed wonderfully...
:Over half a meg of binaries using YMODEM with no error.
XMODEM and its variants, including the XMODEM-1k on BIS mislabelled as
YMODEM, require an 8 bit path to function.
The BIX ZMODEM support on BIX is still incomplete. Apparently it does
not set a few of the foreign PADs to 8 bit transparency as does the
XMODEM program. (8 bit transparency in the U.S. and Belgium works
properly using the defaults.)
Ths BIX ZMODEM implementation also does not monitor the reverse channel
for error packets, but this can be worked around by setting the DSZ
zmodem "l" parameter to 8192 or 4096.
There are a number of messages in the BIS protocols/general conference
detailing the workarounds. If you need to download more than a few
short files, the improvement in throughout from using ZMODEM over
XMODEM-1k is well worth the bother of reading the messages.
BIX have been having problems with their Pyramid crashing, and have
been distracted from fixing the known bugs in their ZMODEM support.
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406
TeleGodzilla BBS: 621-3746 CIS: 70007,2304 Genie: CAF