> 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 <read packet> <write packet> > 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.
