extremely high latency channel - Protocols

This is a discussion on extremely high latency channel - Protocols ; I am communicating with a remote system (a buoy) using MaxStream 900MHz radios. Due to various circumstances, the latency on the line is very high, up to 30 seconds sometimes. Often I'll press return at the unix or Kermit prompt ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: extremely high latency channel

  1. extremely high latency channel

    I am communicating with a remote system (a buoy) using MaxStream 900MHz
    radios. Due to various circumstances, the latency on the line is very
    high, up to 30 seconds sometimes. Often I'll press return at the unix
    or Kermit prompt several times, and 20-30 seconds later the several
    prompts will appear. Same thing with echoes of typing.

    However, due to the error checking of the radios, the line is rather
    reliable. Occasionally some data gets lost, but most of the time it
    all gets through.

    Also, if you try to send something while the other side is trying to
    send, it causes extra delays, and that is where data is lost most of
    the time.

    Our major problem is trying to tweak the Kermit protocol to deal with
    this. Ultimately, if the system could send a packet, PATIENTLY wait
    for an acknowledgement without trying to send anything (and only after
    a minute or so attempt a retry), it would probably work OK.

    As it is, we get extremely dismal throughput, even on ROBUST setting,
    because it seems I can't get Kermit to wait patiently enough for a
    response. I've tried to set the send and receive timeouts to high
    values (like 60) but I keep seeing messages about timeouts of 15
    seconds or less during the transfer attempts.

    We've gotten much better results simply using "cat" to display the
    files and using session logging to capture the text. But I should
    think that a protocol as versatile as Kermit could do better than
    "cat". I've even tossed around the idea of tacking checksums to the
    end of the files and doing my own error checking in script. But that
    seems so silly because the Kermit protocol should be able to handle
    this.

    Does anyone have any hints here? What's particularly frustrating is
    that the interactive command prompt experience over this link isn't all
    that bad, it just usually takes a few seconds for things to echo.

    Thanks for any tips.


  2. Re: extremely high latency channel

    As a followup, I have found that using Zmodem protocol over the link
    works slowly but reliably when timeouts are disabled using the -O
    parameter.

    I would still much rather use the Kermit protocol, but every attempt I
    have made to adjust the parameters of the protocol (I'm transferring
    C-Kermit to C-Kermit here) result in indefinite delays or unbelievably
    slow performance (would you believe 2 CPS -- that's TWO (period) CPS,
    while Zmodem at least broke the 20CPS barrier and averaged about 21
    CPS, which is acceptable. But again, I'd rather use the Kermit
    protocol and its nice features like "set send move-to" and countless
    other advantages.


  3. Re: extremely high latency channel

    Have you had a look at the articles on "Experience with K95 over
    satellite links" in comp.protocols.kermit.misc around march 14, 2002?
    ()?

    It seems that these articles can provide a hint on to make it work.



    On 10 Aug 2006 23:24:09 -0700, tomviolin wrote:
    > As a followup, I have found that using Zmodem protocol over the link
    > works slowly but reliably when timeouts are disabled using the -O
    > parameter.
    >
    > I would still much rather use the Kermit protocol, but every attempt I
    > have made to adjust the parameters of the protocol (I'm transferring
    > C-Kermit to C-Kermit here) result in indefinite delays or unbelievably
    > slow performance (would you believe 2 CPS -- that's TWO (period) CPS,
    > while Zmodem at least broke the 20CPS barrier and averaged about 21
    > CPS, which is acceptable. But again, I'd rather use the Kermit
    > protocol and its nice features like "set send move-to" and countless
    > other advantages.
    >


  4. Re: extremely high latency channel

    On 2006-08-11, tomviolin wrote:
    : As a followup, I have found that using Zmodem protocol over the link
    : works slowly but reliably when timeouts are disabled using the -O
    : parameter.
    :
    Sorry for the delay in getting to this; I have to go out of my way to
    check netnews these days.

    Zmodem is a streaming protocol. You can make C-Kermit stream too if you
    want to try it. This technique is appropriate for error-free connections
    such as over TCP/IP networks, but it can also work when you have an
    error-free serial connection, such as you should have when using
    error-correcting modems and hardward flow control. See:

    http://www.columbia.edu/kermit/ckermit70.html#x4.20

    See especially section 4.20.2.4, "Streaming on Dialup Connections".

    Of course both Kermit partners must support streaming. For example,
    C-Kermit 7.0 or later and Kermit 95 1.1.19 or later.

    The problem with streaming is that it's all-or-nothing. Any error will
    stop the transfer dead. Of course you can always keep partial files
    and use the RESEND/REGET feature to continue from that point.

    : I would still much rather use the Kermit protocol, but every attempt I
    : have made to adjust the parameters of the protocol (I'm transferring
    : C-Kermit to C-Kermit here) result in indefinite delays or unbelievably
    : slow performance (would you believe 2 CPS -- that's TWO (period) CPS,
    : while Zmodem at least broke the 20CPS barrier and averaged about 21
    : CPS, which is acceptable. But again, I'd rather use the Kermit
    : protocol and its nice features like "set send move-to" and countless
    : other advantages.
    :
    Thanks :-)

    For the past 10 years or so, timeouts have been "dynamic" -- calculated on
    the fly based on the behavior of the connection. That's why your SET SEND
    and SET RECEIVE timeout commands seemed to have no effect. Here's the
    text from "help set send":

    SET SEND TIMEOUT number [ { DYNAMIC [ min max ] ], FIXED } ]
    Number of seconds to wait for a packet before sending NAK or
    retransmitting. Include the word DYNAMIC after the number in the
    SET SEND TIMEOUT command to have Kermit compute the timeouts dynamically
    throughout the transfer based on the packet rate. Include the word FIXED
    to use the "number" given throughout the transfer. DYNAMIC is the
    default. After DYNAMIC you may include minimum and maximum values.

    It should also say, a negative timeout value means "don't time out,
    wait forever":

    SET SEND TIMEOUT -1 FIXED

    Does this help?

    - Frank

+ Reply to Thread