Per Jessen wrote:

Achim Gratz wrote:

...

I am using a GPS as a reference clock for NTP. It's currently attached via a USB serial adapter, but the PPS timing precision is limited by the USB interrupt handling. I want to see if things get better by attaching it to the (only) RS232 port, but AFAIK that is used (optionally? I think) for a serial console during boot. The running system doesn't seem to use the serial, at least I can find no getty process attached to it. So, do I need to do anything to disable the serial console and if so, waht exactly?

I thought you had to enable a serial console explicitly by adding "console=ttyS0,baud,8n1" as linuxrc arguments. Whether that is different in TW, I don't know.

Yes, my remembering, too, you have to explicitely enable it. On my previous laptop, which still had a real serial, I also just used it for 'normal' applications. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Brüns writes:

Is the PPS signal wired to one of the handshake lines? Depending on the converter, the line status registers may be signaled using interrupt transfers, are "streamed" using bulk transfers, or have to be polled.

The PPS signal for a real RS232 has to come in on DCD, so I re-routed that line on the converter board I use (the serial driver for the BSD kernels can be told to use CTS instead of DCD). There is a patched serial driver around that also uses CTS (this is much more commonly available on converter boards than DCD).

Prolific (pl2303) and CH34X support interrupt transfers for line status signaling, while Silabs CP210x and FTDI apparently do not.

I haven't had much luck with one particular PL2303 board, but then it didn't claim to support anything beyond just TX/RX. The FTDI board that breaks out all signals works just fine and has pretty good timing overall.

If the converter uses interrupt transfers, the polling rate (all USB "interrupts" are message-signalled, i.e. happen at the protocol level, not on the physical layer) varies. The latency is at least/typically one frame (1ms for Low/Full Speed).

Yes. So far the best I've tried was the FTDI, which had jitter down in the ±30µs range. I was hoping with a hardware serial I might get another order of magnitude better, but apparently not.

FTDI puts the status in the header of the normal data transfer. As the Bulk IN enpoint is continously polled for available data (~33us) it should be able to signal changes in the line status with at most 33us latency.

I think I see about 5…10µs less latency on the serial vs. USB, which seems about right from your explanation. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org