juan@cobra.gatech.edu (Juan Orlandini) (01/25/90)
After much agravation with jrcomm, I have gone back to using VLT. (I should have stayed with that trusted friend, but alas, I'm a sucker for gimmickry). The only problem I have now, is that I can't find the external Zmodem package. Could someone please mail me XPRZmodem 2.0, or failing that, tell me where I can ftp it from. Thanks, Juan juan@cobra.gatech.edu
bard@jessica.Stanford.EDU (David Hopper) (02/20/90)
I would like to thank everyone who responded to my Kermit posting a while back.
Apparently, I was not issuing the 'set file type binary' command before down-
loading. Stupid mistake, and I appreciate everyone's replies. I am now down-
loading in XPRKermit at 1024K blocks (GREAT compared to 94K blocks).
My problem now is with the XPRZmodem protocol. It downloads fine with a buffer
size of 1K, but it is TERRIBLY slow. I changed the buffer size to 64K and, as
I am using a floppy system at present, the frame size to 65536 (as the docu-
mentation states as an example). Whenever I download a file greater than 64K,
the protocol times out at exactly 65536K (when the floppy is accessed). I see
no option in the VLT (4.428) protocol window to set the timeout limit. Any
replies would be appreciated.
Thanks in advance,
Dave Hopper /// Yesterday, CS. | bard@jessica
/// Today, Anthro/History. | .Stanford.EDU
\\\/// |
\XX/ Tomorrow... URBAN TERRORISM! | (Mel Blanc lives!)papa@pollux.usc.edu (Marco Papa) (02/20/90)
In article <9331@portia.Stanford.EDU> bard@jessica.Stanford.EDU (David Hopper) writes: |My problem now is with the XPRZmodem protocol. It downloads fine with a buffer |size of 1K, but it is TERRIBLY slow. I changed the buffer size to 64K and, as |I am using a floppy system at present, the frame size to 65536 (as the docu- |mentation states as an example). Whenever I download a file greater than 64K, |the protocol times out at exactly 65536K (when the floppy is accessed). I see |no option in the VLT (4.428) protocol window to set the timeout limit. Any |replies would be appreciated. XPRZmodem 2.0 is broken (in a variety of places). The source is available (I think on BIX), so you could try to fix it yourself :-) -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
scott@grlab.UUCP (Scott Blachowicz) (02/22/90)
Regarding XPRZmodem; bard@jessica.Stanford.EDU (David Hopper) writes: > My problem now is with the XPRZmodem protocol. It downloads fine with a buffer > size of 1K, but it is TERRIBLY slow. I changed the buffer size to 64K and, as > I am using a floppy system at present, the frame size to 65536 (as the docu- > mentation states as an example). Whenever I download a file greater than 64K, > the protocol times out at exactly 65536K (when the floppy is accessed). I see > no option in the VLT (4.428) protocol window to set the timeout limit. Any > replies would be appreciated. I'm using VLT4.226 (I think) with XPRZmodem, and when I have to go to floppy, I set the sizes for 16K and it works (or at least, it has in the past). This is with a 1200 baud connection, in case that makes a difference. I have yet to bring up 4.428 VLT...does it include XPRKermit or can I find that elsewhere? or should I just stay with XPRZmodem? I'll (hopefully) have access to a Telebit modem soon. Any recommendations for using that on my A1000 with VLT (or VT100, AmiUUCP, etc) would be appreciated. Later, -- Scott Blachowicz E-mail: scott@grlab.UUCP USPS: Graphicus ..or.. ...!hpubvwa!grlab!scott 150 Lake Str S, #206 VoicePh: 206/828-4691 Kirkland, WA 98033 FAX: 206/828-4236
nicthu@mcorp.UUCP (Nick "The Watchdog" Thurn) (02/23/90)
In article <9331@portia.Stanford.EDU> bard@jessica.Stanford.EDU (David Hopper) writes: >... >I am using a floppy system at present.... >Whenever I download a file greater than 64K, >the protocol times out at exactly 65536K (when the floppy is accessed). ^^^^^^ You must be using a LOT of floppies if you're downloading files this large! :-) Nick osu!mcorp!nicthu
aries@dvinci.UUCP (Aries Project) (02/26/90)
> My problem now is with the XPRZmodem protocol. It downloads fine with a buffer > size of 1K, but it is TERRIBLY slow. I changed the buffer size to 64K and, as > I am using a floppy system at present, the frame size to 65536 (as the docu- > mentation states as an example). Whenever I download a file greater than 64K, > the protocol times out at exactly 65536K (when the floppy is accessed). I see > no option in the VLT (4.428) protocol window to set the timeout limit. Any > replies would be appreciated. > > Thanks in advance, > > Dave Hopper /// Yesterday, CS. | bard@jessica VLT seems to have inherent speed problems. I implemented the XPR callback routines myself (for DIALOG Professional) and I regularly have long distance callers downloading at 2000+ cps (using 14,400 HST). I initially had the buffer set at 16K, and most people had problems when the download hit the 16K mark. I dropped the buffer to 1K and things are working fine. I'm still maxing out at about 800 cps when people are uploading though (ie XPRZmodem is receiving). I'm not sure what the problem is. Maybe XPRZmodem only requests one character at a time? Anybody have any ideas? -Mike Oliphant
bscott@pikes.Colorado.EDU (Ben M Scott) (03/19/90)
> there is a protocol FASTER than Zmodem, called > JModem...Its on IBM bbs's sometimes, Jmodem is potentially faster than ZModem, but it does not have many of the 'modern conveniences' that I think many of us have grown accustomed to...like sending the filename for downloads, or Batch/Resume, nor is it a streaming protocol like Zmodem as it has to acknowledge each block sent, thus decreasing throughput. Also, it only has a 16-bit CRC, and Xon/Xoff characters are not escaped. Still, the file compression done is guaranteed not to increase block size and under good conditions it can use up to 8K blocks (which is why it's often called JModem 8K). The author of the protocol until recently ran a BBS in my area which I called from time to time. Just a little while back I came upon an Amiga port of JModem implemented as an external protocol a'la DSZ. I have not tried it yet due to the previously listed shortcomings, but it does exist. I don't know where you can get it, though; I've forgotten where I got it myself. . <<<<Infinite K>>>> -- _______________________________________________________________________________ | | | Someday, I'm going to make up a clever .sig file like everyone else has... | |_____________________________________________________________________________|
derek.clarke@canremote.uucp (Derek Clarke) (03/22/90)
Speaking of protocols, there is a protocol FASTER than Zmodem, called JModem...Its on IBM bbs's sometimes, and i was wondering, Is there a trminal with it anywhere??? Even something real good like that would do me... I like changes a lot, guess thats why i have usd 4 bbs prgs in the last 2 months... --- * Via ProDoor 3.1a ~ QNet 2.02: Track 36 BBS The Commodore Support Group (416)-549-1916
jeh@sisd.kodak.com (Ed Hanway) (10/12/90)
joseph@valnet.UUCP (Joseph P. Hillenburg) writes: >jeh@sisd.kodak.com (Ed Hanway) writes: > >> papa@pollux.usc.edu (Marco Papa) writes: >> >In article <1990Oct8.193808.21972@ux1.cso.uiuc.edu> jbn35564@uxa.cso.uiuc.ed >> >>Why not fix the XPR Zmodem? >> >> >There is really nothing to fix. XPR-Zmodem has an inherent overhead due to >> >the external protocol definition. >> >> Then why not fix the external protocol definition? Or what I really mean >> is extend it to make it capable of handling full-duplex streaming protocols >> without degradation. > >The fact that the protocol is *external* is why it isn't as fast as an >internal protocol. Perhaps my overuse of the word "protocol" wasn't clear. If XPRZmodem is slow because the interface between the terminal program and the XPR library isn't adequate for a full-duplex streaming protocol like Zmodem, then enhance that interface. From my brief perusal of the XPR spec, the interface between the terminal program and the XPR library looks very clean, but tailored to half-duplex, synchronous protocols like Xmodem. The fact that the Zmodem XPR is shoehorned into this interface probably accounts for its performance (or lack thereof). With an improved interface, there's no reason why an "external" protocol should have any more overhead than an "internal" one. Ed Hanway uunet!sisd!jeh