From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <896eab203042b2e267eb2b12d585a553@hamnavoe.com> To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Sat, 29 Sep 2012 19:01:42 +0100 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] usbether Topicbox-Message-UUID: bbfc06f2-ead7-11e9-9d60-3106f5b1d025 > why doesn't the device do the buffering? By "device" do you mean the hardware usb/ether adapter? It does some buffering - you can configure it to "burst" as many ether input packets as will fit in N 512-byte usb packets, in each usb input operation. I've got N=37 because that's what the linux driver does; of course there's no documentation to explain what the allowed range is or what the consequences of varying it would be. As far as I can see there's no "overrun" flag for the device to tell me I've missed reading some packets. > or is the problem > that usb/ether essentially an event loop of > and any delays in that pipeline accumulate? Almost: it's a pipeline of one thread reading a buffer full of packets, splitting it up, and sending a packet at a time to a second thread, which writes them to the kernel packet ethernet interface, which stores them in a Buf queue.