Strange indeed, Howard: > Strangely, when I used LSPPP v .764 as the packet driver, consistently > I got slower download speeds from my zoom 56K modem, compared to epppd, > although I do not see how a packet driver can directly effect modem > speeds.
I got the opposite impression with a 56K modem (not a Zoom one but it seems Hayes compatible), and I think - didn't measure - consistently. One explanation could be modem/hardwired compression - is it set the same in both cases ? (Which is to be set with the modem initation, and thus with the dialler - i do _not_ use LSppp's built-in dialler but an external one [chat]; the LSppp dialler had some problems, earlier, so I never vothered with this.) Another thing, linked to that, is the port speed setting: > /B sets the baud rate. > I hope/assume this is the speed of the modem, not the speed the com > port talks to the modem - which is faster usually? This /B switch is definitely for for the _port_ setting - the "real", inter-modem speed is negotiated between the modems, and by them. But if your port setting is too slow, you get lots of errors and retry/resend requests. That could be it. > /A sets PAP timeout and retries > Must you use this switch to enable PAP authentication? I think this is only needed if you want to force PAP. As far as I understood from the doc (which indeed is not too verbose, <g>), LSppp does do some sort of "fallback". I never had to bother about that with different access providers in different telco empires around here. Thus the command line gets rather short, at my home place: lsppp764 /b:03e8 /i:5 /B:115200 /U:xxx /P:yyy The major difference I experienced was with the ability to negotiate DNSs; I think this is part of "IP negotiation" - according to LSppp's author, it does DHCP; but AFAIK the implementation of that one could indeed vary considerably from server to server. And as LSppp does _not_ read a WATTCP.CFG, so it may be better to put in DNSs at the command line; it could shorten IP negotiation too, perhaps. Thus away from "base" I susually have it like this (the /z is a debug switch and creates a log file - not very useful if you don't know those codes of just one or two bytes which are exchanged as key words between hosts and clients): lsppp764 /z /b:03e8 /i:5 /B:115200 /N:213.151.60.2,212.35.2.2 /U:xxx /P:yyy I never bothered about most of the other switches; some of them seem relevant only for specific machine conditions (/V, for instance: needed only if the machine is networked and that card then has its driver at that address commonly used precisely for packet drivers.) I wonder if the /F switch does anything at all - maybe even _slows_ the machine if changed from the default (of "1" - a commport which does have a FIFO buffer would get polled slower; a port setting of 115200 is way fast enough, in comparison with any real line speed of incoming bytes, even on stone-old '286s. "No buffer" means the same as 1 byte in a FIFO buffer and correspondingly, an irq request to get it; I doubt if even with 56K modems there would be overruns.) But the doc should be a little bit more verbose or rather, precise indeed (there are trivial syntax errors in the decription of the switches). // Heimo Claasen // <hammer at revobild dot net> // Brussels 2002-04-20 The WebPlace of ReRead - and much to read ==> http://www.revobild.net 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
