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.