combination of packet delay and bandwith - TCP-IP

This is a discussion on combination of packet delay and bandwith - TCP-IP ; As we can see there is an direct combination on packet delay and bandwith in the following point. When we override the maximum bandwith in sending more data than its possible the packetdelay rises significant. Thats to be easily comprehensible ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: combination of packet delay and bandwith

  1. combination of packet delay and bandwith

    As we can see there is an direct combination on packet delay and
    bandwith in the following point. When we override the maximum bandwith
    in sending more data than its possible the packetdelay rises
    significant. Thats to be easily comprehensible if we do a ping on a ip
    address in internet and uploading something to another direction on
    the same interface (ppp0 or so) the ping times are something like
    that:

    Antwort von 78.47.168.34: Bytes=32 Zeit=79ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=58ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=64ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=58ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=91ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=56ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=61ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=62ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=74ms TTL=56
    (begin upload)
    Antwort von 78.47.168.34: Bytes=32 Zeit=136ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=166ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=163ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=133ms TTL=56
    Antwort von 78.47.168.34: Bytes=32 Zeit=152ms TTL=56

    My questions are
    1. Is it possible to detect the overriding in that way or are there
    other possibilities to detect overriding the possible bandwith
    2. Is this rising RTT reasoned in waiting for delivery of the icmp
    packet in the modem internal queue (because it have to wait because
    overriding bandwith) ?

    Greetings from Robert

  2. Re: combination of packet delay and bandwith

    On 2008-05-07 10:13:04 -0400, rupat said:

    > My questions are
    > 1. Is it possible to detect the overriding in that way or are there
    > other possibilities to detect overriding the possible bandwith
    > 2. Is this rising RTT reasoned in waiting for delivery of the icmp
    > packet in the modem internal queue (because it have to wait because
    > overriding bandwith) ?



    You've got a good troubleshooting mind, R - but I'd like to see you
    take it further to get a better answer for yourself. Expand your
    troubleshoot to take a packet trace from the PPP0 interface and take a
    look directly at how the data is flowing through the transfer, where
    the ICMP packets are mingled with that flow, and whether or not you're
    seeing any unexpected fragmentation / re-assembly effects.

    > (begin upload)
    > Antwort von 78.47.168.34: Bytes=32 Zeit=136ms TTL=56
    > Antwort von 78.47.168.34: Bytes=32 Zeit=166ms TTL=56
    > Antwort von 78.47.168.34: Bytes=32 Zeit=163ms TTL=56
    > Antwort von 78.47.168.34: Bytes=32 Zeit=133ms TTL=56
    > Antwort von 78.47.168.34: Bytes=32 Zeit=152ms TTL=56



    See, this looks like a queueing or fragmentation effect because of the
    approximately +/-30ms return times in the PING, which I don't like for
    measurement, but the pattern is evident here - the unchanging TTL at
    least speaks to the same routed path, so one could guess that you might
    be fragmenting / reassembling as your transfer protocol ramps up to
    full payloads, etc. Guesswork here - get the packets and see.

    /dmfh

    --
    _ __ _
    __| |_ __ / _| |_ 01100100 01101101
    / _` | ' \| _| ' \ 01100110 01101000
    \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx


+ Reply to Thread