On Sat, Apr 25, 2015 at 06:09:16PM -0400, Cody P Schafer wrote: > > This assumes I'm using something that is normal serial hardware. > > Many devices that present as serial ports aren't really serial ports. > USB devices are especially prone to this. > Further, even if a real serial port is on the other end, nothing > guarantees that device isn't implementing it's own version of waiting > that I have no control over. > > As a result, the buffer will often contain more than 1 byte.
That's true, but if your VMIN=1 code is going to read a byte at a time whenever it's plugged into a "real" serial port, then I don't see why it's an approach we should be encouraging, if the motivation is efficiency. What are you actually trying to optimise for? Rather than efficiency, you seem to be focused on minimising latency: getting bytes as soon as they are available. That's fundamentally mutually exclusive with maximising efficiency. You say you don't want any timeouts, but think about *why* you get multiple bytes at a time with a USB serial adapter. It's because there's a timeout in effect. The driver only polls the USB device every N milliseconds, so whenever it does so you get all the bytes that arrived wihin that time. On FTDI devices for example, the default latency timer value is 16ms. You seem happy with this arbitrary timeout giving you a gain on efficiency, by getting you multiple bytes on each read. But you don't want to improve efficiency any further by setting what timeout you're actually willing to tolerate. If you really want to minimise latency, you should either avoid using a USB adapter entirely, or tune the latency timer down to the minimum in the USB device driver settings. Either way, you should then be getting only a single byte per loop cycle, so there's no advantage to using anything other than a single-byte read call. If you're not already getting at most byte per loop cycle, then extra syscall overhead in reading each one is not your problem. If you really want to maximise efficiency, then you need to avoid making the OS return every byte as soon as it's available. Make large read requests with a big buffer and a long timeout, and let the OS get on with things. If you want a balance somewhere in between, then use sp_blocking_read() with a short timeout that you're willing to tolerate. And you'll then also get consistent behaviour regardless of what serial device you use, rather than depending on the device happening to have a suitable timeout. > I'm not currently seeking any behavior other than VMIN=1. While I > could see other values being convenient for protocol implementations, > as you mention portability for that would be tricky (or deeper than > adjusting port flags, one would have to actually compose a single > lib operation on some platforms into more than 1 system call). Note that some library calls already involve more than one system call. For one thing, sp_blocking_read() on Unix platforms works by running select() for the block and then read() to get the data. This is necessary because the port has to be opened in O_NONBLOCK mode to be able to support nonblocking operations as well. This also means that if we add a function for the behaviour you want, it would still be doing a wait followed by a nonblocking read internally. > The VMIN=1 case, on the other hand seems like it'd be rather possible. I agree that it's possible to add a function that provides these semantics. I don't currently see a good reason to. It would be exactly equivalent to sp_wait() for RX followed by sp_nonblocking_read(). Your goal seems to be to minimise latency. But if you're getting more than one byte received per loop cycle, then the time cost of making multiple syscalls to read them will be absolutely negligible compared to the latency you're already getting through the rest of the system. So I don't see the point in trying to optimise the code for this scenario. Martin ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
