" Maynard) (02/21/89)
I'm feeding a Ufgate site. When he went from UUPC to Ufgate's uuslave
for the actual transfer, the transfer speed dropped badly; we're running
the link at 2400 BPS, but he's reporting only 23 CPS transfer speeds.
His system is logged on now, picking up his feed, and, according to the
lights on the modem, it's only transferring a block every three seconds:
he sends an acknowledgment, I send a block, and, three seconds later, he
sends another acknowledgment and the process repeats. I've asked him
about it, and he tells me that every block comes up with a long block
error. I'm running Microport System V/AT v2.3, with Honey-DanBer UUCP
installed. Help?
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity.
hoptoad!academ!uhnix1!splut!jay +----------------------------------------
{killer,bellcore}!texbell! | "Less great!" "Tastes filling!"sl@van-bc.UUCP (pri=-10 Stuart Lynne) (02/21/89)
In article <869@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: >I'm feeding a Ufgate site. When he went from UUPC to Ufgate's uuslave >for the actual transfer, the transfer speed dropped badly; we're running >the link at 2400 BPS, but he's reporting only 23 CPS transfer speeds. Don't know if it's still true with Ufgate, but uuslave had a window size of 1 vs. 7 for uupc. This has a big impact on transfer performance. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
mju@mudos.ann-arbor.mi.us (Marc Unangst) (02/21/89)
In article <869@splut.UUCP>, jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: > I'm feeding a Ufgate site. When he went from UUPC to Ufgate's uuslave > for the actual transfer, the transfer speed dropped badly; we're > running the link at 2400 BPS, but he's reporting only 23 CPS > transfer speeds. His system is logged on now, picking up his feed, > and, according to the lights on the modem, it's only transferring a > block every three seconds: he sends an acknowledgment, I send a > block, and, three seconds later, he sends another acknowledgment and > the process repeats. I've asked him about it, and he tells me that > every block comes up with a long block error. I'm running Microport > System V/AT v2.3, with Honey-DanBer UUCP installed. Help? You might ask him what debugging level he has UUSLAVE set at. If you set it at 9 (the highest available; it prints out the contents of each block in hex and ASCII), your xfer rates will drop dramatically. This is because UUSLAVE uses DOS calls for screen I/O, and because it won't send the ACK until it has printed the whole block. Thus, it doesn't send the ACK until a few seconds after it receives the block, because it's still busy printing out the contents of the block to the screen. Even setting the debuglevel to 2 (normal, except print a real-time block count) slows down the transfer. You're best to let it default to 1, where it doesn't print out anything in the middle of a packet. -- Marc Unangst UUCP : mju@mudos.ann-arbor.mi.us UUCP bang : ...!uunet!sharkey!mudos!mju UUCP bang alt.: ...!{ames, rutgers}!mailrus!clip!mudos!mju Internet : mju@mudos.ann-arbor.mi.us
eric@hdr.UUCP (Eric J. Johnson) (02/21/89)
In article <869@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes:
:
:I'm feeding a Ufgate site. When he went from UUPC to Ufgate's uuslave
:for the actual transfer, the transfer speed dropped badly; we're running
I just installed UFGATE on one of my PCs and see this happening.
I too, have switched from UUPC. One thing I tried was using the UUPC
'uu' program to transfer the data (which is much faster), and then run
a program to change the X. and D. spooled file names to UFGATE format. Which
UFGATE picks up without a problem.
The problem I am having with UUPC is that it mangles compressed news files
during transfer which then cannot be decompressed by 'cub'. Has anyone
else seen this problem? When I use the UFGATE 'uuslave' program, the compressed
files transfer without any problem (besides incredibly slow transfer speed).
--
Eric J. Johnson, Amperif Corporation. UUCP: eric@hdr.UUCP
Perhaps, once upon a time, some Devilish hacker planted a bomb deep in the
human brain such that it would only trigger upon a certain thought passing
through the mind... Perhaps this explains spontaneous human combu*****julian@acp.OZ (Julian Elischer) (02/23/89)
In article <921@hdr.UUCP>, eric@hdr.UUCP (Eric J. Johnson) writes: > In article <869@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: > : > :I'm feeding a Ufgate site. When he went from UUPC to Ufgate's uuslave > :for the actual transfer, the transfer speed dropped badly; we're running > > I just installed UFGATE on one of my PCs and see this happening. > > I too, have switched from UUPC. One thing I tried was using the UUPC > 'uu' program to transfer the data (which is much faster), and then run > a program to change the X. and D. spooled file names to UFGATE format. Which > UFGATE picks up without a problem. I used UUPC (modified (see later)) to send batched news to a fido system. I re-wrote the name translator and wrote a "rnews" for the dos end, that the uuxqt request would run. I used 12 bit compress and compiled compress from news2.11 on DOS (actually worked, though 12 bits was MAX) > > The problem I am having with UUPC is that it mangles compressed news files > during transfer which then cannot be decompressed by 'cub'. Has anyone > else seen this problem? When I use the UFGATE 'uuslave' program, the compressed > files transfer without any problem (besides incredibly slow transfer speed). > I have used both of these programs.. I haven't noticed the slow speed to ufgate that you have mentioned, (the xfers occur at night and I must say, I just haven't noticed (though I remember when I was testing, noticing that something was strange) however I do know about the compress problem with UUPC. I run a version of the earlier version of UUPC called dcp that came out about 6 months earlier. I didn't go on to UUPC as such because by then I had re- written so much of dcp that it did what I wanted. The problem is that compressed files are binary, and UUPC/dcp opens the target file (for rcv) and source file(for xfer) in TEXT mode, which translates "\n" in the internal representation to CRLF on the disk when written (and visa versa when read). It also closes the file on reading a ^Z (dos eof). This is a really simple patch to the program to change, but then mail fouls up because mail is plain text (as is uncompressed news) and you need to change the mail/news software to expect unix type \n line terminations. The solution I ended up using was to modify dcp (UUPC) so that it would use binary mode if the control line had the -c flag set .. e.g. S source/file target/file -cd 666 spooled/name (or whatever the exact format was) and use TEXT format if the -C flag was there, (or neither). This overloaded the conventional usage of the -c / -C flags so that spooled files from unix are text, while directly read files are binary. (see uucp(C)). This flag is not always passed to the remote machine, however on the system I use it is so all worked fine. Obviously, on the dos end you can use whatever flag you want... On the subject.. I wish uucp (we use HDB) had a -o option such as found in lp that gets passed on to the other side to signal such things.. (Is Peter Honeyman listening?) . I'd love to have a text/Binary mode switch for several different systems, I know it's useles in unix but many systems need it. julian ELISCHER Australian Computer Products UUCP: uunet!munnari!acp.oz!julian ACSnet: julian@acp.oz.au 1133 Hay st. West Perth, 6005 , Western AUSTRALIA.
robert@hemingway.WEITEK.COM (Robert Plamondon) (02/24/89)
I see the same problem with my installation. I upped the window size
to 10 (with the undocumented -f option to uuslave), but the transfer
rate was still only 40 bytes/sec. The debug flag was the default, and
uuslave only writes to the screen between transferring files.
The delays are clearly caused by a long pause between receiving blocks
and sending ACKS. With a window size of ten, and my PC receiving, it
will receive for a relatively long time (ten blocks, I assume), then
stop, send an ACK, get another block, send and ACK, etc.
The pauses between ACKS are on the order of 1-2 seconds.
I assumed it was my FOSSIL driver (I'm running on a Tandy 2000), but
now I'm not so sure. Does this problem happen to people with and
without FOSSIL drivers? If anybody DOESN'T see this problem with his
setup, speak up!
-- Robert
--
Robert Plamondon
robert@weitek.COM
"No Toon can resist the old 'Shave and a Hair-Cut'"nomad@verdix.com (Lee Damon) (02/24/89)
In article <762@hemingway.WEITEK.COM> robert@hemingway.WEITEK.COM (Robert Plamondon) writes: >I assumed it was my FOSSIL driver (I'm running on a Tandy 2000), but >now I'm not so sure. Does this problem happen to people with and >without FOSSIL drivers? If anybody DOESN'T see this problem with his >setup, speak up! I have noticed that when my machine sends (is in Master mode), there is a packet then an ack then a packet then an ack, etc. (No sliding windows) but when it is in slave mode it just streams along, no pause between receiving and acking. I'm running on a PC/AT with the X00 FOSIL. For further information on UFGATE, and to aid in discussing this w/o bothering people who don't care, you can subscribe to the UFGATE mailing list (the UFGATE echo is the main part of the mailing list, I just gateway between - anything posted to the echo goes out to the list and visa-versa). Send requests to be added to the list to: ufgate-list-requests@cs.orst.edu or ufgate-list-requests@castle.fidonet.org (aka castle!ufgate-list-requests). nomad (hostmaster, fidonet.org) ------------- Lee Damon work: verdix!nomad or nomad@verdix.com play: {agora,tessi,verdix}!castle!nomad or nomad@castle.fidonet.org fidonet: The Castle BBS, 1:105/302, 503-641-3161 "God" created man, and man, being ever so humble, returned the favor.
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (02/24/89)
In article <921@hdr.UUCP> eric@hdr.UUCP (Eric J. Johnson) writes: >In article <869@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: >: >The problem I am having with UUPC is that it mangles compressed news files >during transfer which then cannot be decompressed by 'cub'. Has anyone I feed a dozen pc types compressed news with uupc. What release of uupc do you have? In the initial release there was an inadvertant use of strcpy instead of strncpy to copy the incoming data. If you have the source it is really easy to find and fix. If you don't, you can download the file van-bc!~/uupc/interim.arc from this site. It contains the source and MS-DOS binaries for a more recent release. The phone number is 604-939-4782, login: nuucp, password: nuucp for uucp; login: guest, password: guest for interactive. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
nanook@novavax.UUCP (Keith Dickinson) (02/24/89)
in article <762@hemingway.WEITEK.COM>, robert@hemingway.WEITEK.COM (Robert Plamondon) says: > > > I see the same problem with my installation. I upped the window size > to 10 (with the undocumented -f option to uuslave), but the transfer > rate was still only 40 bytes/sec. The debug flag was the default, and > uuslave only writes to the screen between transferring files. > > The delays are clearly caused by a long pause between receiving blocks > and sending ACKS. With a window size of ten, and my PC receiving, it > will receive for a relatively long time (ten blocks, I assume), then > stop, send an ACK, get another block, send and ACK, etc. > > The pauses between ACKS are on the order of 1-2 seconds. > > I assumed it was my FOSSIL driver (I'm running on a Tandy 2000), but > now I'm not so sure. Does this problem happen to people with and > without FOSSIL drivers? If anybody DOESN'T see this problem with his > setup, speak up! > > -- Robert > -- > Robert Plamondon > robert@weitek.COM > "No Toon can resist the old 'Shave and a Hair-Cut'" I'm running UUSlave on a 10 Mhz XT clone and get arround 185 cps at 2400 baud. My configuration is the default except debug level is set to 1 (that should actualy SLOW it down!). I also have my fossil driver (OpusComm) set so that I have a 4k inbound/outbound buffer. The larger buffer gives UFgate a little more leaway in timing. I _have_ heard of a known problem with UUSlave working with high speed modems (primarily TrailBlazers). These modems for some reason confuse UUSlave causing it to actualy slow down somehow. According to Garry Paxinos (pax@ankh.UUCP), the author of UUSlave, the primary reason for slow data transfers is CPU speed. Since the UUCP-g protocol is very inefficient on the PC side, the only reason for a low speed would be a slow computer. I only get about 185 cps with a 10Mhz system. When I ran an 8 Mhz system I got about 140-160 cps, so speed is obviously a factor! If your interested in the source code and don't have it, I can foreward it to you. Keith Dickinson -- __ Fidonet : 369/2 [(305) 421-8593] Brave New World South / \ Internet: nanook@muadib.FIDONET.ORG / oo|\ or : nanook@f3.n369.z1.FIDONET.ORG (_\ |_) UUCP : novavax!muadib!nanook _ /__\@'__ USnail : 433 SE 13th CT. J-202, Deerfild Beach, Fl. 33441 // / | | (( / | (*) | "Speak UUCP Fido, Speak!" \\/ \ |__U__| ______ \ /_ || \\_ / FIDO \ muadib is a FREE gateway for mail between \____)|_) \_) (________) Usenet and FidoNet. For info write to Root.