Re: [tipc-discussion] kernel page allocation problem
On Friday 01 April 2016 15:02:05 Jon Maloy wrote:
> > I saw that the problem is in the lack of memory.
> > I also made a simple stress test (one side sends in a loop) and received
> > this problem immediately.
> > But User's Manual states that if there is no room for the receiving side
> > to accept message it prevents the sending side from sending, effectively
> > blocking the sender.
>
> That is true only for connection oriented messaging (SOC_STREAM,
> SOCK_SEQPACKET). Is that what you are running?
> If you are just doing a tight loop with 66k messages using TIPC_PORT_NAME
> you will not have any flow control, and the messages might be dropped in the
> receiving socket.
> But if you are really tight of memory they might also be dropped at the link
> layer, which is what you are seeing.
> I have never seen that happening before, but it is fully possible in TIPC
> versions before commit 40ba3cdf542a469aaa9 ("tipc: message reassembly using
> fragment chain") from Nov 6th 2013. (I don't remember which Linux version
> this corresponds to, but that should be easy to find out). Furthermore, this
> might even happen with connection oriented messaging, but is less likely.
>
> So, if you are running connectionless, I recommend you to go to a connection
oriented mode. If you already are connection oriented, you can try to find out
which version this fix was in, and re-adapt the code.
Thanks a lot, Jon, again.
After your answer I again looked through the both manuals and did not find
anything saying that connectionless messaging allows drops. Vice verse, the
programmer's manual explicitly states that "TIPC is designed to be a reliable
messaging mechanism, in which an application can send a message and assume
that the message will be delivered to the specified destination as long as
that destination is reachable."
Now, is it a bug, corrected in Nov 6th 2013? Or a feature?
i can't move to connection oriented methods, because I need to support one-
to-3 and 3-to-one.
Sorry.
--
Leon
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] kernel page allocation problem
On Wednesday 30 March 2016 14:40:58 Jon Maloy wrote: > Hi Leon, > I took a quick look at your dump, and to me it looks like you have simply run out of memory. I think that is the first thing you should look at. > As for the most recent code version to use, I cannot give you aby definite answer, since the kernel API and environment keeps changing continuously, so new code will not easily compile on older kernels and vice versa. > If you want to go down that road, I would recommend a bisectional approach, e.g., try if the code from 3.15 applies and runs, and then go forwards or backwards from there. > But, as already said, look at the problem you have at hand first. Jon, thank you for the answer. I saw that the problem is in the lack of memory. I also made a simple stress test (one side sends in a loop) and received this problem immediately. But User's Manual states that if there is no room for the receiving side to accept message it prevents the sending side from sending, effectively blocking the sender. This is what I expected to occur. But this doesn't happen in my case. I logged the sendto() execution time and it always was less then 2ms, except the case when this page error occurred on the accepting side - then sendto() took about 500-700 ms. Excuse me, please, may be this is the simple newbie question...:-) What do I do wrong? -- Leon -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140 ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
[tipc-discussion] Max msg length
Hello, all. I tried to understand what is the maximum TIPC message length allowed. I found version 1.7 manual saying that 66000 bytes is the upper limit. But this number seemed to me strange and I continued to search. And I found TIPC discussion saying: "...as the maximum length of one TIPC message never exceeds the maximum of signed integer". -) And, BTW, where does the 66000 magic number come from? Thanks a lot ahead. -- Leon -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140 ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] Please, help - no connection
On Tuesday 22 March 2016 12:27:07 Jon Maloy wrote: > Hi Leon, > Netid was never obligatory. It has a default value of 4711, and will use > that if no other value is explicitly set. Personally, I practically never > set it. > So, to me it sounds like you still have a problem. As for now, the system seems to work as required. The change was to use: tipc-config -netid=1234 -addr=1.1.X -be=eth:eth0 instead of non-working variant: tipc-config -addr=1.1.X >From what you say the '-be' is obligatory in my case? -- Leon -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140 ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Re: [tipc-discussion] Please, help - no connection
Thank you very much both Richard and Jon. I found the problem - it was that I missed the netid parameter in tipc-config call. I did not notice that I need it in the manual example, while my all previous development worked fine inside the same machine. May be it will be useful to add some kind of control for this parameter absence in the tool - it's necessity/obligatory is not obvious... Again, thanks a lot for the help!!! On Monday 21 March 2016 13:27:55 Jon Maloy wrote: > Richard, this is kernel 2.6.37. I doubt very much that the 'tipc' tool will work with that kernel version. Correct me if I am wrong. > Anyway, I am pretty sure that the choice of tool is not the issue here; to try changing it would just cause him unnecessary extra work. > > > Leon, just a control question: since you are indicating your IP addresses, I hope this doesn't mean you are trying to configure an IP bearer. This isn't supported in the TIPC version you are using; it came a lot later. > > I would start doing the following: > What does tipc-config say about the bearers? Have they been correctly enabled? Do the nodes have the addresses you have set? > Does Wireshark show that the discovery messages are transferred and responded to as they should ? > If not, since you are anyway hacking the code, why not throw in a couple of printouts to verify what happens to those messages in the code. It is the disabling of the disc_domain test that makes me suspicious. I this test replaced bay an unconditional "true" (it should be) ? > > Try this, and chances are good you will find what is missing. > > Regards > ///jon > > > -Original Message- > > From: Richard Alpe [mailto:richard.a...@ericsson.com] > > Sent: Monday, 21 March, 2016 04:06 > > To: Leon Pollak; tipc-discussion@lists.sourceforge.net > > Subject: Re: [tipc-discussion] Please, help - no connection > > > > Hi Leon, > > > > On 2016-03-20 13:32, Leon Pollak wrote: > > > I have 2 Linux 2.6.37 embedded ARM computers with TIPC compiled-in. > > > > > > IP1=192.168.1.1 > > > TIPC1=1.1.1 > > > > > > IP2=192.168.1.2 > > > TIPC2=1.1.2 > > > > > > Both addresses were assigned with tipc-config utility, which was cross- > > > compiled for the case. Compilation failed at first (because of kernel > > > version?) with the errors, which were solved as following: > > > - function show_stat() was masked out; > > > - function enable_bearer() reference to the field disk_domain was commented > > > out. > > This tool is deprecated. I would suggest using the "tipc" tools present in the > > iproute2 package. > > > > > Running connection-demo on each one of the computers works fine. > > > Running client on 2 and server on 1 fails with timeout. > > > Ping, obviously, works between them. > > Can you try running the PTTS test? > > > > Regards > > Richard > > -- Leon -- Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140 ___ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
