RS> The Spirit is notorious for MR flashing and poor thruput at 14K. The
 RS> latest fix is some hardware mods, one internal in the modem, and a new
 RS> cable. Currently that does appear to be a viable fix, after a few false
 RS> starts, suggesting a comm port problem.

A new modemcomputer cable???

 RS> If you got yours from Mike Bourne Electronics, the importer, just tell
 RS> him to fix it. Not sure if they do it on the spot or what.

I got it from a local store, who got it from Mike Boorne.

 RS> That last transfer of mine was much better. Started off a little on the
 RS> slow side but was getting to the 1500+ at the end, and the file was
 RS> quite short, only 43K, so it would likely have picked up even more.

Unfortunately the theory didn't hold up in your next download!

 RS> Thats also classic Spirit, the MR blinking just when you get poor
 RS> thruput.

Of course it could be genuine error correction, no?

 PE>> Do you use a Spirit II?

 RS> No, I run a Supra, a rockwell chipset modem.

 PE>> If so, did you notice the MR light? It should have been flashing too.

 RS> I do get an error display if errors are occurring, they werent.

Isn't that impossible?  You mean the bug is that it flashes the light and
holds up the transmission???

 PE>> I'm not particularly happy with how long it takes pkzip to pack.  I
 PE>> think I will change to using info-zip, maybe that is faster. What do
 PE>> you think of that aspect?  How does the packing time compare with what
 PE>> to? you're used

 RS> Its a bit early to tell yet for me. The first one I attempted was a
 RS> huge one of 909K, I very rarely get them that big. I do recall those
 RS> monster 1MB packets I got from the OS/2 BBS did take a long while to pack
 RS> up but cant remember exactly how long time wise.

What you should have done is go into each message area and read the last
message.  That way all the lastread pointers are set high, so you don't get
any mail from them.  I keep 7 days worth for all conferences.

 RS> I will tag echoes selectively to get more common sizes and say after a
 RS> few of those. It superficially doesnt look that different to what I get
 RS> on the Madhouse, rather quicker than on the Bush Telegraph. The madhouse
 RS> is Maximus/OS/2. The same for the scan of the mailbase before packing,
 RS> seems about the same as the madhouse, faster than the BT.

If you enjoy technical challenges (which you seem to) you can suggest ways
to tune OS/2 so that your messages get packed lickety bloody split. I don't
have a particularly fast hard disk, but I do have an 8 meg disk cache, and
from what I see, the red light doesn't go on very often when packing, or at
least there are significant delays between the red lights, which means it
must be CPU-bound.  I have a 486-33.  When the 586 comes out and prices
drop, I might get an upgrade to 486DX2-66.  I presume that is a simple
drop-in replacement of the CPU?

 PE>> Also, your date seemed "wrong" to Maximus.  You can
see the error
 PE>> message it generated.  Could you check the packet next time to see
 PE>> what the date looks like?  And the time! Maybe our clocks are out of
 PE>> synch and your message was ahead of current time?

 RS> Interesting. My copy is dated 04-17-93 (21:40). Which is about right.
 RS> Thats the message on my system, not the copy of it you sent back to me
 RS> in the QWK. The copy has 04-17-93 (00:00). The QWKs themselves are dated
 RS> correctly. But I rename them so that may have set their datestamps. It
 RS> doesnt on the madhouse ones tho, they just have times which are way out.

You would have seen the previous message.  Hey, maybe it's me that needs to
set the TZ variable.  Any ideas (this is OS/2 2.1 March beta I am running,
and Maximus is an OS/2 application).

 RS> I have noticed that all maximus QWK packets have some fundamental
 RS> problem with dates without looking too carefully at it. For example the
 RS> date stamp on the QWK packet itself is usually 10 hours atleast out. I
 RS> will look more closely.

Which is exactly the right distance from UTC!

 PE>> If the problems don't go away, I'll have to do some stress testing
 PE>> downloading a large file. I'll try locally and with you, both ways. Do
 PE>> you reckon it makes any difference who calls who?  I was told for ISD
 PE>> calls it makes a big difference who originates the call.

 RS> With the Spirit fault it does matter which direction and exactly what
 RS> modem is at the other end. And how far away the other modem is, thru
 RS> the phone network. Some have found local calls worse than STD from
 RS> memory.

 RS> Software problems are more likely to make a visible difference
 RS> uploading and downloading. Essentially because when the file is
 RS> flowing out of your system, your system can take its time and that
 RS> just gives lower thruput.

I don't seriously think this could be the problem.  I am running basically
nothing, and I am only running at 19200.  BFN.

Paul

--- GoldED 2.40