(Continued from previous message)


Yes, but this is early on in the session, and most BBSs do have
significant pauses while you escape out of the mailer and load the BBS.
I'm not convinced most people really would be aware of what is going on.

BG> Surely others would notice something like that?

You could have said that about the infamous Spirit
double sending. It was amazing how few actually did.

BG> I know I didn't with all of those modems at CHH.

I'm not convinced. How many of those modems actually do
unambiguously display the fact that they are responding to a
demand for a retrain from the USR at the other end of the call ?

I actually had a similar effect myself trying to call Pauls Netcom
1234 2400 geriatric standby modem. An odd quirk in the way FroDo
handles its dialing prefix stuff, gave a pause like that, and it took
me a while to twig that it was exhibiting some undesirable behaviour.

AND I looked closely at it because it wasnt getting a successful
2400 connect. If it had just been a bit slow and got one anyway,
I may well not have noticed anywhere near as readily.

BG> And although I wasn't looking for anything like that,
BG> I doubt I'd have overlooked such an occurrence.

I've seen that happen heaps myself. I come up to a system that
someone has asked for some assistance with, and it stands out
like dogs balls to me, and they havent even noticed, even techys.

BG> and this was done by calling Mike's own BBS - equipped with
BG> a Courier - and DLing a largish file.  I must have tested
BG> literally 100s of modems in this manner, the bulk of them
BG> being 14k4, yet I didn't once see the problem you describe.

RS> Maybe.

BG> No "maybe" about it, Rod, it's quite true.

I meant maybe you would have noticed that quirk of the USR VE and
maybe you wouldnt have. Demanding a retrain with V32bis modems.

BG> I've nothing to gain by telling porkies either
BG> (unlike that fuckwit mate of yours, RTL).  :)

Oh sure, I wasnt suggesting you were making it up.
I've taken to just saying LIAR straight out on those
now, there is quit a bit of that about currently |-)

RS> It will be interesting to see what comes out of the close
RS> look at just what other V32bis modems get from the USR VE.
RS> I find it rather hard to believe that it only does that when
RS> a Supra calls, but I havent actually tested that carefully.

BG> Well, I tested most of the currently available brands of V.32bis modems
BG> (I've ignored V.34s here, as it appears to be a V.32bis problem), and
BG> not one of them failed to connect at their full speed of 14400 bps.

I didnt mean that, I meant the USR demanding an immediate retrain.

BG> Of course, all of these were Austel models,
BG> so it wasn't possible to test a Supra.  :)

Sure Bill |-)

BG> And there must be a HELL of a lot of people
BG> calling Couriers with their Rockwell 14k4s too.

RS> Yes, but how many can actually SEE an initial demand
RS> by the USR for a retrain and now many would actually
RS> notice if they can is another matter entirely.

BG> Your Supra aside, does it really matter though?

Well, its completely fucked behaviour. And removing that would
presumably fix the problem with the Supra, coz there is never
the slightest suggestion any problem with the call after that.

The other extremely odd detail is that the INITIAL connect
is always perfect, and its only the retrain demand that
makes a session fall over 30% of the time. Thats damned odd.

BG> If the calling modem isn't being adversely affected
BG> by the retrain request, surely it makes no difference
BG> whether the request is being issued or not.

Sure, but its still completely fucked. The USR VE is supposed to be perfect |-)

Sorry, couldnt help myself |-)

RS> I agree that some careful testing of what other V32bis modems report
RS> that mindless immediate retrain demand would certainly be interesting.

BG> Yeah, but it's not a particularly easy thing for an
BG> end-user to get hold of a swag of 14k4 modems for testing...

Yeah, and its subtle enough that it isnt even that easy to just get
the average droid to call with his V32bis and see what happens either.

BG> If it fails the same way, I'd also be pointing the finger at
BG> Couriers in general.  All you've proved so far is that YOUR Supra
BG> appears to have a minor incompatibility problem with 2 or 3 Couriers.

RS> Nope, I have proven pretty conclusively a general
RS> problem between the Supra and the Courier.

BG> The Supra V.34s don't exhibit this problem,

It aint doing a V32bis call is it ?

BG> so to date, you've really only proved
BG> that YOUR specific Supra barfs at the USR.

Yes, its theoretically possible that mine is the only V32bis
Supra which does, but I think thats clutching at straws and
isnt really worth putting too much effort into testing yet.

BG> I'd like to see some hard evidence that OTHER V.32bis Supra owners are
BG> seeing the same thing before I start pointing my finger at the Courier.

I think thats as fruitless as Paul trying another
physical USR VE or having his line tested.

Sure, theoretically possible, but microscopic chance IMO. Only worth testing
that possibility if the much more likely stuff is eliminated. We know for
example that Franks result is even more totally fucked. The evidence points
to the fact that the sun doesnt actually shine out of the USR VEs arse.

I will however continue to pursue a workaround, if only for
calls to USR VEs even if Paul does get something else instead.

I havent managed to get the USR_Modems turned on yet, and havent tried
the Supra echo yet either, tho its been turned on for a long time.
@EOT:

---