search

dzianis97 / iwidarwin

Automatically exported from code.google.com/p/iwidarwin
0 stars 0 forks source link

tx performance. #7

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
i seem that tx performace is not good.
it is 3 time allocattion per 1 mbuf chains. 

this should be changed? 
this may be difficult issue .

Original issue reported on code.google.com by kazuh...@gmail.com on 29 Jan 2007 at 8:52

GoogleCodeExporter commented 9 years ago 
we should check the ieee80211_rx also. it seems that the rx packets are getting 
to
much errors

Original comment by jalav...@gmail.com on 30 Jan 2007 at 5:06

GoogleCodeExporter commented 9 years ago

Original comment by kazuh...@gmail.com on 12 Feb 2007 at 12:09

GoogleCodeExporter commented 9 years ago 
i think ipw_tx_skb, ieee80211_xmit are the reason of kernel panic related with 
rx performance

i'll check them

Original comment by jalav...@gmail.com on 20 Feb 2007 at 7:51

GoogleCodeExporter commented 9 years ago 
we should research   argument of setCapacity  and locking at first.

from apple doccument about setCapacity:
> Changes the number of packets that the queue can hold before it begins to drop
excess packets.
  this argument is not packet size  but number of tx packet which IOOutputQueue can
hold .
  we should research good value for setCapacity using perfomance benckmark ( examply 
  netperf).
locking is related with setCapacity
  outputPacket must be thread safe. this meaning is that outputPakcet is working
peritialy. 
  I seem that mutex lock or spin lock is required. 
  locking or mutext nerver occer kernel panic( if it is dead lock, kernel panic dont
happen) 

performance tools:
  we dont use tiny self script but should use good perfomance tools.
  i think that netperf is good.
  do you have two machines. netperf can be sevaral tested.

  netperf is http://www.netperf.org/netperf/.

Original comment by kazuh...@gmail.com on 21 Feb 2007 at 10:11

GoogleCodeExporter commented 9 years ago 
try this in outputpacket()

IWI_LOG("t: %04x f:%04x\n",mbuf_type(m),mbuf_flags(m));

this shows we get different types and flags for packets.

should we treat the packets according to their type and flag values?

this could be the reason of kernel panics

Original comment by jalav...@gmail.com on 21 Feb 2007 at 4:45

GoogleCodeExporter commented 9 years ago 
jalavoui,

I think ...
if mbuf_type is MBUF_TYPE_FREE or mbuf_type is not MBUF_PKTHDR, 
kernel panic is caused by it.i dont know about other conditions.

and I found the conditions which kernel panic happen always.

[server 192.168.0.14] -------  [iwi2200 machine 192.168.0.12] 

server:
   % netserver

iwi2200 machine:
   % netperf -H 192.168.0.14 -t UDP_STREAM -- -s 1024

attached file is binary of netperf and netserver( osx in x86)

Original comment by kazuh...@gmail.com on 21 Feb 2007 at 5:58

Attachments:

GoogleCodeExporter commented 9 years ago 
fixed

Original comment by kazuh...@gmail.com on 22 Feb 2007 at 6:56