TIP: Click on subject to list as thread! ANSI
echo: locsysop
to: Rod Speed
from: Geoff Armstrong
date: 1994-04-12 23:14:00
subject: Pollaxing during Polling

Hello Rod!

On 11 Apr 94, you said to Geoff Armstrong:

GA>> Could you please look in you binkley.log and see what's happening
GA>> with my packet xmission? When my system sends its outgoing packet
GA>> (usually small ie less than 4k) it gets all manner of zmodem
GA>> retries due to CRC errors. The larger files I get from you process
GA>> without any CRC errors. So most likely it is in my ZModem send.

RS> The usual cause of that symptom, uploads awful, downloads fine, is
RS> that you dont have the handshaking between the modem and the comms
RS> prog right. On an upload that means that the modem cant tell the comms
RS> prog to pause and so data gets lost, giving a visible symptom of a
RS> Zmodem error, CRC errors. Doesnt affect downloads coz the modem doesnt
RS> need to tell the comms prog to pause, so it doesnt matter if it cant.

RS> You want hardware handshaking in the modem and the comms prog.

I've looked, but there is no setting for handshaking in FrontDoor that I
can see. Sounds like a likely candidate, though. I will try Binkley again,
and see if that does anything for me.

GA>> Sometimes the session is aborted due to excessive retries, which
GA>> means I need to try again manually. A real pain.

RS> Thats just a secondary level problem, the fundamental problem is just
RS> dropped chars, and so CRC errors. If its bad enough it gives up
RS> instead of retrying.

Yes, I can see that now. Maybe I'll give more time to the session in the
windoze configuration. Also I have set the control panel / ports / com2
setting to "Hardware" ilo "None", as previously set.

GA>> Also, sometimes after an attempted session (due to BUSY returned
GA>> or something) my modems "Originate" light is out,
indicating that
GA>> the modem is set to "Answer" mode. Also when this happens, the
GA>> modem is continuously trying to lock on, scanning up and down. I
GA>> can hear the busy tone of the unsuccessful call over the top
GA>> (underneath?). The modem won't then retry to dial, it just leaves
GA>> the line looped until manual intervention.

RS> Sounds like just a brain dead modem. Didnt you say you were using
RS> those Exicom specials ?

Yes, chunks of shit they are. Are Exicom and NetComm related?

GA>> I have a PCTools for Windows timed event set up to fire off Front
GA>> Door at time "x", and I set the event in FD to fire up
and talk to
GA>> you one minute past "x". I have "Exit with
ErrorLevel 32" set in
GA>> the event, so in theory FD is only running for the event duration
GA>> + 1 minute. I can then use a terminal program without worrying
GA>> about port conflict, which I always ran into with FD running
GA>> 24hrs/day. I kept forgetting to close it down before I ran the
GA>> term prog.

GA>> I wonder if somethinh in this arrangement is stuffing up the port,
GA>> and thus the initial connect and the initial ZModem xfer (which is
GA>> always TO you)?

RS> Its possibly some subtle interaction with the Windows comm port
RS> config. Try with plain old DOS, not a Win DOS box, and see if that
RS> changes the symptoms.

I did this morning when I picked this packet up. All went well with no CRC
errors on send. And that was before I changed the control panel setting.
We'll see what Binkley does next.

Sea Ewes are round!
Geoff.

--- FMail 0.92
* Origin: My Point Entirely! (Brisbane, Australia) (3:711/934.14)
SEEN-BY: 640/305 711/934
@PATH: 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.