Re: Telnet over WAN latency troubleshooting

Rich Jordan wrote:
> modems is showing 3-4% packet loss to one location, 0% to the other,
> with equivalent times (50-60ms for 64 byte packets, 70-120ms for 372
> byte packets, no time to test larger). Both sites were experiencing
> significant latency before, during, and after testing.

Have you tried pinging with ever increasing packet sizes ? You can use
that to determine the effective MTU between two points. (once your
exceed MTU, pings have 100% packet loss). And also, I find odd that
your ping times would increase so significantly by going from 64 to 372
byte packets.


> The central modem's log showed a series of disconnect/reconnect at the
> PPPoE level on 1/23 after 9:15PM,

After such a disconnect, you SHOULD be able to call your ISP and get
them to tell you what their logs show as reason for session drop. 21:15
is an odd time for maintenance.

Of course, if you have a huge ISP, you're out of luck because they are
unlikely to cater to individual customers to that level. The guys who
answer the phone at large ISPs don't have access to such logs.


You also need to determine if the modem lost DSL signal at about the
same times as the PPPoE session drops. This would indicate a problem on
the phone line between your premise and the telco's CO/DSLAM.

> I'll do bidirectional testing tomorrow. I'll also try to find out
> about any MTU padding on the modems. I can't find any way to change
> that on the DECservers,


The padding issue is at the PPPoE level. It is one of those "may do"
things that come from PPP days. So on your DECservers, it woudln't be an
issue at all. And not all PPPoE routers do the padding. I think that
some older Linksys routers did it.


Another thing to do is to get yourDSL modem to report on line quality.
It will give you two sets decibel levels for transmit and receive. One
minus the otger gives you the spare "bandwidth".

You might get something like:

> 3Com-DSL>show adsl trans
> ADSL Transceiver Status Report:
> Operational Mode operational
> Attenuation Upstream 16.0 dB
> Attenuation Downstream 28.5 dB
> Noise Margin Upstream 15.0 dB
> Noise Margin Downstream 21.5 dB
> Transmit Power (ATUR) 12.0 dBm
> Transmit Power (ATUC) 19.5 dBm
> Actual Negotiated Downstream Baud Rate: 3008000 bps
> Actual Negotiated Upstream Baud Rate: 800000 bps

The Noise margin should be 10 or more. Below 6 and trouble starts to happen.
.

Relevant Pages

  • Re: Beyond multicore
    ... Transmission systems are not perfect, ... At the other end there is a decoder that wants to take the packet, ... We can do packet loss concealment. ... See ITU-T G.729B or ETSI/3GPP GSM 06.90 for a thorough treatise ...
    (comp.arch)
  • Re: Copy hangs - File opened twice?
    ... If the BIG file is copied temporarily locally to server_1 and the batch job ... If all works "locally" then really all you have is the network, ... tcp/IP MTU value and when a PC filled a packet ... Some packet loss is to be expected but above a certain ...
    (microsoft.public.win2000.file_system)
  • Re: CPU utilisation cap?
    ... hopefully some possible scheduler effects), and might shed more light on ... i.e., when a packet source sends a UDP packet, does it ... > a sampling process that polls the kernel's notion of CPU% measurement ... What I see is little-to-no packet loss ...
    (freebsd-performance)
  • Re: Gigabit copper losing half speed but only in one direction! Any ideas?
    ... > reboot, but the results were the same. ... > source for the TCP transmission does the bandwidth tank. ... Packet loss in the direction of sending is a bigger deal than packet ...
    (comp.unix.solaris)
  • Re: Unreliable Unix Domain DGRAM socket?
    ... We know, in theory, it is unreliable, but in reality, I rarely see packet loss happens to this type of socket. ... If the sending buffer of socket_A is ok but the receiving buffer of socket_B is full, ...
    (freebsd-net)