Date: Sun, 21 May 2006 16:03:39 -0400 From: Mike Tancsa <mike@sentex.net> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-net@freebsd.org, Brian Candler <B.Candler@pobox.com> Subject: Re: improving transport over lossy links ? Message-ID: <6.2.3.4.0.20060521154616.11bd1d60@64.7.153.2> In-Reply-To: <Pine.BSF.3.96.1060522014929.24481E-100000@gaia.nimnet.asn. au> References: <6.2.3.4.0.20060521104147.081af2d8@64.7.153.2> <Pine.BSF.3.96.1060522014929.24481E-100000@gaia.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:53 PM 21/05/2006, Ian Smith wrote:
> > Its not so much data corruption of packets on the wire, but
> > the modem dropping the connection, retraining and
> > renegotiating. When the retrains and re negotiations happen, this
> > can cause problems for the VPN as keep alives are missed, tx buffers
> > can fill up etc. I have tried a number of modems, the current one
> > being U.S. Robotics 56K FAX INT V5.22.70. and I am also trying an
> > external Intel at the office
>
>Yes that's just the problem alright. Just to be clear, you're referring
>here only to various calling-in modems, calling to these fixed terminal
>server cards, of maybe Lucent origin, right?
Hi,
Correct. Its always dialing into a terminal server that is connected
via PRIs. Usually Lucent PM3, sometimes Cisco 5800s depending on the
location they dial from.
> > The internal USR seems to correctly see the carrier drop and PPP
> > hence sees it. However, the 2 external Intels I am experimenting
> > with on the USB serial ports do not. I suspect thats part of the
> > reason the DCD is not working. Perhaps incorrect init string or
> > something with the USB-Serial. Note, I only have the internal USRs
> > deployed in the field right now
>
>Don't know about USB modems. Do USR still use their own chipsets, or
>what? In any case, they're probably highly tunable and well documented.
Actually, they are just regular external modems connected to USB to
serial adaptors (using the uftdi driver)
>Not V.90 full tilt, anyway. If 45333 is sort of usual for this one,
>then I'd probably try telling it to connect no higher than maybe 41333
>or 40000; often about 10-15% or so less than 'normal' can make all the
>difference. If you can afford the bandwidth, go for slow and solid ..
Yes, for sure I will try and lower the speeds a bit, but ultimately I
want to deal with situations where the carrier drops and the modem
has to redial. The client is willing to put in an extra phone line
if it would make the link more reliable. Typically these sites are
too remote for other types of transport. I think if I can get mp
working with reliable dcd I think that should do it.
---Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.2.3.4.0.20060521154616.11bd1d60>