> of course the 64bit question is, which queue is dropping packets.
> there are so many to choose from.
Looks my initial guess was wrong. I added some readahead to the kernel
usb driver and that didn't help at all. Then I reduced the device's
buffering ("burst factor"), and increased the interme
> After running out of 9pi-specific things to debug, it occurred to me
> to try a usb ethernet dongle on an x86 plan 9 machine. There I
> observed the same thing: so many dropped packets that the connection
> is unusable.
> So, has anyone had success using usbether to connect a plan 9 system
> to
> the qopen sets the queue limit to 8k
Which qopen are you referring to?
the qopen sets the queue limit to 8k, which seems a little low, unless it's
reset later.
the later unchecked qpass (with comment) will toss the data away, which is
a little drastic.
On 29 September 2012 22:46, Richard Miller <9f...@hamnavoe.com> wrote:
> It often gets about 8k at a time (a comple
On Sat Sep 29 17:47:18 EDT 2012, 9f...@hamnavoe.com wrote:
> > And is it really doing it? I mean it asks for many bytes but how many
> > does it get?
>
> It often gets about 8k at a time (a complete 9p message). I'll have
> to add a check to see what the maximum is.
of course the 64bit question
> And is it really doing it? I mean it asks for many bytes but how many
> does it get?
It often gets about 8k at a time (a complete 9p message). I'll have
to add a check to see what the maximum is.
On 29/09/2012, at 23:25, Richard Miller <9f...@hamnavoe.com> wrote:
That's the asix driver: the raspberry pi adapter has an SMSC LAN95xx,
see /n/sources/contrib/miller/usb/ether/smsc.c for my driver which
reads up to 37*512=18944 bytes at a time.
And is it really doing it? I mean it asks for ma
> Taking a cursory glance it looks as if it just reading at most one
> full packet at a time
> (the size of the buffer is 2000)
That's the asix driver: the raspberry pi adapter has an SMSC LAN95xx,
see /n/sources/contrib/miller/usb/ether/smsc.c for my driver which
reads up to 37*512=18944 bytes at
On Sat Sep 29 14:02:51 EDT 2012, 9f...@hamnavoe.com wrote:
> > why doesn't the device do the buffering?
>
> By "device" do you mean the hardware usb/ether adapter? It does some
i ment #u itself. sorry for being unclear. actually, echoing
gorka, i think there's going to need to be enough thread
On Sat, Sep 29, 2012 at 8:01 PM, Richard Miller <9f...@hamnavoe.com> wrote:
> 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
> 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 d
> I had a similar problem with serial a while ago. The problem was that
> it was taking too long doing too many system calls, doing big reads
> and buffering may help you?
why doesn't the device do the buffering? or is the problem
that usb/ether essentially an event loop of
and any delays in th
On Sat, Sep 29, 2012 at 6:16 PM, Richard Miller <9f...@hamnavoe.com> wrote:
> So, has anyone had success using usbether to connect a plan 9 system
> to the outside world? I am hoping someone can give me an encouraging
> report. I'm a bit worried that it's a fundamental problem with the
> plan 9 u
I've been struggling to get the raspberry pi's built-in usb ethernet
adapter working. I can send and receive packets reliably enough to
get a remote file system mounted, but with any kind of heavy use the
usbether input seems to be missing a lot of packets, and everything
gets horribly slow.
Afte
14 matches
Mail list logo
