<div dir="ltr">My mistake. I didn't read the thread well enough. High latency is the problem I've experienced most with USB serial devices. This is different.<div><br></div><div>You're right Dan. One could try /increasing/ the latency to increase buffering, but I think that will just send larger chunks. It will likely increase the overall throughput, if anything, not decrease it. If the radio just isn't keeping up with the throughput in general this won't help.</div><div><br></div><div>I do like your idea of creating a throttled serial driver so long as users can still opt out of it. Maybe they could even tune the throttling with a parameter? This might help some HW without strewing sleep() calls all over the place. I want the max speed I can use, though. It takes too long to read/write some radios as it is. Don't throttle everyone.</div><div><br></div><div>Throttling baudrate completely might be a bad idea in some cases. What if a radio needs a relatively high amount of time to "digest" a packet/block/line of information? Maybe it reads an entire block, and then commits it to EEPROM, for example. Or maybe it decrypts the block (slowly). If the time needed to process a block is high compared to the time between symbols, you wouldn't want to impose the block timeout on each symbol, or the throughput would be much lower than needed; maybe painfully so.</div><div><br></div><div>My experience is most embedded devices don't use XON/XOFF. Even the simplest microcontrollers can usually keep up with 9600 baud until they try to do something like decryption or writing to EEPROM. Maybe I'm wrong here - I've never written firmware for a radio.</div><div><br></div><div>-Nathan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 16, 2017 at 2:30 PM, Dan Smith via chirp_devel <span dir="ltr"><<a href="mailto:chirp_devel@intrepid.danplanet.com" target="_blank">chirp_devel@intrepid.danplanet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> The other thing to try is setting the latency of your USB serial adapter<br>
> in the driver advanced tab. I have car tuning gear that requires this.<br>
><br>
> By default the latency setting is a bit high for a lot of USB serial<br>
> dongles. It increases efficiency at the cost of reduced speed. Akin to<br>
> the Nagle algorithm in networking maybe?<br>
<br>
</span>You mean turn _up_ the latency to slow things down a bit? If so, then<br>
that's worth a try.<br>
<br>
IMHO, this really smells like a flow control problem. Either the radios<br>
are expecting XON/XOFF and we're not doing it, or some of the<br>
chips/drivers are not signaling to the line discipline that their UART<br>
buffer is full and thus they're getting overwritten. The latter is more<br>
likely given that 9600 baud is really slow and most of the radios should<br>
be able to ingest that stream without needing us to slow down.<br>
<br>
If this is really a pervasive problem with drivers or USB devices,<br>
perhaps we should just write a generic throttled serial class, and let<br>
people opt-in to using that with a given flow rate. It'd be interesting<br>
to know if writing 8/16 bytes at a time, and timing it for 10% higher<br>
than the time it should take to flush that at the current baudrate helps<br>
all of these problems universally.<br>
<div class="HOEnZb"><div class="h5"><br>
--Dan<br>
______________________________<wbr>_________________<br>
chirp_devel mailing list<br>
<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.<wbr>danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" rel="noreferrer" target="_blank">http://intrepid.danplanet.com/<wbr>mailman/listinfo/chirp_devel</a><br>
Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" rel="noreferrer" target="_blank">http://chirp.danplanet.com/<wbr>projects/chirp/wiki/Developers</a><br>
</div></div></blockquote></div><br></div>