The only thing that immediately springs to mind is that the app is
linked against libc.so.2.  There's a Global Offset Table in shared
objects that results in a function redirection when the library function
is called.

Doing an ntox86-objdump on libc.so.2 shows that it needs libc.so.3, so
I'm assuming that for some libc functions you need to go through two
levels of indirection (libc.so.2 into libc.so.3) to get into the real
function on 6.4.0, so there's additional overhead that isn't present
with the same binary on 6.3.2.  How significant this would be, I don't
know, but I guess that it's possible that for very small writes, the
function call overhead becomes significant whereas for larger packet
sizes, it isn't 

I have to admit that I consider this to be hand waving, and I could be
talking through my hat, but it's the best that I've got for now :>

	R.


-----Original Message-----
From: Juan Manuel Placco [mailto:community-noreply@qnx.com] 
Sent: Wednesday, February 04, 2009 9:27 AM
To: technology-networking
Subject: Re: RE: RE: RE: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison

> Ummm... I thought in your last posting you mentioned:
> 
> "I delay my answer to do ALL this tests again in order to be totally 
> sure "
> 
> So I was waiting for you to confirm your results (?)
> 
> I have to admit that I'm floundering on this one.  Without some 
> extensive profiling (of system and application) I'd only be making 
> speculative guesses.  Maybe this is one that would be best asked in 
> the OS forums?
> 
> 	R.
> 
> -----Original Message-----
> From: Juan Manuel Placco [mailto:community-noreply@qnx.com]
> Sent: Tuesday, February 03, 2009 6:15 PM
> To: technology-networking
> Subject: Re: RE: RE: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison
> 
> Hi... is there any news about this topic?
> 
> Thank you!!
> 
> Juan Manuel
> 
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post21370


Hi Robert, thank you very much for the anwer.

Yes... You are right but I've already tried once in the OS forum, but
with less lucky than here :), a much worst response time :)

Anyway, if you have a feeling, I'am sure it will be better than mines,
so I would be extremely grateful to have your opinion. 

The question is exactly what you summarised in last post.

>> Let me see if I can summarise your question...

>> Running a 6.4 binary on 6.4 is always faster than the 6.3 version at 
>> all times.

>> When you compare running the 6.3 binary on 6.4 with running the 6.3 
>> binary on 6.3, for all cases EXCEPT the 10 byte case, a performance 
>> increase is seen.  For the 10 byte case, a performance decrease is 
>> seen. Why?

>> I'll wait and see if that's the question before I try to answer :>.

>>	Robert.

The answer is YES. 

BUT, if you think the only way is to re-post to the OS Forum, just let
me know...

Thank you in advance, Robert. 

Regards,
Juan Manuel


_______________________________________________
Technology
http://community.qnx.com/sf/go/post21400

You are waving your hands wildly, but at what I don't know... :-)

There is no indirection other than the normal PLT.  The compat libc.so.2
doesn't actually contain any of the libc.so.3 functions, it's only got
some backend gcc stubs.

Robert Craig wrote:
> The only thing that immediately springs to mind is that the app is
> linked against libc.so.2.  There's a Global Offset Table in shared
> objects that results in a function redirection when the library function
> is called.
> 
> Doing an ntox86-objdump on libc.so.2 shows that it needs libc.so.3, so
> I'm assuming that for some libc functions you need to go through two
> levels of indirection (libc.so.2 into libc.so.3) to get into the real
> function on 6.4.0, so there's additional overhead that isn't present
> with the same binary on 6.3.2.  How significant this would be, I don't
> know, but I guess that it's possible that for very small writes, the
> function call overhead becomes significant whereas for larger packet
> sizes, it isn't 
> 
> I have to admit that I consider this to be hand waving, and I could be
> talking through my hat, but it's the best that I've got for now :>
> 
> 	R.
> 
> 
> -----Original Message-----
> From: Juan Manuel Placco [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, February 04, 2009 9:27 AM
> To: technology-networking
> Subject: Re: RE: RE: RE: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison
> 
>> Ummm... I thought in your last posting you mentioned:
>>
>> "I delay my answer to do ALL this tests again in order to be totally 
>> sure "
>>
>> So I was waiting for you to confirm your results (?)
>>
>> I have to admit that I'm floundering on this one.  Without some 
>> extensive profiling (of system and application) I'd only be making 
>> speculative guesses.  Maybe this is one that would be best asked in 
>> the OS forums?
>>
>> 	R.
>>
>> -----Original Message-----
>> From: Juan Manuel Placco [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, February 03, 2009 6:15 PM
>> To: technology-networking
>> Subject: Re: RE: RE: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison
>>
>> Hi... is there any news about this topic?
>>
>> Thank you!!
>>
>> Juan Manuel
>>
>>
>> _______________________________________________
>> Technology
>> http://community.qnx.com/sf/go/post21370
> 
> 
> Hi Robert, thank you very much for the anwer.
> 
> Yes... You are right but I've already tried once in the OS forum, but
> with less lucky than here :), a much worst response time :)
> 
> Anyway, if you have a feeling, I'am sure it will be better than mines,
> so I would be extremely grateful to have your opinion. 
> 
> The question is exactly what you summarised in last post.
> 
>>> Let me see if I can summarise your question...
> 
>>> Running a 6.4 binary on 6.4 is always faster than the 6.3 version at 
>>> all times.
> 
>>> When you compare running the 6.3 binary on 6.4 with running the 6.3 
>>> binary on 6.3, for all cases EXCEPT the 10 byte case, a performance 
>>> increase is seen.  For the 10 byte case, a performance decrease is 
>>> seen. Why?
> 
>>> I'll wait and see if that's the question before I try to answer :>.
> 
>>> 	Robert.
> 
> The answer is YES. 
> 
> BUT, if you think the only way is to re-post to the OS Forum, just let
> me know...
> 
> Thank you in advance, Robert. 
> 
> Regards,
> Juan Manuel
> 
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post21400
> 
> 
>...

I stand (well ok... sit) corrected.  My hat has a big hole in it
somewhere.

So my answer to the original question is: I don't know :>  

To be honest, I'm also not sure if the effort to investigate further is
worthwhile.  
The moral of the story is...  If you're going to be running on 6.4.0,
compile your application on 6.4.0.

	R. 

-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com] 
Sent: Wednesday, February 04, 2009 1:27 PM
To: technology-networking
Subject: Re: QNX 6.4 - QNX 6.3 Comparison

You are waving your hands wildly, but at what I don't know... :-)

There is no indirection other than the normal PLT.  The compat libc.so.2
doesn't actually contain any of the libc.so.3 functions, it's only got
some backend gcc stubs.

Robert Craig wrote:
> The only thing that immediately springs to mind is that the app is 
> linked against libc.so.2.  There's a Global Offset Table in shared 
> objects that results in a function redirection when the library 
> function is called.
> 
> Doing an ntox86-objdump on libc.so.2 shows that it needs libc.so.3, so

> I'm assuming that for some libc functions you need to go through two 
> levels of indirection (libc.so.2 into libc.so.3) to get into the real 
> function on 6.4.0, so there's additional overhead that isn't present 
> with the same binary on 6.3.2.  How significant this would be, I don't

> know, but I guess that it's possible that for very small writes, the 
> function call overhead becomes significant whereas for larger packet 
> sizes, it isn't
> 
> I have to admit that I consider this to be hand waving, and I could be

> talking through my hat, but it's the best that I've got for now :>
> 
> 	R.
> 
> 
> -----Original Message-----
> From: Juan Manuel Placco [mailto:community-noreply@qnx.com]
> Sent: Wednesday, February 04, 2009 9:27 AM
> To: technology-networking
> Subject: Re: RE: RE: RE: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison
> 
>> Ummm... I thought in your last posting you mentioned:
>>
>> "I delay my answer to do ALL this tests again in order to be totally 
>> sure "
>>
>> So I was waiting for you to confirm your results (?)
>>
>> I have to admit that I'm floundering on this one.  Without some 
>> extensive profiling (of system and application) I'd only be making 
>> speculative guesses.  Maybe this is one that would be best asked in 
>> the OS forums?
>>
>> 	R.
>>
>> -----Original Message-----
>> From: Juan Manuel Placco [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, February 03, 2009 6:15 PM
>> To: technology-networking
>> Subject: Re: RE: RE: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison
>>
>> Hi... is there any news about this topic?
>>
>> Thank you!!
>>
>> Juan Manuel
>>
>>
>> _______________________________________________
>> Technology
>> http://community.qnx.com/sf/go/post21370
> 
> 
> Hi Robert, thank you very much for the anwer.
> 
> Yes... You are right but I've already tried once in the OS forum, but 
> with less lucky than here :), a much worst response time :)
> 
> Anyway, if you have a feeling, I'am sure it will be better than mines,

> so I would be extremely grateful to have your opinion.
> 
> The question is exactly what you summarised in last post.
> 
>>> Let me see if I can summarise your question...
> 
>>> Running a 6.4 binary on 6.4 is always faster than the 6.3 version at

>>> all times.
> 
>>> When you compare running the 6.3 binary on 6.4 with running the 6.3 
>>> binary on 6.3, for all cases EXCEPT the 10 byte case, a performance 
>>> increase is seen.  For the...

That is because the debut libc.so.3 (and the compat libc.so.2) are
poorly documented, or, should I say do we have even a memo internal
circulated? ;-)

Weijie  

-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com] 
Sent: February 4, 2009 1:27 PM
To: technology-networking
Subject: Re: QNX 6.4 - QNX 6.3 Comparison

You are waving your hands wildly, but at what I don't know... :-)

There is no indirection other than the normal PLT.  The compat libc.so.2
doesn't actually contain any of the libc.so.3 functions, it's only got
some backend gcc stubs.

Robert Craig wrote:
> The only thing that immediately springs to mind is that the app is
> linked against libc.so.2.  There's a Global Offset Table in shared
> objects that results in a function redirection when the library
function
> is called.
> 
> Doing an ntox86-objdump on libc.so.2 shows that it needs libc.so.3, so
> I'm assuming that for some libc functions you need to go through two
> levels of indirection (libc.so.2 into libc.so.3) to get into the real
> function on 6.4.0, so there's additional overhead that isn't present
> with the same binary on 6.3.2.  How significant this would be, I don't
> know, but I guess that it's possible that for very small writes, the
> function call overhead becomes significant whereas for larger packet
> sizes, it isn't 
> 
> I have to admit that I consider this to be hand waving, and I could be
> talking through my hat, but it's the best that I've got for now :>
> 
> 	R.
> 
> 
> -----Original Message-----
> From: Juan Manuel Placco [mailto:community-noreply@qnx.com] 
> Sent: Wednesday, February 04, 2009 9:27 AM
> To: technology-networking
> Subject: Re: RE: RE: RE: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison
> 
>> Ummm... I thought in your last posting you mentioned:
>>
>> "I delay my answer to do ALL this tests again in order to be totally 
>> sure "
>>
>> So I was waiting for you to confirm your results (?)
>>
>> I have to admit that I'm floundering on this one.  Without some 
>> extensive profiling (of system and application) I'd only be making 
>> speculative guesses.  Maybe this is one that would be best asked in 
>> the OS forums?
>>
>> 	R.
>>
>> -----Original Message-----
>> From: Juan Manuel Placco [mailto:community-noreply@qnx.com]
>> Sent: Tuesday, February 03, 2009 6:15 PM
>> To: technology-networking
>> Subject: Re: RE: RE: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison
>>
>> Hi... is there any news about this topic?
>>
>> Thank you!!
>>
>> Juan Manuel
>>
>>
>> _______________________________________________
>> Technology
>> http://community.qnx.com/sf/go/post21370
> 
> 
> Hi Robert, thank you very much for the anwer.
> 
> Yes... You are right but I've already tried once in the OS forum, but
> with less lucky than here :), a much worst response time :)
> 
> Anyway, if you have a feeling, I'am sure it will be better than mines,
> so I would be extremely grateful to have your opinion. 
> 
> The question is exactly what you summarised in last post.
> 
>>> Let me see if I can summarise your question...
> 
>>> Running a 6.4 binary on 6.4 is always faster than the 6.3 version at

>>> all times.
> 
>>> When you compare running the 6.3 binary on 6.4 with running the 6.3 
>>> binary on 6.3, for all cases EXCEPT the 10 byte case, a performance 
>>> increase is seen.  For the 10 byte case, a performance decrease is 
>>> seen. Why?
> 
>>> I'll wait and see if that's the question before I try to answer :>.
> 
>>> 	Robert.
> 
> The...

http://community.qnx.com/sf/discussion/do/listPosts/projects.core_os/discussion.osrev.topc3117?pageSize=-1#post9324
has a discussion on the reasons for the libc.so.3 change.

Colin

Weijie Zhang wrote:
> That is because the debut libc.so.3 (and the compat libc.so.2) are
> poorly documented, or, should I say do we have even a memo internal
> circulated? ;-)
> 
> Weijie  
> 
> -----Original Message-----
> From: Colin Burgess [mailto:community-noreply@qnx.com] 
> Sent: February 4, 2009 1:27 PM
> To: technology-networking
> Subject: Re: QNX 6.4 - QNX 6.3 Comparison
> 
> You are waving your hands wildly, but at what I don't know... :-)
> 
> There is no indirection other than the normal PLT.  The compat libc.so.2
> doesn't actually contain any of the libc.so.3 functions, it's only got
> some backend gcc stubs.
> 
> Robert Craig wrote:
>> The only thing that immediately springs to mind is that the app is
>> linked against libc.so.2.  There's a Global Offset Table in shared
>> objects that results in a function redirection when the library
> function
>> is called.
>>
>> Doing an ntox86-objdump on libc.so.2 shows that it needs libc.so.3, so
>> I'm assuming that for some libc functions you need to go through two
>> levels of indirection (libc.so.2 into libc.so.3) to get into the real
>> function on 6.4.0, so there's additional overhead that isn't present
>> with the same binary on 6.3.2.  How significant this would be, I don't
>> know, but I guess that it's possible that for very small writes, the
>> function call overhead becomes significant whereas for larger packet
>> sizes, it isn't 
>>
>> I have to admit that I consider this to be hand waving, and I could be
>> talking through my hat, but it's the best that I've got for now :>
>>
>> 	R.
>>
>>
>> -----Original Message-----
>> From: Juan Manuel Placco [mailto:community-noreply@qnx.com] 
>> Sent: Wednesday, February 04, 2009 9:27 AM
>> To: technology-networking
>> Subject: Re: RE: RE: RE: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison
>>
>>> Ummm... I thought in your last posting you mentioned:
>>>
>>> "I delay my answer to do ALL this tests again in order to be totally 
>>> sure "
>>>
>>> So I was waiting for you to confirm your results (?)
>>>
>>> I have to admit that I'm floundering on this one.  Without some 
>>> extensive profiling (of system and application) I'd only be making 
>>> speculative guesses.  Maybe this is one that would be best asked in 
>>> the OS forums?
>>>
>>> 	R.
>>>
>>> -----Original Message-----
>>> From: Juan Manuel Placco [mailto:community-noreply@qnx.com]
>>> Sent: Tuesday, February 03, 2009 6:15 PM
>>> To: technology-networking
>>> Subject: Re: RE: RE: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison
>>>
>>> Hi... is there any news about this topic?
>>>
>>> Thank you!!
>>>
>>> Juan Manuel
>>>
>>>
>>> _______________________________________________
>>> Technology
>>> http://community.qnx.com/sf/go/post21370
>>
>> Hi Robert, thank you very much for the anwer.
>>
>> Yes... You are right but I've already tried once in the OS forum, but
>> with less lucky than here :), a much worst response time :)
>>
>> Anyway, if you have a feeling, I'am sure it will be better than mines,
>> so I would be extremely grateful to have your opinion. 
>>
>> The question is exactly what you summarised in last post.
>>
>>>> Let me see if I can...

So do the release notes:

 
http://www.qnx.com/developers/docs/6.4.0/momentics/release_notes/rel_6.4
.0.html#New_libraries

Steve Reid (stever@qnx.com)
Technical Editor
QNX Software Systems 

Hi again, and sorry. Any comments, please?

Thank you very much!

Juan Manuel

Hi Juan:
	We'll get to it when we can.  There's a lot of other things
going on just now I'm afraid.

	Robert. 

-----Original Message-----
From: Juan Manuel Placco [mailto:community-noreply@qnx.com] 
Sent: Tuesday, December 09, 2008 5:56 PM
To: technology-networking
Subject: Re: RE: RE: RE: QNX 6.4 - QNX 6.3 Comparison

Hi again, and sorry. Any comments, please?

Thank you very much!

Juan Manuel


_______________________________________________
Technology
http://community.qnx.com/sf/go/post18253

Ok Robert. I can understand. Just don't forget me, please !!

Regards and thank you very much for the support,
Juan Manuel

Hi Juan:

	I'm also confused about what "cant_msg" is used for in the
client.  The usage says "messages amount" which seems to imply that this
is the size of the message to send, but that's definitely not what it
does.  It simply acts as a loop counter to send the same message size
(1024 bytes) all the time and the "cant_msg" acts as another multiplier
to the top level "cant_retries" loop.  

	Robert.



-----Original Message-----
From: Robert Craig 
Sent: Thursday, December 04, 2008 2:29 PM
To: 'post17863@community.qnx.com'
Subject: RE: QNX 6.4 - QNX 6.3 Comparison

Hi Juan:

	I finally got around to looking through your test code and there
are problems in there with the way that you're doing your timing
calculation in the client.

The resolution of the internal clock is usually set to 1 ms, so if your
single msg send takes less than this amount of time to run, then you'll
end up with invalid timing results.  Instead of doing your timing check
around the single message send and then summing the results together in
your main function (totmsg += mseg), you need to do the timing
comparison around your "for (i = 0; i < cant_retries; i++)" loop to get
the total time.  And you need to make absolutely sure that the number of
retries that you pass in gives you a good amount of time in order for
the timing results to be valid.

Also, the server side doesn't properly handle the network message case.
From the docs for MsgReceive:

"In a local message pass, the kernel would ordinarily limit the size of
the transfer to the minimum of both sizes. But in the networked case,
the message is received by the client's lsm-qnet.so into its own private
buffers and then sent via transport to the remote lsm-qnet.so. Since the
size of the server's receive data area can't be known in advance by the
client's lsm-qnet.so when the message is sent, only a fixed maximum size
(currently 8 KB) message is transferred between the client and the
server. "

(See the sample code for how this should be handled).


	Robert.


 

-----Original Message-----
From: Juan Manuel Placco [mailto:community-noreply@qnx.com]
Sent: Wednesday, December 03, 2008 12:55 PM
To: technology-networking
Subject: Re: QNX 6.4 - QNX 6.3 Comparison

Yes Robert, I'm surprised too, and I was expecting the same conclusions
you mention. Mario, I was in the idea that a memmove is a memmove
(almost an assembly level function and DMA's task)

Thanks very much for your answers!!

Regards,
Juan Manuel


_______________________________________________
Technology
http://community.qnx.com/sf/go/post17863

> Hi Juan:
> 
> The usage says "messages amount" which seems to imply that this
> is the size of the message to send

Robert, so, this is my erroneous translation to english (as you noticed is not very good) ... Sorry... I wanted to mean 
the "amount of messages sended".... but I didn't find the correct words to mean that...

"amount of messages sended" could work ?

Thanks, I'm learning too much with this discussion, 

Believe me, I'm very thankful!!
Juan Manuel

Hi Juan,
a little to hint to do some CPU time mesurements.
to do a real CPU time measurements you can read each threads' CPU clock time.
to do this you have to get the right clockID and then do ClockTime()

long long start;
long long end;
clockid_t c_id  = ClockId( getpid(), pthread_self() );

ClockTime( c_id, 0, &start);

// do your stuff

ClockTime( c_id, 0, &end);

long long cpu_in_nanos = end - start;

with this you are measuring only the CPU time of this single thread,
nothing else.
maybe this helps to get more precise times


/hp

In your usage message, I'd say "number of messages to send".


Steve Reid (stever@qnx.com)
Technical Editor
QNX Software Systems 
 

> -----Original Message-----
> From: Juan Manuel Placco [mailto:community-noreply@qnx.com] 
> Sent: Thursday, December 04, 2008 4:17 PM
> To: technology-networking
> Subject: Re: RE: QNX 6.4 - QNX 6.3 Comparison
> 
> > Hi Juan:
> > 
> > The usage says "messages amount" which seems to imply that this
> > is the size of the message to send
> 
> Robert, so, this is my erroneous translation to english (as 
> you noticed is not very good) ... Sorry... I wanted to mean 
> the "amount of messages sended".... but I didn't find the 
> correct words to mean that...
> 
> "amount of messages sended" could work ?
> 
> Thanks, I'm learning too much with this discussion, 
> 
> Believe me, I'm very thankful!!
> Juan Manuel
> 
> 
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post17958
> 
> 

Thanks!!... it was so easy... :)