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 gpsd. They run on almost any hardware
or OS and talk to a wide collection of devices.
There is no hard requirement for latency. They just work better with lower
latency. The lower the better.
People gripe about the latency due to USB polling which is about a ms.
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.
I can easily notice a few 10s of microseconds. I probably wouldn't notice a
few microseconds, but there are people who would. The latency isn't
critical, it's the jitter. (ntpd has fudge factors to correct for a fixed
offset.) Yes, down at the microsecond level luck-of-the-cache is important.
Hopefully you meant "milliseconds" here; single-digit microsecond latency on
any kind of stable duty cycle is linux-rt territory, and simply not a reasonable
goal for mainline.
The jitter is all scheduler and since the user-space app is sleeping waiting
for input, there's nothing the tty core can do about that. Removing one
mandatory scheduling wakeup _may_ help latency, but will probably not make
much difference regarding jitter.
Also, how painful would it be if unsupported termios changes were rejected
if the port was in low_latency mode and/or if low_latency setting was
disallowed because of termios state?
What does "unsupported termios changes" mean?
For example, once the port is in low_latency mode, setting L_ECHO (and its ilk)
would be rejected. And vice versa, if the L_ECHO is set in termios, low_latency
would be rejected.
So running a vt console is low_latency mode is not going to work.
ntpd has only a few places where it opens a serial port. I'll collect a list
of the options that are used if that will help. The common cases are either
raw binary, or lines of text. It doesn't need any fancy editing.
It would be pointless to throttle low_latency, yes?
What does "throttle" mean? If you mean what I call flow-control, then no,
it's not interesting.
Yes, whatever the driver currently considers flow-control. The core is
agnostic about the mechanism; throttling is the generic requirement.
There shouldn't be any problem with ntpd or gpsd grabbing all the data
promptly.
Ok.
What would be an acceptable outcome of being unable to accept input?
Corrupted overrun? Dropped i/o? Queued for later? Please explain with
comparison to the outcome of missed minimum latency.
Corruption would be evil. Longer latency would be OK, especially if it
didn't happen often. (ntpd has code to discard outliers.) 3% of the time
would probably not be a problem. 25% might cause problems.
We can allocate a bigger buffer if that helps.
No need, I already solved this step.
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.
What Alan said. low_latency has no impact on the handling of the PPS signal
through DCD.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
