> 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
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
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
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
> > > >
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
evaluate the
the
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
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.
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
> 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
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
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
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
On 2014-02-21, Peter Hurley pe...@hurleysoftware.com 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
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
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
> 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;
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
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
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
On 2014-02-20, Peter Hurley pe...@hurleysoftware.com 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
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-digit
On 02/20/2014 02:33 PM, Grant Edwards wrote:
On 2014-02-20, Peter Hurley pe...@hurleysoftware.com 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
On 2014-02-20, Hal Murray murray+fed...@ip-64-139-1-69.sjc.megapath.net 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
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
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
> 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
> 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
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
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
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
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-232 and
Hi Grant,
On 02/19/2014 11:55 AM, Grant Edwards wrote:
On 2014-02-19, Stanislaw Gruszka sgrus...@redhat.com 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
On 2014-02-19, Peter Hurley pe...@hurleysoftware.com 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
On 02/19/2014 01:12 PM, Grant Edwards wrote:
On 2014-02-19, Peter Hurley pe...@hurleysoftware.com 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
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 want
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
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 to
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
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 change
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
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 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
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
> 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
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
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
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 feature
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
54 matches
Mail list logo
