Hi Alex, No problems testing your new branch, just send me the URL, branch name and can you also send me the commit hash as open embedded uses this.
One thing I've noticed with this problem I'm seeing is that I can make it happen a lot quicker by making a SSH connection to one of the boards over the ethernet port. Which is weird as this connection is IPv4, so there must be some sort of interaction going on between ethernet/6lowpan or IPv4/IPv6. Anyway I'll do some more testing when the new branch is ready. Cheers, Martin. On 05/02/14 10:35, Alexander Aring wrote: > Hi Martin, > > On Wed, Feb 05, 2014 at 10:08:03AM +0000, Martin Townsend wrote: >> Hi Alex, >> >> I have been testing your 6lowpan_pending branch with the fragmentation >> updates (commit 5e47d2f516a6cf1acf9927125392484835d93552 - I don't think >> this has the spin_lock patch below) using 2 devices pinging each other, > I thought I fix a little bit in the net branch which used the old > fragmentation api. But David Miller said it already the synchornization > of the fragmentation is a mess, so I decide to reimplement the > fragmentation api of 6lowpan. > > That means you don't need this patch, I removed everything from the > current fragmentation api and replace it. > >> one with 1000 byte ping and the other with a 777 byte ping and the good >> news it was working fine for about 3/4 hour. The bad news is that it >> gets to a point where something happens and then only sporadic pings are >> getting through on one device and the other I've seen one ping get >> through in about 10 minutes. Could this be a symptom of what your >> describing here or would it completely freeze? If I stop the pings and >> set them both off again withdefault packet sizes it works fine again. >> As soon as I try to using a larger ping payload it becomes sporadic again. >> > I guess it's because the fragmentation queue and the memory managment. > The new fragmentation have a garbage collector and some other things but > it has basically a maximum memory size and if you reach this memory > size... I don't know what happens then there. Maybe you experience this > issue yet. > > The good news! You can change some parameters for the garbage collector > and we should use some "good defaults" for 6lowpan. The bad news, you > can't change these parameters at runtime (oh yea, ipv6 can do this but I > dropped it... I will add the necessary sysfs entries there). Maybe you > want to try it out now, then search for > > IPV6_FRAG_HIGH_THRESH > IPV6_FRAG_LOW_THRESH > > in net/ieee802154/reassembly.c. This are the default values for ipv6. > Currently I don't have any time to think about some default values for > 6lowpan. Maybe you can help me there! > > > It works after you stopped it because the garbage collector runs and > drops many things out of the fragmentation queue. (I think). > >> I'll try and get some sort of tracing working to see if this shows >> anything. If you have a branch with the inet_frag api changes I don't >> mind trying them out too. >> > Give me some time, then I will create a new branch on current net-next > with the necessary sysfs entries and will cleanup the code. > > Then I need you! If you have tested these patches for new fragmentation, > then I can add a Tested-by <martin....> to these patches, so it's easier > to get this patches mainline. That's a really big help :-) > > - Alex ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
