From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E4D1720069D for ; Wed, 14 Mar 2012 11:13:51 -0700 (PDT) Received: by eaal11 with SMTP id l11so1850560eaa.16 for ; Wed, 14 Mar 2012 11:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uCyABHeI5Bz9NtNJvRhSidRfgXi5I32zUErhrFMCp/E=; b=yDeoU2g6XuYNJziZef0jvko21B5LYvp5CAT/XNadD5y7E8TRwFUav/q23poZoL0VAp FV1BXG5x3+iCVhgBO0P0NpZPmnZ4ARyMwt7COBx0LgWFo0u66IhpbLfjfrw5dVxbWCFc vkIeXUsUWcD0oEa3R2YPO1pSiALnMrhXtEMQJ7jibr1br4RYlGPxKFiGsM3whTgYHCn1 N8WwPjViaTsRpMkD5ccKkVN0SIbHkXZrlT3HxszT7O7bVtwRKaPh2BCIdHUB0SFv/FWp Kgn2qbkT4s7XJUQVIDyNUv3l0lem12Wt7C5OSVzGZId3lBMrX/cjS+WLl07rKeX/RNPX T4aw== MIME-Version: 1.0 Received: by 10.52.36.226 with SMTP id t2mr2605531vdj.52.1331748829470; Wed, 14 Mar 2012 11:13:49 -0700 (PDT) Received: by 10.220.140.132 with HTTP; Wed, 14 Mar 2012 11:13:49 -0700 (PDT) In-Reply-To: <20120314104920.697EA40617@snark.thyrsus.com> References: <20120314104920.697EA40617@snark.thyrsus.com> Date: Wed, 14 Mar 2012 13:13:49 -0500 Message-ID: From: Patrick Maupin To: "Eric S. Raymond" Content-Type: text/plain; charset=ISO-8859-1 Cc: thumbgps-devel@lists.bufferbloat.net Subject: Re: [Thumbgps-devel] USB handshake signals and Linux X-BeenThere: thumbgps-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 18:13:52 -0000 On Wed, Mar 14, 2012 at 5:49 AM, Eric S. Raymond wrote: > Since the Plane Jane design concept depends on the host system being > able to see USB events corresponding to serial handshaking state > changes, I went looking for information on which handshake signals > from which serial-to-USB adapters actually propagate these signals > through. I focused on Linux becase that's the kernel for the > bufferbloat deployment. There is another question, which is about the internal latency inside the USB adapter. In general (e.g. for character data) the USB adapters will deliberately add some latency so as to make better use of internal buffering resources. (Once an adapter sends a packet of characters up to the host, it has to wait for an ACK before it can reuse that buffer -- it might need to resend for a NAK.) So if the host polls with an interrupt packet, and there is data at the USB device but it reasonably expects that more data is coming, it might not send the packet up right away. The FTDI devices have a latency timer that allows you to control this somewhat. But even better, if we're going to use the PPS signal, they essentially guarantee that they will send ASAP on modem control signal change. We might need to characterize "ASAP" but I would hope that it doesn't vary too much. I know nothing about the Prolific device; you might look for what they have to say about latency.