lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 22 Oct 2007 09:59:32 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Michael Whyte <m.whyte@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: CC2420 (802.15.4) Speed Issue

Michael Whyte wrote:
> Hi Guys,
> 
> I'm currently writing my first bit of Linux kernel code so be gentle.
> It's a driver for TI CC2420 802.15.4 radio and I'm observing strange
> behavior. I am currently testing just by transferring a ~300kb file
> over HTTP between two of these devices.

Into which revision of the kernel are you inserting your driver?

> The strange thing is, when ever you start the transfer it starts
> humming along at 5k/s which is not far off what I'd expect these
> devices to achieve, then at some random point along the transfer or
> sometimes not at all... it suddenly drops fairly deterministically to
> 150byte/s and finishes the transfer at that speed, maybe rising to
> 170bytes/s by the end of the transfer is I'm lucky.
> 
> I don't really know where to start looking to solve the problem, it
> seems everything is functioning as it should at least some of the time
> as in some cases it will complete the whole transfer at the 5k/s
> speed. Is it just tcp throttling very harshly (i.e. 50x) when it loses
> a packet?

See below re packet traces and stats.

> Is it the Xscale chip scaling down the CPU frequency
> mid-transfer, I've got no idea how to check this? 

Knowing nothing about Xscale I'd wonder if there wasn't a regsiter on it 
somewhere you could query for its current CPU frequency.  Otherwise, if the CPU 
is slowing down, presumably that should show-up as a change in power consumption 
for the whole device which  you could in theory measure with a power meter.

> It is some sort of
> resonance affect happening with the two radios CCA although I'm not
> seeing any CCA timeouts.
> 
> Can any one give any hints what to play with or where to look to try
> find the cause and get the transfers to run reliabily without the
> sudden bottoming out of speeds? (if you stop the transfer and initiate
> a new one immediately it will start at full speed again)

Might also check the netstat statistics for TCP - netstat -s -t.  You might find 
that at the point where the performance drops there was a non-trivial packet 
loss event taking the congestion window down.  Should show-up in a packet trace 
as well.

If you want to eliminate any possibility of http server issues (as close to 
epsilon as they probably are) you could use a netperf TCP_CRR test:

netperf -H <server> -t TCP_CRR -l <time> -- -r 256,300K

You could also add some -s and -S options to the end of that to constrain the 
TCP windows which might be an interesting experiment.

rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ