On Sat, Jul 04, 2009 at 09:33:51AM +0200, thus spake Benoit PAPILLAULT:
quoted text
> I already noticed this kind of behavior when using iperf over
> Ethernet. Let's say you are trying to send a UDP stream at 200 Mbit/s
> over a 100 Mbit/s ethernet interface. If no cable are connected, iperf
> will happily reports 200 Mbit/s being sent, which means that the
> kernel just drops everything! If an Ethernet cable is connected,
> somehow, the kernel (I'm not sure it's the driver itself) is limiting
> iperf to say 95 Mbit/s. I think the latter is strange in fact, not the
> former. So if there is many gaps in the iperf sequence numbers, it
> means that either the linux kernel or the madwifi driver is dropping
> packets. For me, it's pretty clear that it's the kernel dropping
> packet as expected.

Okay, I agree with that.  But first, in the case of my measurements, we can
say that the kernel should consider the "cable" as plugged, since the
destination MAC address *is* reachable.  And second, how come changing the
debug flags (athdebug +xmit) changes anything at all in the way the kernel
would consider the "cable" as plugged or not?

I would like to understand what kind of side-effects are caused by the
activation of the debug flag.  Note that it seems only the xmit flag causes
this change, though I have tried only a few others (namely tsf and xmit_proc).

-- 
To err is human, to purr feline.

------------------------------------------------------------------------------
_______________________________________________
Madwifi-devel mailing list
Madwifi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/madwifi-devel