immediately writing serial port buffers - Unix

This is a discussion on immediately writing serial port buffers - Unix ; How do you cause the contents of the serial buffers held by the drivers to be immediately written to the wires? Using FTDI USB serial ports, we're having some problems with latency on output. If we write() a short packet, ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: immediately writing serial port buffers

  1. immediately writing serial port buffers

    How do you cause the contents of the serial buffers held by the
    drivers to be immediately written to the wires?

    Using FTDI USB serial ports, we're having some problems with latency
    on output. If we write() a short packet, the bytes are not output to
    the wires until either some time has elapsed or quite a few more bytes
    are written. We want to write() the short packet and have the bytes
    written to the wires immediately. (For some given value of
    immediately, naturally! Anything less than 5 milliseconds would do
    nicely.)

    Would tcdrain() help, or does this function just wait till the driver
    chain has got round to sending the data?

    In case this is implementation specific, it's a Linux 2.4 system
    running on an Intel CPU.






  2. Re: immediately writing serial port buffers

    Hi

    On Mon, 27 Oct 2008 16:50:40 -0700, stengist wrote:

    > How do you cause the contents of the serial buffers held by the drivers
    > to be immediately written to the wires?


    > Would tcdrain() help


    I think that you have answered your own question, but here's another one
    for you: what happened when you tried it?

    > or does this function just wait till the driver chain has got round to
    > sending the data?


    What does "man tcdrain" say on your system? Mine says:

    "tcdrain() waits until all output written to the object referred to by fd
    has been transmitted."

    viza

  3. Re: immediately writing serial port buffers

    On 28 Oct, 00:51, viza
    wrote:
    > > Would tcdrain() help

    >
    > I think that you have answered your own question, but here's another one
    > for you: what happened when you tried it?


    I haven't tried it today because someone else was using the scope. I'

    > > or does this function just wait till the driver chain has got round to
    > > sending the data?

    >
    > What does "man tcdrain" say on your system? *Mine says:
    >
    > "tcdrain() waits until all output written to the object referred to by fd
    > has been transmitted."


    Yes, I've seen that. The trouble is that the behaviour described isn't
    precisely what I want. I don't just want to passively wait till the
    various latency timers expire and the drivers finally get round to
    emptying their partly filled buffers. I want to actively tell the
    drivers to send whatever they've got, without waiting for the latency
    timers.

    The low latency setting helps a bit. From man setserial:

    low_latency
    Minimize the receive latency of the serial device at the cost of
    greater CPU utilization. (Normally there is an average of 5-10ms
    latency before characters are handed off to the line discipline to
    minimize overhead.) This is off by default, but certain real-time
    applications may find this useful.

    We've been setting this via the ASYNC_LOW_LATENCY ioctl.

  4. Re: immediately writing serial port buffers

    On Tue, 28 Oct 2008 14:42:37 -0700, stengist wrote:

    > On 28 Oct, 00:51, viza wrote:


    >> What does "man tcdrain" say on your system? *Mine says:
    >>
    >> "tcdrain() waits until all output written to the object referred to by
    >> fd has been transmitted."

    >
    > Yes, I've seen that. The trouble is that the behaviour described isn't
    > precisely what I want. I don't just want to passively wait till the
    > various latency timers expire and the drivers finally get round to
    > emptying their partly filled buffers. I want to actively tell the
    > drivers to send whatever they've got, without waiting for the latency
    > timers.


    Sorry, in my sarcasm I overlooked that subtlety.

    Going in a different direction: try running on a system without X or any
    other big services running. If it gets faster then you are probably
    waiting because of the kernel scheduler, in which case increasing the
    process priority or scheduling policy may help.

    HTH

+ Reply to Thread