> This is a complete pointless test. Use a bog standard 8250 UART on the
> PC and connect a microcontroller on the other end which serves you an
> continous stream of data at 115200 Baud.
>
> There is no way you can keep up with that without the low latency
> option neither on old and nor on new m
Hi Thomas,
On 02/23/2014 05:33 PM, Thomas Gleixner wrote:
On Thu, 20 Feb 2014, Peter Hurley wrote:
On 02/19/2014 09:55 PM, Peter Hurley wrote:
On 02/19/2014 06:06 PM, Hal Murray wrote:
Can you give me an idea of your device's average and minimum required
latency (please be specific)? Is you
On Thu, 20 Feb 2014, Peter Hurley wrote:
> On 02/19/2014 09:55 PM, Peter Hurley wrote:
> > On 02/19/2014 06:06 PM, Hal Murray wrote:
> > > > Can you give me an idea of your device's average and minimum required
> > > > latency (please be specific)? Is your target arch x86 [so I can
> > > > evalua
On 2014-02-21, Peter Hurley wrote:
> I think the consensus is to leave the low_latency facility in, but
> remove it's connection to the tty buffers.
>
> If the known-to-be-already-in-non-interrupt-context drivers want,
> I can add a different function for executing flush_to_ldisc()
> directly. Bu
Hi Alan,
On 02/21/2014 10:39 AM, One Thousand Gnomes wrote:
Ok, so this is still only about "best effort", and really bad
worst case behavior (that the tty core has no control over) is ok.
Going to great lengths to trim one wakeup when nouveau disables interrupts
for 2ms seemed like a waste of
> Back in the old days, when a serial driver pushed characters up to the
> tty layer it didn't immediately wake up a process that was blocking on
> a read(). AFAICT, that didn't happen until the next system tick. I'm
> not sure if that was just because the scheduler wasn't called until a
> tick ha
> Ok, so this is still only about "best effort", and really bad
> worst case behavior (that the tty core has no control over) is ok.
>
> Going to great lengths to trim one wakeup when nouveau disables interrupts
> for 2ms seemed like a waste of time.
If it used to work and it doesn't now it's a r
On 2014-02-20, Hal Murray wrote:
> Let's go back to the big picture. In the old old days, time sharing
> systems had lots of serial ports. It was common for the hardware to
> buffer up several characters before requesting an interrupt in order
> to reduce the CPU load.
There were even serial b
On 02/20/2014 02:33 PM, Grant Edwards wrote:
On 2014-02-20, Peter Hurley wrote:
Sender completes 2000 loops in 160ms total run time;
that's 80us average per complete round-trip.
If I understand correctly, that 80us _includes_ the actual time for
the bits on the wire (which means the actual "b
> Have you tried 3.12+ without low_latency? I ripped out a lot of locks from
> 3.12+ so it's possible it already meets your requirements.
Looks good. I don't think I could tell the difference by looking at my
normal collection of graphs.
> Hopefully you meant "milliseconds" here; single-digi
On 2014-02-20, Peter Hurley wrote:
> On 02/19/2014 09:55 PM, Peter Hurley wrote:
>> On 02/19/2014 06:06 PM, Hal Murray wrote:
Can you give me an idea of your device's average and minimum required
latency (please be specific)? Is your target arch x86 [so I can evaluate
the
the
On 02/19/2014 09:55 PM, Peter Hurley wrote:
On 02/19/2014 06:06 PM, Hal Murray wrote:
Can you give me an idea of your device's average and minimum required
latency (please be specific)? Is your target arch x86 [so I can evaluate the
the impact of bus-locked instructions relative to your expecte
On Wed, Feb 19, 2014 at 09:55:21PM -0500, Peter Hurley wrote:
> On 02/19/2014 06:06 PM, Hal Murray wrote:
> >> Can you give me an idea of your device's average and minimum required
> >> latency (please be specific)? Is your target arch x86 [so I can evaluate
> >> the
> >> the impact of bus-locked
On 02/19/2014 06:06 PM, Hal Murray wrote:
Can you give me an idea of your device's average and minimum required
latency (please be specific)? Is your target arch x86 [so I can evaluate the
the impact of bus-locked instructions relative to your expected]?
The code I'm familiar with is ntpd and
On 02/19/2014 04:42 PM, One Thousand Gnomes wrote:
It only has to happen *once*, not every time to screw stuff up.
If the reader isn't pulling _all_ the data out the instant it's woken,
trying to trim off one worker wakeup (by processing input at interrupt time)
is pointless.
No - because of
> gpsd uses TIOCMIWAIT to get a wakeup from a PPS signal connected to a modem
> control line. That path might have the same problem and/or some ideas on how
> to handle the data case.
TIOCMIWAIT should be fine. The data processing is deferred but very few
devices defer processing of modem chang
> Can you give me an idea of your device's average and minimum required
> latency (please be specific)? Is your target arch x86 [so I can evaluate the
> the impact of bus-locked instructions relative to your expected]?
The code I'm familiar with is ntpd and gpsd. They run on almost any hardware
> > Because low latency is about *turn around* time. There are plenty of
> > protocols that can flow control, do flow control and want low latency
> > because they are not windowed. It's not mutually exclusive by any means.
>
> But if it's all about turn around time, how can the situation devolve
On 02/19/2014 02:17 PM, One Thousand Gnomes wrote:
How can the requirement be for both must-handle-in-minimum-time data
(low_latency) and the-userspace-reader-isn't-reading-fast-enough-
so-its-ok-to-halt-transmission ?
Because low latency is about *turn around* time. There are plenty of
protoco
> How can the requirement be for both must-handle-in-minimum-time data
> (low_latency) and the-userspace-reader-isn't-reading-fast-enough-
> so-its-ok-to-halt-transmission ?
Because low latency is about *turn around* time. There are plenty of
protocols that can flow control, do flow control and wa
On 02/19/2014 01:12 PM, Grant Edwards wrote:
On 2014-02-19, Peter Hurley wrote:
On 02/19/2014 11:55 AM, Grant Edwards wrote:
setserial has low_latency option which should minimize receive latency
(scheduler delay). AFAICT it is used if someone talk to external device
via RS-485/RS-232 and ne
On 2014-02-19, Peter Hurley wrote:
> On 02/19/2014 11:55 AM, Grant Edwards wrote:
> setserial has low_latency option which should minimize receive latency
> (scheduler delay). AFAICT it is used if someone talk to external device
> via RS-485/RS-232 and need to have quick requests and
Hi Grant,
On 02/19/2014 11:55 AM, Grant Edwards wrote:
On 2014-02-19, Stanislaw Gruszka wrote:
Hello,
On Tue, Feb 18, 2014 at 05:12:13PM -0500, Peter Hurley wrote:
On 02/18/2014 04:38 AM, Stanislaw Gruszka wrote:
setserial has low_latency option which should minimize receive latency
(sched
Hello,
On Tue, Feb 18, 2014 at 05:12:13PM -0500, Peter Hurley wrote:
> On 02/18/2014 04:38 AM, Stanislaw Gruszka wrote:
> >Hi,
> >
> >setserial has low_latency option which should minimize receive latency
> >(scheduler delay). AFAICT it is used if someone talk to external device
> >via RS-485/RS-2
Hi Stanislaw,
On 02/18/2014 04:38 AM, Stanislaw Gruszka wrote:
Hi,
setserial has low_latency option which should minimize receive latency
(scheduler delay). AFAICT it is used if someone talk to external device
via RS-485/RS-232 and need to have quick requests and responses . On
kernel this feat
> spin_lock's there. Maybe we can create WQ_HIGHPRI workqueue and schedule
> flush_to_ldisc() work there. Or perhaps users that need to low latency,
> should switch to thread irq and prioritize serial irq to meat
> retirements. Anyway setserial low_latency is now broken and all who use
> this featu
Hi,
setserial has low_latency option which should minimize receive latency
(scheduler delay). AFAICT it is used if someone talk to external device
via RS-485/RS-232 and need to have quick requests and responses . On
kernel this feature was implemented by direct tty processing from
interrupt contex
27 matches
Mail list logo
