[jacorb-developer] Delay in serial communication

[Nick Cross]

Please note support from the community is on a best-effort basis. If you
need specialised support (especially with relation to interaction with
particular hardware / operating systems) then I would recommend
contacting the commercial companies listed on
http://www.jacorb.org/support.html for professional support.

If I remember correctly I suggested that you could use a simple byte
stream to represent the incoming data from the microcontroller to
attempt to narrow down where your issue is. I do not have access to a 
Windows system (I use Fedora 16) to test against.

As Steve has suggested you might try a profiler (e.g. JProfiler) and 
analyse where the time is taken.

Regards

Nick


On 26/07/12 11:50, Kujtim Hyseni wrote:
>
> Hello Nick,
>
> Ok, I will do what you have suggested. But, I have some questions
> regarding the process...
>
> *) Will someone of JacORB team contact me later when they begin to
> test my code *) You probably don't have 8051 microcontroller at
> back-end (to receive response from), but you will need to "simulate"
> it, thus, you will need "another" PC which communicates with PC
> hosting the JacORB server I am submitting. The "other" PC will listen
> at sepcified port and respond sime message which syntax is: first
> byte=length, other bytes of length-1 any contect. Probbaly I will
> need to supply you with the code of "other" PC *) But first, please
> do more simple test - a simple server, with an interface with just
> one method with no parameters which returns void but implements
> Thread.sleep(5000); instruction and see how it affects your PC. In
> Windows: please start media player or see how your whole operating
> system is blocked.
>
> Anyway, I am available to you at any time ... so please contact me if
> I need you.
>
> Kujtim
>
>> Date: Thu, 26 Jul 2012 11:05:21 +0100 From: jacorb at goots.org To:
>> jacorb-developer at lists.spline.inf.fu-berlin.de CC:
>> kujtimhyseni at hotmail.com Subject: Re: [jacorb-developer] Delay in
>> serial communication
>>
>>
>> Checking back through my emails I find I did reply and you did not
>> enter a ticket with a standalone compilable test case to
>> demonstrate the issue. I have repeated my email below:
>>
>>
>>> On 19/04/12 08:54, Kujtim Hyseni wrote: - show quoted text -
>>>
>>> You have still not provided your IDL/Client code (and in fact a
>>> complete CORBA application would be useful). See below for how to
>>> submit it.
>>>
>>>> The solutions outside of the 'CORBA world' is very similar and
>>>> is present as follows:
>>>
>>> <snipped code>
>>>
>>> - show quoted text -
>>>
>>>
>>> Any communication 'over the wire' will cause *some* delay
>>> comparing to a direct local call (TCP transfer/marshalling etc).
>>> You have mentioned JacORB 'causes a delay' but have not shown
>>> that the simple overhead of a remote CORBA call is causing the
>>> supposed delays.
>>>
>>> Presumely in your CORBA application the client is calling
>>> operation1/2? How does your Thread end? I can't see any code to
>>> end it?
>>>
>>> You also mention that the application is causing a load on the
>>> CPU. Have you tried profiling it to see where the issue is?
>>>
>>> If you can demonstrate a bug in JacORB then please submit a
>>> standalone compilable test case showing the problem by submitting
>>> a bugzilla here http://www.jacorb.org/contrib.html
>>>
>>>>>> Have you tried using Wireshark to analyse the network
>>>>>> trace?
>>>> I cannot use Wireshark in local (localhost) invocations since
>>>> Windows (XP in my case) doesn't allows it - I will try it when
>>>> I will establish a network.
>>>
>>> Install Linux in a VM and test using that. Or look at the
>>> alternatives here
>>> http://wiki.wireshark.org/CaptureSetup/Loopback
>>>
>>>>>> Have you tried turning on JacORB debug logging?
>>>> Can you explain how to do this, please?
>>>
>>> See the JacORB programming guide.
>>
>>
>>
>> Regards
>>
>> Nick
>>
>>
>>
>>
>> On 26/07/12 10:53, Kujtim Hyseni wrote:
>>>
>>> On date 29 March 2012 I posted the following message at JacORB
>>> mailing list:
>>>
>>> "Hello,
>>>
>>> for my project I heave developed a class (implementation class)
>>> which forwards requests (operations) from client to serial port,
>>> waits for response, receives the response and sends it back to
>>> client but it takes a long time to perform it. It delays in
>>> receiving the response from serial port. For communication with
>>> serial port I have developed a dedicated class which implements
>>> Runnable and SerialPortEventListener classes. My class
>>> communicates serially with 8051 microcontroller. Again, it seems
>>> that class delays in receiving the byte stream from
>>> microcontroller. Microcontroller has a built in serial port while
>>> my PC uses USB-to-Serial cable. When I communicate
>>> microcontroller with the class from usual Java program (from
>>> main() routine) it works fine and it takes less than a second to
>>> receive the response back.
>>>
>>> I did some measurements (100 requests) in two ways. In the
>>> first, communication class is external and is instantiated from
>>> implementation class. In the second, communication class is
>>> merged with implementation class. The results are: for first way
>>> average response time 9.33266 seconds, minimal response time
>>> 4.984 seconds while maximal response time 18.015 seconds; for
>>> second way average response time 8.62625 seconds, minimal
>>> response time 4.969 seconds while maximal response time 16.015
>>> seconds. These values are unacceptable for real time applications
>>> and raise the question for using JacORB further.
>>>
>>>
>>> What do you think and suggest about?"
>>>
>>> Then I got various suggestions (from Nick Cross) such: to
>>> install JacORB 3.0 and provide the code samples.
>>>
>>> I now installed JacORB 3.0 and made the same tests, but, received
>>> the same delays - just to illustrate for 5 requests times are
>>> (in seconds): 6.735, 12, 8, 7 and 13. When I invoke the requests
>>> from usual java program it takes less than a second per request -
>>> this is normal since routines at this phase are void , they just
>>> return values.
>>>
>>> Again, these delays are unacceptable for out application and if
>>> not resolved we will abandon JacORB and move to another ORB or
>>> perhaps Web service technology.
>>>
>>> Can someone from JacORB developers or mailing list contributors
>>> pay some attention and help resolving this issue, in order to
>>> continue with my project and use JacORB.
>>>
>>> Kujtim Hyseni  _______________________________________________
>>> jacorb-developer maillist  -
>>> jacorb-developer at lists.spline.inf.fu-berlin.de
>>> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
>>>
>
>>>
> _______________________________________________ jacorb-developer
> maillist  -  jacorb-developer at lists.spline.inf.fu-berlin.de
> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
>