Professional Web Applications Themes

Curious pings on SCO 5.0.4/6 - SCO

Hello, sometimes we had on many SCO PC's with 5.0.4 and 5.0.6 very slow network conection. PING kasseob4 (10.22.136.54): 56 data bytes 64 bytes from kasseob4 (10.22.136.54): icmp_seq=3 ttl=62 time=40 ms 64 bytes from kasseob4 (10.22.136.54): icmp_seq=0 ttl=62 time=3080 ms 64 bytes from kasseob4 (10.22.136.54): icmp_seq=1 ttl=62 time=2080 ms 64 bytes from kasseob4 (10.22.136.54): icmp_seq=2 ttl=62 time=1090 ms 64 bytes from kasseob4 (10.22.136.54): icmp_seq=4 ttl=62 time=2240 ms 64 bytes from kasseob4 (10.22.136.54): icmp_seq=5 ttl=62 time=1240 ms 64 bytes from kasseob4 (10.22.136.54): icmp_seq=6 ttl=62 time=240 ms 64 bytes from kasseob4 (10.22.136.54): icmp_seq=7 ttl=62 time=2400 ms 64 bytes from kasseob4 (10.22.136.54): icmp_seq=8 ...

  1. #1

    Default Curious pings on SCO 5.0.4/6

    Hello,

    sometimes we had on many SCO PC's with 5.0.4 and 5.0.6 very slow
    network conection.

    PING kasseob4 (10.22.136.54): 56 data bytes
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=3 ttl=62 time=40 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=0 ttl=62 time=3080 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=1 ttl=62 time=2080 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=2 ttl=62 time=1090 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=4 ttl=62 time=2240 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=5 ttl=62 time=1240 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=6 ttl=62 time=240 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=7 ttl=62 time=2400 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=8 ttl=62 time=1400 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=9 ttl=62 time=400 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=13 ttl=62 time=40 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=10 ttl=62 time=3080 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=11 ttl=62 time=2080 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=12 ttl=62 time=1090 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=14 ttl=62 time=820 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=21 ttl=62 time=40 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=15 ttl=62 time=6110 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=16 ttl=62 time=5110 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=17 ttl=62 time=4120 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=18 ttl=62 time=3120 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=19 ttl=62 time=2120 ms
    64 bytes from kasseob4 (10.22.136.54): icmp_seq=20 ttl=62 time=1120 ms


    A PC, same HW, same OS, same NIC works fine connected at the same Hub.
    But sometimes another PC has this error which works fine a few weeks.

    Solution: Reboot

    The ping looks like a sinus curve, running in a loop.
    The RS 50x is installed.
    Nic: SMC EtherPower II Driver (ver 2.0.5)
    HW SMC EtherPower II 9432BFTX 10/100Mbps - PCI Bus# 0,Device#
    4,Funct


    Any ideas ?

    Stefan
    Stefan Guest

  2. #2

    Default Re: Curious pings on SCO 5.0.4/6

    In article <com>,
    Stefan Marquardt <de> wrote: 
     
     
     

    Some auto-negotiation could be failing. And if something goes into
    fdx mode the hubs are the culprit. Swithces are cheap enough to
    toss all the hubs into the trash.

    As to the large time going down to a slow time, that is typical of
    not being able to make the connection, and then when it opens up
    the timing of the first sent gets high, and then each succeeding
    one is lower as they are all answered sequentially in real time.

    Those times are very typical of an intermittent connection - and
    also something doing HDX on a FDX and generating collisions - which
    FDX doesn't have.

    You will be best served by fixing the port speeds on all NICs.




    --
    Bill Vermillion - bv wjv . com
    Bill Guest

  3. #3

    Default Re: Curious pings on SCO 5.0.4/6

    Bill Vermillion wrote:
     
     



    >
    > Some auto-negotiation could be failing. And if something goes into
    > fdx mode the hubs are the culprit. Swithces are cheap enough to
    > toss all the hubs into the trash.
    >
    > As to the large time going down to a slow time, that is typical of
    > not being able to make the connection, and then when it opens up
    > the timing of the first sent gets high, and then each succeeding
    > one is lower as they are all answered sequentially in real time.
    >
    > Those times are very typical of an intermittent connection - and
    > also something doing HDX on a FDX and generating collisions - which
    > FDX doesn't have.
    >
    > You will be best served by fixing the port speeds on all NICs.[/ref]

    Actually, those ping times are typical of DNS lookup failures. Or not
    failures, but timeouts.

    ping does its sending semi-autonomously, in the background, while it
    processes received packets in the foreground. It receives a packet,
    does a reverse DNS lookup to convert its IP address to a name. If that
    reverse lookup takes 5 seconds, no other received packets are processed
    during that time, but more packets are still _sent_ once a second by the
    background processing. Then the DNS lookup completes. ping reports the
    correct time for that first packet. The second packet was sent early in
    the DNS wait, but didn't get read until much later (after the DNS lookup
    completed), so its round-trip time is misreported. Each subsequent
    packet looks like it took 1 second less, because each was _sent_ one
    second later than the previous one.

    Now, the _cause_ of the DNS timeouts might be something like what you're
    talking about...
     
    Bela Guest

  4. #4

    Default Re: Curious pings on SCO 5.0.4/6

    In article <com>,
    Bela Lubkin <com> wrote: 

    >> 
    >> 
    >> 
    >>
    >> Some auto-negotiation could be failing. And if something goes into
    >> fdx mode the hubs are the culprit. Swithces are cheap enough to
    >> toss all the hubs into the trash.
    >>
    >> As to the large time going down to a slow time, that is typical of
    >> not being able to make the connection, and then when it opens up
    >> the timing of the first sent gets high, and then each succeeding
    >> one is lower as they are all answered sequentially in real time.
    >>
    >> Those times are very typical of an intermittent connection - and
    >> also something doing HDX on a FDX and generating collisions - which
    >> FDX doesn't have.[/ref][/ref]
     [/ref]
     

    I'd agree if the once the long numbers settled down to the lower
    numbers - eg going from 3000 down to 40, but going from 3080 to
    2080 to 1080 to 40 to 2240 to 1240 to 240 doesn't fit with any DNS
    I've seen. Once you have the DNS info all the times should settle
    down to a number that is similar except for delays.

    Also the packets are coming back out of sequence.

    I see packet order of 3,1,2,4,5,6,7,8,9,13,10,11,12,14,21 ...

    That surely does not indicate DNS to me. If I'm overlooking
    someting obvious in DNS please do let me know.
     

    And then the packet time would remain relatively even after the
    huge numbers decremented. I didn't explain large numbers to small
    numbers as well as you.
     

    Looking back at those sequence numbers and packets not being
    returned in order, do you still feel that way?

    It's almost as if some packets are taking a differnt route back.
    It definately is y.

    Bill
    --
    Bill Vermillion - bv wjv . com
    Bill Guest

  5. #5

    Default Re: Curious pings on SCO 5.0.4/6

    Bill Vermillion wrote:

    [regarding:]
     [/ref][/ref]

    Bela>> Actually, those ping times are typical of DNS lookup failures. Or not
    Bela>> failures, but timeouts.

    Bill> I'd agree if the once the long numbers settled down to the lower
    Bill> numbers - eg going from 3000 down to 40, but going from 3080 to
    Bill> 2080 to 1080 to 40 to 2240 to 1240 to 240 doesn't fit with any DNS
    Bill> I've seen. Once you have the DNS info all the times should settle
    Bill> down to a number that is similar except for delays.

    For whatever reason (I'll speculate in a moment), OSR5 `ping` does a
    reverse DNS lookup of _every_ packet it receives. It doesn't try to
    cache IP-to-name information. This is probably so that if you had a
    long-running ping and one day someone changed that address's name, ping
    would suddenly start reporting the new name. This _could_ have been
    implemented with a cache, some knowledge of DNS record timeouts, etc.,
    but it wasn't.

    The data above is _almost_ characteristic of OpenServer ping's handling
    of DNS timeouts. But after a closer look I think I agree that something
    different is going on.

    Look at packets number 0 1 2 3. Because ping is sending them
    monotonically at 1 second intervals, they were sent at times like
    1000000.23, 1000001.23, 1000002.23, 1000003.23. Now, if they had been
    received in sequence, here's what I would believe had happened: the
    first packet came back 40ms after it was sent. ping read the packet,
    noted that interval, did an RDNS lookup. The lookup took several
    seconds. While it was waiting, its background thread continued to send
    more pings, and their replies also came back in ~40ms each. But ping
    didn't read them until its foreground reader thread came back from the
    RDNS lookup, so _as far as it could tell_ they had taken much longer.
    The reply to the packet sent at 1000000.23 was received at 1000000.27,
    40ms later, and read immediately. The reply to the 1000001.23 packet
    was received at 1000001.27, but ping didn't _read_ it until 1000004.30,
    so it reported that as a ~3-second turnaround.

    But:

    Bill> Also the packets are coming back out of sequence.
    Bill>
    Bill> I see packet order of 3,1,2,4,5,6,7,8,9,13,10,11,12,14,21 ...
    Bill>
    Bill> That surely does not indicate DNS to me. If I'm overlooking
    Bill> someting obvious in DNS please do let me know.

    I think you're right, because of the out of order receipt. That means
    that there was blockage somewhere along the way. Some router between
    the two machines was holding either the outgoing packets or the replies
    -- _not_ losing them, just holding them and eventually letting them all
    fly at once. During this holding period they got out of order (which is
    fairly normal, routers do not guarantee in-order delivert). When ping
    finally received them back, it reported them as having taken various
    times about 1.0 second apart, because they all arrived at the same time
    but were _sent_ 1 second apart.

    Bela>> ping does its sending semi-autonomously, in the background,
    Bela>> while it processes received packets in the foreground. It
    Bela>> receives a packet, does a reverse DNS lookup to convert its
    Bela>> IP address to a name. If that reverse lookup takes 5 seconds,
    Bela>> no other received packets are processed during that time, but
    Bela>> more packets are still _sent_ once a second by the background
    Bela>> processing. Then the DNS lookup completes. ping reports the
    Bela>> correct time for that first packet. The second packet was sent
    Bela>> early in the DNS wait, but didn't get read until much later
    Bela>> (after the DNS lookup completed), so its round-trip time is
    Bela>> misreported. Each subsequent packet looks like it took 1 second
    Bela>> less, because each was _sent_ one second later than the previous
    Bela>> one.

    Bill> And then the packet time would remain relatively even after the
    Bill> huge numbers decremented. I didn't explain large numbers to small
    Bill> numbers as well as you.

    Bela>> Now, the _cause_ of the DNS timeouts might be something like
    Bela>> what you're talking about...

    Bill> Looking back at those sequence numbers and packets not being
    Bill> returned in order, do you still feel that way?
    Bill>
    Bill> It's almost as if some packets are taking a differnt route back.
    Bill> It definately is y.

    A router along the way is going into a mode where it collects but does
    not forward packets; then waking back up and forwarding several seconds
    worth of collected packets. The down time is plausible for e.g. an ISDN
    link to go through the stages of: link drops; router notices link is
    down; router redials; link comes back up.
     
    Bela Guest

  6. #6

    Default Re: Curious pings on SCO 5.0.4/6

    On Wed, 05 Nov 2003 18:05:05 GMT, comREMOVE (Bill Vermillion)
    wrote:
     

    How can i see whether it's half or full duplex from remote ?

    Device MAC address in use Factory MAC Address
    ------ ------------------ -------------------
    /dev/net1 00:04:e2:0a:84:10 00:04:e2:0a:84:10

    Multicast address table
    -----------------------
    01:00:5e:00:00:01

    FRAMES
    Unicast Multicast Broadcast Error Octets Queue Length
    ---------- --------- --------- ------ ----------- ------------
    In: 18597 0 4481 0 2725265 0
    Out: 18692 0 2 0 3830565 0

    DLPI Module Info: 2 SAPs open, 18 SAPs maximum
    473 frames received destined for an unbound SAP

    MAC Driver Info: Media_type: Ethernet
    Min_SDU: 14, Max_SDU: 1514, Address length: 6
    Interface speed: 100 Mbits/sec

    DLPI Restarts Info: Last queue size: 0
    Last send time: 5352483
    Restart in progress: 0
    Interface Version: MDI 100

    ETHERNET SPECIFIC STATISTICS

    Collision Table - The number of frames successfully transmitted,
    but involved in at least one collision:

    Frames Frames
    ------- -------
    1 collision 0 9 collisions 0
    2 collisions 0 10 collisions 0
    3 collisions 0 11 collisions 0
    4 collisions 0 12 collisions 0
    5 collisions 0 13 collisions 0
    6 collisions 0 14 collisions 0
    7 collisions 0 15 collisions 0
    8 collisions 0 16 collisions 0



    0 collisions = Switch ?



    Stefan

    Stefan Guest

  7. #7

    Default Re: Curious pings on SCO 5.0.4/6

    In article <com>,
    Bela Lubkin <com> wrote: 
     [/ref][/ref]
     
     
     

    That seems a rather bizarre way to do things. That's just from my
    way of thinking about things. Most of the things based on names
    lookup an IP for a given name. The chances that someone would
    change a name on an IP but that would typically be seen only on a
    local network would it not. As anything outside is going to rely
    on someone elses DNS and when the address/IP resolv is made up
    stream, even if it has to go to the root servers to get that IP
    initially, then the next level up will cache that name/ip
    resolution as long as the TTL is still valid. That's my
    impression, but I've never looked at the source code.
     

    Many readers on this list are fairly recent - eg since the new
    internet came up in the early-mid 1990s. But I've been reading
    your posts for 17 to 18 years - going back to the old Dr.Dobbs
    on Compuserve - and I dropped C'serve in '86 when I brought up
    my own usenet node. This is the first time I've ever had a single
    question about anything you posted, and I think I must finally be
    starting to understand all this mess. I save a good deal of your
    posts, and if I went back an searched the floppy archives I have
    I'd think I'd even find messages from your mother.
     
     

    I can envision that something somewhere is waiting until it gets a
    packet big enough to send a minimum amount of data, or waits a
    pre-determined interval to return that. But why I have no idea.

    But what we don't know is just how far apart the pinged IP is.
    The orginal poster had munged the original IP and gave no clue
    as to what/where it was. Long delays would/could be indicative
    of a typical land/satellite link. The sent data goes via land
    line, and the return data is intercepted as I recall at the level
    3 of the ISO stack, and diverted to an uplink and the down to the
    end user. That would almost guarantee a minimum of about 700ms.
    And I would think you really would want to aggregate the data
    and send in bigger chunks.

    I've read about problems on what are called 'elephants' [ELFN -
    Exteremely Long Fat Networks - very high speed distant links where
    they make the packets HUGE and have large windows, otherwise
    the data is slowed by the handshake/protocols/etc of small packets
    and few outstanding]. Probably has nothing to do with this, but it
    reminded me of disusssion I'd recentely seen.
     
     
     
     

    That had not crossed my mind as I've not worked with ISDN in quite
    awhile - though at one ISP we had several using it - they thought
    it would be cheaper. We propopsed a dedicated T1 from Florida
    to Ohio, but they looked at the ISDN cost, and did not realized
    there was a connect charge on each connection, and running a
    remote mail kiosk they figured it would be cheaper than the $1500
    for the PtP T. When they got their first phone bill of over
    $5000 they realized that we did know what we were talking about.

    So and ISDN could be it - and IF the line is used as voice and IP
    - then the data channel will drop back to 64K when the vox is in
    use. However now that many places are out-sourcing their dialup
    systems getting a bondable ISDN is almost impossible as to
    bond them you have to come in on the same PRI. At one place
    their 'modem' bank occupied about 15 feet of rack space. Each
    rack had at least 5 of the Lucent/Max - each with a DS3 and each
    handling about 600 lines. So with about 30,000 lines available
    it would be only by extreme chance you could get two links into the
    same PRI, so that's why the only way to get a bonded system is
    direct from telco, if that's still possible.

    This is an interesting problem, and if any of our theories are
    correct - then it will probably be solved only by an onsite person
    who knows networking intimately.

    Bill

    --
    Bill Vermillion - bv wjv . com
    Bill Guest

  8. #8

    Default Re: Curious pings on SCO 5.0.4/6

    On Thu, 06 Nov 2003 16:02:00 +0100, Stefan Marquardt
    <de> wrote:
     

    I couldn't find any incantation that displays this.

    You may wanna run:
    ndstat -l
    and see if there are any obvious errors. However, I suspect you won't
    find any.

    If your target is local, see if you can create errors by using ping
    flood.
    ping -f target_IP
    Hopefully, this will give ndstat something to chew upon.

    My guess(tm) is that you have a bad switch, bad cable, miswired cable,
    or 100baseT to 10baseT transition where the internal buffer in the
    switch is losing packets. If the switch is a managed switch with an
    IP address, try pinging the switch and see if the problem persists.
    Also see if you can extract SNMP statistics from the switch if it's a
    managed switch. Also try pinging other machines on the network. The
    idea is to isolate the common network segment that's causing a
    problem.

    I've also successfully induced a similar problem with some creative
    wiring on the ethernet cable. I had the polarity of on of the data
    wires reversed. Everything sorta functioned but I had lots of delays
    that did NOT show up on the server diagnostic output. The switch and
    card were apparently spending their time doing almost continuous NWAY
    negotiations. The only clue was that the lights on the switch port
    would sometimes do a weird dance when there was no traffic. It was
    difficult to see as it sorta looked like normal traffic. If you have
    any home made cables, I suggest you check them.

    Since the target machine is on the local LAN, I can safely assume that
    all packets are coming and going directly to the target and are NOT
    being routed through some circuitous route. Just to be sure, run:
    netstat -rn
    and see if the routing table looks sane.

    There are two different chips used on this card. The old one uses a
    DEC Tulip chip. The current version uses an "Epic" 83C170 chip. The
    Linux Epic driver code mentions that some chips have a hardware
    multicast filter flaw. That should not affect ping which is unicast.
    http://www.scyld.com/network/epic100.html



    --
    Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
    (831)421-6491 pgr (831)336-2558 home
    http://www.LearnByDestroying.com AE6KS
    santa-cruz.ca.us com
    Jeff Guest

  9. #9

    Default Re: Curious pings on SCO 5.0.4/6

    In article <com>,
    Stefan Marquardt <de> wrote: 
    >
    >How can i see whether it's half or full duplex from remote ?
    >
    >Device MAC address in use Factory MAC Address
    >------ ------------------ -------------------
    >/dev/net1 00:04:e2:0a:84:10 00:04:e2:0a:84:10
    >[/ref]
    <snip>
     

    Sco Openserver 5.0.5 by default sets the Nic Cards to Auto negotiate.
    i quote from space.h in /etc/conf/pack.d/e3H/space.h

    "Media type may be overridden. Default is to let the NIC determine
    the speed and duplex mode."

    For a good description of this, go to Tony's site at:

    http://aplawrence.com/SCOFAQ/scotec4.html#duplexspeed

    Dave
    Dave Guest

  10. #10

    Default Re: Curious pings on SCO 5.0.4/6

    On Thu, 6 Nov 2003 00:38:05 GMT, Bela Lubkin <com> wrote:
     

    Duz it also do this if one pings by IP address instead of by name?
    One would assume that the IP address doesn't change in mid session and
    therefore does not require a reverse DNS lookup.

    --
    Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
    (831)421-6491 pgr (831)336-2558 home
    http://www.LearnByDestroying.com AE6KS
    santa-cruz.ca.us com
    Jeff Guest

  11. #11

    Default Re: Curious pings on SCO 5.0.4/6

    In article <3faa79d1$0$41289$visi.com>,
    Dave Gresham <com> wrote: 
    >>
    >>How can i see whether it's half or full duplex from remote ?
    >>
    >>Device MAC address in use Factory MAC Address
    >>------ ------------------ -------------------
    >>/dev/net1 00:04:e2:0a:84:10 00:04:e2:0a:84:10
    >>[/ref]
    ><snip>

    >
    >Sco Openserver 5.0.5 by default sets the Nic Cards to Auto negotiate.
    >i quote from space.h in /etc/conf/pack.d/e3H/space.h[/ref]
     
     
     

    And for a very good description on what happens when things are
    mis-matched see http://www.cisco.com/warp/public/473/46.html

    Though it was written about a Cisco switch it doents how
    manufacturers adding their own ehancements make the the
    problem of automatically determing duplex mode and the transfer
    speed impossible in some cirstanes. A chart shows what happens
    in each of the instances.


    --
    Bill Vermillion - bv wjv . com
    Bill Guest

  12. #12

    Default Re: Curious pings on SCO 5.0.4/6

    Bill Vermillion wrote:
     
     
    >
    > That seems a rather bizarre way to do things. That's just from my
    > way of thinking about things. Most of the things based on names
    > lookup an IP for a given name. The chances that someone would
    > change a name on an IP but that would typically be seen only on a
    > local network would it not. As anything outside is going to rely
    > on someone elses DNS and when the address/IP resolv is made up
    > stream, even if it has to go to the root servers to get that IP
    > initially, then the next level up will cache that name/ip
    > resolution as long as the TTL is still valid. That's my
    > impression, but I've never looked at the source code.[/ref]

    You could have a "link watcher daemon" running, something like:

    # Record link status every 2 minutes, forever

    ping -i 120 123.456.789.012 > /usr/spool/linkwatch 2>&1 &

    If the owner of "123.456.789.012" changed its name one day, it would
    eventually show up in your log. Maybe not right away, because even
    though ping did an RDNS lookup for every packet, the server might not
    time out the old name for a few hours. But eventually it would see the
    name change.

    ping could have some awareness of DNS TTL, and only re-lookup an address
    whose expiration time had passed. The fact is, it doesn't.
     
    >
    > I can envision that something somewhere is waiting until it gets a
    > packet big enough to send a minimum amount of data, or waits a
    > pre-determined interval to return that. But why I have no idea.
    >
    > But what we don't know is just how far apart the pinged IP is.
    > The orginal poster had munged the original IP and gave no clue
    > as to what/where it was. Long delays would/could be indicative
    > of a typical land/satellite link. The sent data goes via land
    > line, and the return data is intercepted as I recall at the level
    > 3 of the ISO stack, and diverted to an uplink and the down to the
    > end user. That would almost guarantee a minimum of about 700ms.
    > And I would think you really would want to aggregate the data
    > and send in bigger chunks.
    >
    > I've read about problems on what are called 'elephants' [ELFN -
    > Exteremely Long Fat Networks - very high speed distant links where
    > they make the packets HUGE and have large windows, otherwise
    > the data is slowed by the handshake/protocols/etc of small packets
    > and few outstanding]. Probably has nothing to do with this, but it
    > reminded me of disusssion I'd recentely seen.[/ref]

    The fastest packets in the original ping output were 40ms -- clearly not
    a satellite or anything particularly weird. In fact let me re-quote a
    bit of it:
     [/ref][/ref]

    Bear in mind that each sequential packet is _sent_ 1 second after the
    previous one. So if two packets were sent at times 100000.23 and
    100001.23, and both were received simultaneously at 100002.50, what
    would ping report? It would show 2270ms for the first and 1270ms for
    the second. If we assume that the above four packets were sent at exact
    1-second interval, they were received at almost exactly the same time:

    icmp_seq=3 time=40 ms sent=100003.23 received=100003.27
    icmp_seq=0 time=3080 ms sent=100000.23 received=100003.31
    icmp_seq=1 time=2080 ms sent=100001.23 received=100003.31
    icmp_seq=2 time=1090 ms sent=100002.23 received=100003.32

    I built that by assigning an arbitrary time to the first packet
    (100000.23), then adding 1.00 second to each according to its sequence
    number, then adding the reported round-trip time. This reads as if some
    part of the link was down for at least 3 seconds, delaying either the
    outbound or return trip of packets 0-2. The delay between return
    receipt of packets 3 & 0 suggests that other data was also stuck in the
    buffers, otherwise all 4 returns would have been received back to back.

    The fact that packets 0 & 1 were received during the same 10ms timer
    tick sets a lower limit on the speed of the slowest link -- if those
    packets were traveling back to back, the slowest link must be able to
    transmit at least 64 bytes per 10ms, or 6400 bytes/sec, or approximately
    64Kbps. We don't know much about upper limit (any number of other,
    non-ping packets could have been traveling at the same time).
     [/ref][/ref]

    This bit shows that the link sometimes goes down for as much as 6
    seconds at a time.

    In each of these two examples, we got back the last sequential packet
    first, and its time was very low. Many router-like devices have
    behaviors where receiving a packet to a particular known remote
    destination will cause link bring-up. It seems likely that the packet
    which caused link bring-up would also travel the link first. It is also
    common that packets already in holding buffers will not actively cause
    link bring-up (that is, the router may attempt bring-up when the packet
    is first received, but if it is unsuccessful, it won't try again until
    _another_ packet triggers the behavior). This router is pretty good
    about keeping packets in received order, but the bring-up triggering
    behavior causes the small amount of disordering we see in the output.

    Two other segments are different:
     [/ref][/ref]
     [/ref][/ref]

    In each of these segments, it looks like some _other_ packet, other
    business this system had with stuff over the link, caused link bring-up.
    None of the ping packets are out of order, and the newest packet clearly
    had been held up for longer than the physical link turnaround time.

    This ysis seems like exactly the sort of thing that an expert system
    could be good at. Sure enough, searching on ``"expert system" ping
    routers troubleshooting'' turns up a bunch of matches. I wonder if any
    of them are actually any good?

    I suspect the original sample we were shown was during an especially bad
    period, that usually pings are clean with only occasional excursions. I
    bet if we had 1000 pings' worth of results, we could diagnose it much
    more closely (or at least an expert system could, it would have the
    patience...)
     
    Bela Guest

  13. #13

    Default Re: Curious pings on SCO 5.0.4/6

    Jeff Liebermann wrote:
     
    >
    > Duz it also do this if one pings by IP address instead of by name?
    > One would assume that the IP address doesn't change in mid session and
    > therefore does not require a reverse DNS lookup.[/ref]

    `ping` _does_ do RDNS lookups on numeric pings:

    $ ping -c 1 192.122.209.42
    PING 192.122.209.42 (192.122.209.42): 56 data bytes
    64 bytes from deepthought.armory.com (192.122.209.42): icmp_seq=0 ttl=51 time=80 ms

    --- 192.122.209.42 ping statistics ---
    1 packets transmitted, 1 packets received, 0% packet loss
    round-trip min/avg/max = 80/80/80 ms

    If you want to suppress RDNS lookups, use "-n".
     
    Bela Guest

  14. #14

    Default Re: Curious pings on SCO 5.0.4/6

    On Thu, 6 Nov 2003 18:36:09 GMT, Bela Lubkin <com> wrote:
     
    >>
    >> Duz it also do this if one pings by IP address instead of by name?
    >> One would assume that the IP address doesn't change in mid session and
    >> therefore does not require a reverse DNS lookup.[/ref][/ref]
     [/ref]

    Good. Then it can be suppressed. May I suggest that Mr Marquardt try
    it with:
    ping -n 10.22.136.54
    which should either identify or eliminate DNS as the probable culprit.


    --
    # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
    # 831.336.2558 voice http://www.LearnByDestroying.com
    # santa-cruz.ca.us
    # 831.421.6491 digital_pager com AE6KS
    Jeff Guest

  15. #15

    Default Re: Curious pings on SCO 5.0.4/6

    In article <com>,
    Bela Lubkin <com> wrote: [/ref]
     [/ref][/ref]

    ....
     [/ref]
     
     
     
     

    On the machines that are in my rackspace [even client machines that
    I don't have access to] I run 'arpwatch'.

    As to pinging every 2 minutes and then logging, one approach would
    be to record the data to a file. Then the next time it runs, do a
    diff on the new run vs the file, and if it's the same throw it
    away. If it changes, save the old file with an extension, save the
    new data, and send email to the admin. My BSD servers do a similar
    check everyday for any changes at all to any SUID/SGID files
    regarding size, time, owners etc. I hate logs that have too much
    redundant data.
     

    Is this behavior only with the OSR5 ping or is it this way in UW7
    also. But I tend to use pings differently as mostly I'm in a
    different environment. Trying to isolate a problem that we could
    not determine if it was telco or our side, the telco guy built a 3
    city/state loop to test an ATM circuit that seemed to fail after a set
    number of bytes. So we did a flood ping with 1000 byte packets
    and had a 3rd person monitoring via serial and found a buffer
    overflow that locked a router, which then was able to sense that
    and reset itself. So I look at pings different and the RDNS each
    time doesn't fit my mindset. So thanks for that information.

    ....
     

    Yup. I was just thinking of different things on the long pings and
    all I did was cloud the issue. Sorry about that.
     [/ref][/ref]
     
     
     

    I think Jeff's take on a bad switch or cable may be it. An FDX/HDX
    mismatch could also be it, if the HDX failed [and it would because
    the FDX doesn't use collisions] then it backs off for a retry as
    it is supposed to. I think I mentioned checking things like that
    in the first reply.

    ....
     

    I see that.

    I hope that when this is resolved the original poster will give us
    the details of the problem. So often we see question, and answers
    given, and then don't know what fixed it.
     

    Typical of many things I've seen. Not quite enough data to really
    know what is going on.

    I'll bow out of this thread for now.

    Thanks for all the information

    Bill


    --
    Bill Vermillion - bv wjv . com
    Bill Guest

  16. #16

    Default Re: Curious pings on SCO 5.0.4/6

    On 06 Nov 2003 16:41:53 GMT, com (Dave Gresham) wrote:
     

    I don't find anything with "ndstat -l" whether it's running
    full-duplex or not.

    I thinks this tool isn't correct.

    I just makes some test with a 1GB card from Broadcom in another SCO
    5.0.7 host

    ndstat shows 1000 Mbit
    If i reconnect the cable i got 100MB full duplex on the console and
    all switsch shows 100MB halfduplex.

    Stefan

    Stefan Guest

  17. #17

    Default Re: Curious pings on SCO 5.0.4/6

    On Thu, 06 Nov 2003 08:37:12 -0800, Jeff Liebermann
    <santa-cruz.ca.us> wrote:
     

    Connect nic -> 3com SuperStack II switching hub -> Cisco -> Cisco ->
    Host.

    Next curious thing (i did all remote)
    I set on kasseob4 the speed fix to 100MB and halfduplex.
    During the system comes up the customer told me that the PC behind him
    (same HW except nic -> 3com ISA) lost network connection.
    I first couldn't trust it that i was the cause for the error !
    I started some ping to this PC from the host and after 16 seconds i
    got the first ping back:

    PING kasseob3 (10.22.136.53): 56 data bytes
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=0 ttl=62 time=18780 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=1 ttl=62 time=17800 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=2 ttl=62 time=16790 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=3 ttl=62 time=15780 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=4 ttl=62 time=14780 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=5 ttl=62 time=13790 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=6 ttl=62 time=12790 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=7 ttl=62 time=11790 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=8 ttl=62 time=10790 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=9 ttl=62 time=9790 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=10 ttl=62 time=8790 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=11 ttl=62 time=7800 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=12 ttl=62 time=6800 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=13 ttl=62 time=5810 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=14 ttl=62 time=4810 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=15 ttl=62 time=3810 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=16 ttl=62 time=2810 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=17 ttl=62 time=1810 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=18 ttl=62 time=810 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=19 ttl=62 time=190 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=20 ttl=62 time=40 ms
    64 bytes from kasseob3 (10.22.136.53): icmp_seq=21 ttl=62 time=100 ms

    We redo that.
    100% the host kasseob4 with the fixed speed knocks out for a few
    seconds kasseob3 and the pings reduce one second / second.
    kasseob4 had no conenction with the fixed speed i have to lead the
    customer through netconfig to change it back.

    This problem happens every month 1-2 times.


    The new problem with knocking out the other PC is very funny.

    I send a technical assistance to the customer to check hub and cables.

    Regards,
    Stefan
    Stefan Guest

  18. #18

    Default Re: Curious pings on SCO 5.0.4/6

    On Thu, 06 Nov 2003 22:35:11 GMT, Jeff Liebermann
    <santa-cruz.ca.us> wrote:
     [/ref]
    > [/ref]
    >
    >Good. Then it can be suppressed. May I suggest that Mr Marquardt try
    >it with:
    > ping -n 10.22.136.54
    >which should either identify or eliminate DNS as the probable culprit.[/ref]


    Just i got the same error at another customer where the PC is
    connected local:

    # > ping -n 10.18.24.43
    PING 10.18.24.43 (10.18.24.43): 56 data bytes
    64 bytes from 10.18.24.43: icmp_seq=2 ttl=64 time=0 ms
    64 bytes from 10.18.24.43: icmp_seq=0 ttl=64 time=2020 ms
    64 bytes from 10.18.24.43: icmp_seq=1 ttl=64 time=1010 ms
    64 bytes from 10.18.24.43: icmp_seq=3 ttl=64 time=2400 ms
    64 bytes from 10.18.24.43: icmp_seq=4 ttl=64 time=1390 ms
    64 bytes from 10.18.24.43: icmp_seq=5 ttl=64 time=390 ms
    64 bytes from 10.18.24.43: icmp_seq=10 ttl=64 time=0 ms
    64 bytes from 10.18.24.43: icmp_seq=6 ttl=64 time=4040 ms
    64 bytes from 10.18.24.43: icmp_seq=7 ttl=64 time=3030 ms
    64 bytes from 10.18.24.43: icmp_seq=8 ttl=64 time=2020 ms
    64 bytes from 10.18.24.43: icmp_seq=9 ttl=64 time=1010 ms
    64 bytes from 10.18.24.43: icmp_seq=15 ttl=64 time=0 ms
    64 bytes from 10.18.24.43: icmp_seq=11 ttl=64 time=4040 ms
    64 bytes from 10.18.24.43: icmp_seq=12 ttl=64 time=3030 ms
    64 bytes from 10.18.24.43: icmp_seq=13 ttl=64 time=2020 ms
    64 bytes from 10.18.24.43: icmp_seq=14 ttl=64 time=1010 ms
    64 bytes from 10.18.24.43: icmp_seq=16 ttl=64 time=2390 ms
    64 bytes from 10.18.24.43: icmp_seq=17 ttl=64 time=1380 ms
    64 bytes from 10.18.24.43: icmp_seq=18 ttl=64 time=370 ms
    
    --- 10.18.24.43 ping statistics ---
    20 packets transmitted, 19 packets received, 5% packet loss
    round-trip min/avg/max = 0/1660/4040 ms

    i use ping -n : no DNS problem

    I make a rlogin to it (very slow) and try a ping on localhost:

    kassedo3 >ping -c20 localhost
    PING localhost (127.0.0.1): 56 data bytes
    64 bytes from localhost (127.0.0.1): icmp_seq=0 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=8 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=9 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=10 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=11 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=12 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=13 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=14 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=15 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=16 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=17 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=18 ttl=64 time=0 ms
    64 bytes from localhost (127.0.0.1): icmp_seq=19 ttl=64 time=0 ms

    After rebooting the PC:

    sender > ping kassedo3
    PING kassedo3 (10.18.24.43): 56 data bytes
    64 bytes from kassedo3 (10.18.24.43): icmp_seq=0 ttl=64 time=10 ms
    64 bytes from kassedo3 (10.18.24.43): icmp_seq=1 ttl=64 time=0 ms
    64 bytes from kassedo3 (10.18.24.43): icmp_seq=2 ttl=64 time=0 ms
    64 bytes from kassedo3 (10.18.24.43): icmp_seq=3 ttl=64 time=0 ms
    64 bytes from kassedo3 (10.18.24.43): icmp_seq=4 ttl=64 time=0 ms
    64 bytes from kassedo3 (10.18.24.43): icmp_seq=5 ttl=64 time=0 ms
    
    --- kassedo3 ping statistics ---
    6 packets transmitted, 6 packets received, 0% packet loss
    round-trip min/avg/max = 0/1/10 ms


    Regards,
    Stefan
    Stefan Guest

  19. #19

    Default Re: Curious pings on SCO 5.0.4/6

    Stefan Marquardt typed (on Fri, Nov 07, 2003 at 02:46:25PM +0100):
    | On 06 Nov 2003 16:41:53 GMT, com (Dave Gresham) wrote:
    |
    | >For a good description of this, go to Tony's site at:
    | >
    | >http://aplawrence.com/SCOFAQ/scotec4.html#duplexspeed
    |
    | I don't find anything with "ndstat -l" whether it's running
    | full-duplex or not.
    |
    | I thinks this tool isn't correct.
    |
    | I just makes some test with a 1GB card from Broadcom in another SCO
    | 5.0.7 host
    |
    | ndstat shows 1000 Mbit
    | If i reconnect the cable i got 100MB full duplex on the console and
    | all switsch shows 100MB halfduplex.

    Did you install the Broadcom driver that SCO provided on Aug 25th?

    --
    JP
    Jean-Pierre Guest

  20. #20

    Default Re: Curious pings on SCO 5.0.4/6

    In article <com>,
    Stefan Marquardt <de> wrote: 
     
    >
    >Connect nic -> 3com SuperStack II switching hub -> Cisco -> Cisco ->
    >Host.
    >
    >Next curious thing (i did all remote)
    >I set on kasseob4 the speed fix to 100MB and halfduplex.
    >During the system comes up the customer told me that the PC behind him
    >(same HW except nic -> 3com ISA) lost network connection.[/ref]
    -----------------------------^^^^--- that's really old technology,
    and the card could be failing. Can you put in a new faster
    PCI card?

    And as to the Cisco, be sure to check that link I posted in a
    message or so back from the Cicso site. Follow that doc and look
    at all the possible choices, and do set things up the way they say
    on everything and you might be working again.
     

    Now that really sounds like something is in automatic mode and
    failing to get the correct duplex setting. Getting the wrong
    speed - unless something is doing conversion - just fails.
     
     

    Have him check all the settings discussed in the Cisco doent.


    --
    Bill Vermillion - bv wjv . com
    Bill Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Curious
    By texas_stingray in forum Macromedia Flex General Discussion
    Replies: 1
    Last Post: May 5th, 06:22 PM
  2. Server-Side Pings and Index Pages
    By deane_b in forum Macromedia Contribute General Discussion
    Replies: 1
    Last Post: February 11th, 12:24 AM
  3. tweaking acks and pings
    By bearclaw@cruller.invalid in forum Mac Networking
    Replies: 0
    Last Post: July 13th, 03:41 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139