Hi Howard S.,
Hi Heimo,
About "`LSPPP v0.764', `LSICQ v1.8x' and contributions" of April
20:
MS> I've been using `LSPPP v0.764' for some time now, so far so good...
MS> It loads and seems to work correctly on my 8088... I think you will
MS> find that `LSPPP v0.764' deserves the confidence Heimo has into it.
HS> I also downloaded v. .764 and it did not choke on authentication...
HC> ...the LSppp dialler had some problems, earlier...
I'm a Sympatico user and lived in Montreal before i moved to Trois-
Rivieres, if i connect to the ~ISP~ from Montreal "Authenticating..." is
not displayed but it is when i do so from Trois-Rivieres... The rest of
the `LSPPP v0.764' screen remains the same but i won't be surprized that
"Authenticating..." doesn't show up in Trois-Rivieres someday. You see,
years ago i noticed that what i believe can be refered to as their ~PPP~
server pool seems not to be 100 % consistent: in both cases my UserName
& PassWord have been defined, thus activating the ~PAP/~CHAP~ modes, but
there are differences at the authentification level, nonetheless!!! 8^o
It sounds nice that you no longer have LogIn problems; personally,
i began to regain interrest with the comming of `LSPPP v0.764' - which i
`WWPacked' to obtain a 13 Kb only executable! :) Lets say i might very
well become a fan in no time if this new path remains trouble-free! ;-)
It already saved my day, this month, when `EPPPD' began to fail; on top
of that, its memory requirement makes it possible to have 624 Kb of free
conventional memory for something as network games while having a sound-
card driver loaded with my ~ANSI~ driver, ~RAMDisk~ drivers, `DOSKey', a
small mouse driver, `KALI DOS' and my French-Canadian keyboard driver!!!
8^)
I wish `LSPPP' will have the best internal dialer it can get or, if
people prefer an external dialer, why not just ask that the internal one
be removed! That would reduce the foot-print even more and the adaptive
external `{Commo}' dialer macro i use will let me choose between the old
fashion terminal/~TTY~ LogIn method and the ~PAP~/~CHAP~ automated ones:
this ensures a successfull LogIn most of the time. Euh... Perhaps it's
possible your ~ISP~ too is using a mixed pool of ~PPP~ servers? 8-o It
has been a problem here for a whole year; i was unable to load `PC/TCP'
on occasions, when i first tried about five years ago... I noticed that
my connection to their ~PPP~ server didn't look the same from one try to
the next and `COMScript' failed because of this (and other dialers too).
Most of them are flawed, i wasn't in favour of it the day i 1st heard of
`LSPPP' and that's why i adapted my external `{Commo}' dialer willingly.
The later `LSPPP' executable made me forget the problems i had before, i
gained some renewed hope since i got it. Heimo was right to insist! :)
HS> ...does not have the ``memory leak'' that Tony Lopez's epppd has...
I didn't even know about it before i was told by Heimo Classen. :>
HS> ...I got slower download speeds from my zoom 56K modem... ...I do
HS> not see how a packet driver can directly affect modem speeds.
HC> I got the opposite impression... One explanation could be modem/
HC> hardwired compression - is it set the same in both cases ?
I tried `EtherPPP', `PC/TCP', `Klos', `LAN WorkPlace for DOS v4.2',
`EPPPD' (`DOSPPPD') and the Novell/Caldera suite from `DR_Web-Spyder'...
Oh, and `PC-NFS' but that was a short story and i don't recall much now.
I can testify that my file transfers weren't equal; it took days before
i was able to find the right mix of buffer types and sizes with `PC/TCP'
and i didn't even think to compare with raw connections (where the Error
Detection and Corrections are disabled - i read it may help), euh... It
certainly is also possible to compare packet-driver configurations where
the Van Jackobson compression has different settings and, as if that was
not enough, i can think of the ~UART~'s ~FIFO~ trigger level which helps
in given circumstances (for LEGACY PCs which are too busy). It can be a
lot of trouble when you try to free up the few last cps possible... P-)
HS> There are a few things not spelled out in the LSPPP doc that I would
HS> like to understand: /A Must you use this switch to enable PAP
HS> authentication?
I'm more a specialist of adaptive external `{Commo}' dialer macros;
`LSPPP' didn't work too well for me until i got v0.764 but i had to play
with it and my understanding has been that ~PAP~/~CHAP~ authentification
is selected by using the "/P:" and "/U:" flags - ~TTY~ LogIn is selected
by default (some ~PPP~ servers may even not require any authentification
at all but that's quite unlikely). I have seen occurances where i would
be better select both (i tried ~TTY~ 1st and then i fell back to ~PAP~)!
%-b,
HS> Does LSPPP support all three of PAP/CHAP/ordinary login...
HC> I think this is only needed if you want to force PAP. As far as I
HC> understood from the doc... ...some sort of "fallback".
I'm really not too shure my ~ISP~ has ever waited for ~CHAP~ LogIn,
or that it would accept it if i decided to enable it. Can `LSPPP' do it
all? Yes, the documentation will tell that much even if there's not one
single occurance of the "CHAP" string in the executable. I suppose that
the ~PAP~/~CHAP~ automated authentification protocols are being selected
internally, at connection time. I found no flag to disable one of them,
separately. I didn't think they'd be used if not selected, in any case.
HS> Is 3 seconds (default) a reasonable time for ISP authentication?
I'm sorry, i didn't encounter that sort of problem. I guess it is.
HS> /B I hope/assume this is the speed of the modem, not the speed the
HS> com port talks to the modem - which is faster usually?
That's the maximum speed at which your MoDem can transfer data thru
the PC's serial-port (the ~UART~ is included on internal MoDem cards)...
It's strongly recommended that the PC-to-MoDem speed is set 3 to 4 times
higher than that of the MoDem-to-MoDem "CARRIER" speed. If i use my old
GridCase II LapTop with my Zoom 14.4 EX Model VFXV32 i must issue an "AT
F8" command so that the CARRIER speed is set to 9K6 bps while my serial-
port speed is 19K2 bps. That MoDem is the Rockwell ~RPI~ type and needs
a special driver to support Compression and Error Detection (provided in
V.42Bis) and the ~UART~ is a ~FIFO~-less 8250 HardWare emulation, that's
not an ideal setup but the speed margin is enough in that case since the
need for a three/fourfold margin doesn't exist here. On the other hand,
my external GVC SF-1156V MoDem can do Compression and Error Detection in
HardWare, of course. The CARRIER will reach 49K333 bps so i must select
a PC-to-MoDem speed of 115K2 bps to ensure that the compressed data does
not give rise to an excessive flow of data. It puzzled me for some time
because 49333 x 3 = 147999... I was also puzzled before because i tried
a 26K2 bps CARRIER connection with only a 38K4bps CONNECT speed and that
setup worked reasonably well on my Tandy-1000 (8088), as i recall!!! My
only explanation was that this MoDem has internal buffering: if i issue
a command it doesn't react as instantaneously as my other MoDems... 8-o
I concluded that this buffering action can smooth the flow enough, maybe
data from/to the packet-driver wasn't too steady and it filled the gaps.
HS> /F I take it it has something to do with enabling fifo buffering?
Yes, there are four ~FIFO~ trigger levels: 1, 4, 8 and 14 bytes...
The 16550 ~UART~'s ~FIFO~ is 16 bytes deep, it fills up while your PC is
busy doing other tasks. In terms of processor speed, DialUp connections
are quite slow and that gives plenty of room to the processor so that it
can accomplish work before the triggering level is finally reached. The
~UART~ sends an interrupt request long before its ~FIFO~ has time to get
full: it's processed fast enough to prevent overruns and the cycle goes
on and on and on... A ~FIFO~ed ~UART~ was no luxury in a LEGACY PC but
modern day machines may very well be able to manage just by "polling"...
There's been 8088 communication SoftWare which relied on this method but
the time-slices for the tasks, between each poll, had to be quite short!
It explains why the ~FIFO~ trigger level influence is more noticeable on
LEGACY HardWare. By the way, `LSPPP' is conservative by having it at 8.
:)
HS> /L & /P I discovered, my ISP uses more than 3 seconds...
Those ~LCP~ and ~IPCP~ stages show up more clearly on other packet-
drivers. I definitively had to adjust the related delays in my `PC/TCP'
script and i think the story tells about the same in `Klos', `PC-NFS' or
i don't know what else. `EPPPD' had its defaults just right but i guess
that the requirement to modify these settings may not be that unusual...
Perhaps you might find that Van Jacobson compression can influence this?
I noticed some difference between a 8088 and a 80286, even with a turbo!
My ~ISP~ doesn't seem to need that much but, as i argued, yours may
not have a consistent ~PPP~ server pool and it's possible timeouts vary.
HS> Is it better to use a short time and several retries or a longer
HS> time and 1 or 2 retries?
I'm far from certain that this applies to `LSPPP' - maybe it's just
a `COMScrpt' thing, euh... - but `PC/TCP' requires 15 separate pauses in
between "signal lcp open"/"poll lcp open", 10 before "poll ipcp open"...
a set of two single pauses of equivalent duration simply won't do! This
doesn't sound to be related so much but i'll suggest many short retries.
Processing power influenced this a lot, what's your HardWare setup? :^)
HS> Matters like the above probably affect successful connects...
Yes. My finding as well, especially when you try to load `PC/TCP'.
`LAN WorkPlace for DOS v4.2' has a set of options at the top of its .CFG
file too, i don't recall, euh... Ha! "Buffers" and "MemPool"... Well,
i bet that if you look around you'll find more of these to play with!...
;-)
HS> ...it may be better to put in DNSs at the command line...
I like this idea! I agree that it should cut the negotiation time.
HS> ...defects in LSPPP instead of incorrect timeout settings.
Hummm... I remember when i was raging against my ~ISP~; it turned
out that we both had problems... My serial-port was defective so it was
quite puzzling when things got back to usual, try check your debug logs.
Salutations, :)
Michel Samson
www3.sympatico.ca/bicephale
a/s Bicephale
... I BBS using LEGACY DOS+TCP/IP+TelNet+ZMoDem/Kermit+.QWK technologies
To unsubscribe from SURVPC send a message to [EMAIL PROTECTED] with
unsubscribe SURVPC in the body of the message.
Also, trim this footer from any quoted replies.
More info can be found at;
http://www.softcon.com/archives/SURVPC.html
