Re: dialup dns delay

On 15 Sep 2007, Erik G <erikgspm@xxxxxxxxxxxxxx> wrote:
As Tony Moore wrote on 14 Sep 2007:

[snip]

The high packet loss is evidenced by a long delay.

Not merely of a long delay. It is evidence of packets being lost. Your
ICMP packets do not arrive at 194.151.228.18, or the replies do not
make it back to your machine.

The DialUp status window shows that, during the delay period, zero bytes
are recieved (but maybe 2000 are sent).

However, pinging the DNS a second time (or a different address),
shows expected behaviour:

[snip]

Note that the two commands above do *not* cause an address resolution
by the DNS.

True. If I ping a URL, there is a long delay before it is resolved, but
the packet loss doesn't show:

*ping www.google.com
[50 seconds delay, zero bytes received]
PING www.l.google.com (209.85.135.147): 56 data bytes
64 bytes from 209.85.135.147: icmp_seq=0 ttl=242 time=360 ms
64 bytes from 209.85.135.147: icmp_seq=1 ttl=242 time=340 ms
64 bytes from 209.85.135.147: icmp_seq=2 ttl=242 time=320 ms
--- www.l.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 320.000/340.000/360.000 ms

Both pings are done directly to the IP address (which presumably is of
the ISP's primary DNS machine).

Correct.

Something is happening on the IP level, probably somewhere in the
dialup (SLIP) connection.

I believe that DialUp uses PPP. Could the delay be caused by a
malfunction in my RPC, or modem (USRobotics 56K Faxmodem 5631)?

The initial delay, above, might suggest that the ISP's DNS is broken
but, if my account is configured to use a _public_ DNS (known to
work correctly with a different ISP), similar results are obtained.

This supports the notion that there is no problem in the IPS's DNS. It
is a problem with the address resolution (ARP).

My guess is that you are given a dynamic IP address when you dail in,
and it takes a while before packets sent to your (newly established)
IP address actually start arriving at your machine.

That could explain why the first resolution is delayed, but subseqent
resolutions are not. However, I've had an account with this ISP for some
years, but the delay has surfaced only recently. It's always possible
that the ISP has made some 'imprvements'. I'll ask about it on Monday.

Erik, thank you for your response.

Tony



.

Relevant Pages

  • Re: my future telephones [telecom]
    ... sample was transmitted every 125 microseconds and, because of circuit ... each sample had the same delay reaching the other end. ... the data folks wanted very long packets. ... to echo depends on two factors, ...
    (comp.dcom.telecom)
  • dialup dns delay
    ... via wget, results in a delay of up to 60 seconds, while the DNS resolves ... To demonstrate this, if I ping the DNS, immediately after connecting: ... 54 packets transmitted, 3 packets received, 94% packet loss ... The high packet loss is evidenced by a long delay. ...
    (comp.sys.acorn.networking)
  • Re: my future telephones [telecom]
    ... sample was transmitted every 125 microseconds and, because of circuit ... each sample had the same delay reaching the other end. ... major delay for VoIP networks is the packetizing delay, ... the data folks wanted very long packets. ...
    (comp.dcom.telecom)
  • Re: tcp hostcache and ip fastforward for review
    ... It would probably break or delay many things. ... This is an unlikely case (many small packets sent to a non-interactive ... > for minmss it will reset and drop the connection. ... which is unfortunate. ...
    (freebsd-current)
  • Re: tcp hostcache and ip fastforward for review
    ... It would probably break or delay many things. ... This is an unlikely case (many small packets sent to a non-interactive ... > for minmss it will reset and drop the connection. ... which is unfortunate. ...
    (freebsd-net)