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
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 complete
the qopen sets the queue limit to 8k
Which qopen are you referring to?
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
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 usb
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 read packet write packet
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
in
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
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 a
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
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 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 is,
12 matches
Mail list logo
