No subject

satisfying their timing requirememts must be a top consideration.

Once you go out of your box, you have to face these unpleasant realities.
eg. CPU > ser-port > modem > telco-line > ISP > ...

To talk of 'throttling back until it flies'; instead of making the timing 
specs comply, sounds bad ?

1. Some years ago a version of n-o stand Alone often failed to dial
the modem, yet DOS and linux always dialed.

2. Here in s.africa it is know that many modems need an extra string
to 'get dial-tone'.   Apparently there must be a specified time between
when the machine 'looks' and when dial-tone is detected.
Perhaps n-o should wait ?

3. n-o V2.3.2 standalone Mail.Panel failed to connect, yet
      V 2.3.6 DOSbased connected.   I don't know of any
     software update and must assume a critical timing cause.

4. I'm still trying to find out why sometimes when I get an abnormal
ppp disconnect; further retries fail unless I reboot or Ctrl-Break a few
times immediately after Dialer.Dial PPP Device0 ~
The need to try a few times indicates a randomness - 'the roulette
ball to fall in' while the "Dialer.Dial PPP Device0" task is still busy ?
By monitoring with a second n-o box, I confirm that the strings
sent to the modem are OK (except that V24.Panel does not show
CR nor LF - which are important). Line and modem Status-register
values for good and bad conditions, are different - for latter analysis.
Perhaps these differences will points to hardware handshake problems ?

If none of you have these problems or even believe them, it's because 
you all use M$ outspOOk !


Chris Glur.
--
PS. I'm using 486 40 Mhz machines.