CC2420 (802.15.4) Speed Issue

CC2420 (802.15.4) Speed Issue

[Michael Whyte]

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.

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? Is it the Xscale chip scaling down the CPU frequency
mid-transfer, I've got no idea how to check this? 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)

Thanks,
-YT

Re: CC2420 (802.15.4) Speed Issue

[Rick Jones]

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