silo overflows -- what can I do about this?

[Matthew Dillon]

:
:Joseph Garcia wrote:
: > It connects and I can log in and enter commands. The problem pops up 
: > when receiving a lot of data quickly from the device (i.e. when I'm 
: > writing the configuration to the terminal).
:
:Maybe I'm completely missing the point here, but your
:description sounds like it could be a problem with
:flow control or handshaking.  Dit you try to enable
:it on your serial port?  stty(1) has several options
:for that (note that you must apply them to the lock-
:state device or initial-state device, otherwise they
:might be reset on the next open of the actual device;
:see sio(4) for details).
:
:Just an idea.  Sorry if the problem is somewhere else.
:
:Best regards
:   Oliver

    Probably wouldn't be a good idea to program a cisco to use
    hardware flow control on the console port.  I have a cisco
    too and telnet is basically the way to go.  You just set up the
    firewall rules to only allow connections from a single internal host.

    Cisco's can also talk TFTP.  So, e.g. with my little cisco

    ! copy tftp://blah.blah.blah.blah/some/path/filename running-config
    !
    ! Primary incoming filter for T1
    [ config commands ]

    And I just cut-and-pate the copy line into the cisco and it pulls the
    config via TFTP.

    --

    The 16550A can't do hardware flow control (CTS/RTS based flow
    control) in hardware, it's actually done by the interrupt handler
    in the driver.  Well, that is, the 16550A *has* a hardware flow
    control mode, but it was implemented incorrectly 25 years ago
    and it has never been fixed, ever.  Nobody uses it because of that.

    Serial ports are being used less and less.  I use a modem
    only very occassionally these days.  I haven't had any problem 
    running PPP over the modem at 19200 but I know for a fact that there
    *ARE* interrupt latency issues in DragonFly that have not been
    addressed that could well be responsible for lost characters on a
    tty.  While I want to fix the latency issues, it's near dead last
    on my list of important things to do.  

    I someone else wants to investigate the latency issues DragonFly does
    have a utility called pctrack (man pctrack) which works with kernels
    compiled with DEBUG_PCTRACK.  This utility is a very low level utility
    and would be difficult to use by a non-programmer, and even then it
    would be difficult to use.  It tries to record the PC as of when
    a statistics clock interrupt occurs.  The idea is that areas of
    code which entail very long interrupt latencies will record the PC
    as of the crit_exit() that finally allowed interrupts to be processed
    again.  Unfortunately it doesn't work as well as I would like and
    more often then not the PC's recorded are not useful in helping track
    down latency issues.

					-Matt