dialup dns delay



Recently, my dialup connection, using Hermes/MPro/Netsurf/wget/RO6.06,
has been subject to a delay, and I should be grateful if someone could
suggest its cause.

Usually, my modem negotiates a V90 link to the ISP's server, at 46,666
bps, suggesting that the quality of the telephone line is not an issue.
Username/password details are then sent, and accepted, without problem.

However, as of a few weeks ago, launching a URL via browser, or download
via wget, results in a delay of up to 60 seconds, while the DNS resolves
the IP address of the URL. This happens at the _start_ of each_and_every
dialup session but, after the first URL has been resolved, launching a
second URL proceeds normally, without delay.

To demonstrate this, if I ping the DNS, immediately after connecting:

PING 194.151.228.18 (194.151.228.18): 56 data bytes
64 bytes from 194.151.228.18: icmp_seq=50 ttl=246 time=320 ms
64 bytes from 194.151.228.18: icmp_seq=51 ttl=246 time=300 ms
64 bytes from 194.151.228.18: icmp_seq=53 ttl=246 time=260 ms
--- 194.151.228.18 ping statistics ---
54 packets transmitted, 3 packets received, 94% packet loss
round-trip min/avg/max = 260.000/293.333/320.000 ms

The high packet loss is evidenced by a long delay. However, pinging the
DNS a second time (or a different address), shows expected behaviour:

PING 194.151.228.18 (194.151.228.18): 56 data bytes
64 bytes from 194.151.228.18: icmp_seq=0 ttl=246 time=290 ms
64 bytes from 194.151.228.18: icmp_seq=1 ttl=246 time=340 ms
64 bytes from 194.151.228.18: icmp_seq=2 ttl=246 time=320 ms
--- 194.151.228.18 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 290.000/316.666/340.000 ms

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. Something
is clearly wrong, but the IPS's technical staff say that they can find
nothing amiss.

Can anyone please suggest where I, or the ISP, should look for the cause
of the problem?

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)
  • 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: dialup dns delay
    ... Not merely of a long delay. ... It is evidence of packets being lost. ... the ISP's primary DNS machine). ...
    (comp.sys.acorn.networking)
  • 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)