Re: Pistachio IPC performance on Bare Metal

--001a11c29f3ef6f3bf0503bb3e7a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

You can always call the RDTSC x86 instruction (i assume your cpu has it
since it's not that old hw) and move it's result in the ipc msg.
Transmit the msg and on the other end call the RDTSC instruction again.
Subtract the value from the ipc msg from the result of the current RDTSC
instruction and you will have approximately the most accurate measurement +
the time for the extra move and subs instructions.
Since you know the hw you are running your sw on you can determine the
amount of cpu cycles it takes to execute these 2 instructions (mov & subs).
Subtract again this amount from the previous result and you are looking at
the exact cpu cycles your machine took to execute your code from point to
point.

PS do not freak out when you receive inconsistent results. These are most
likely side effect of the instruction and data cache misses (if such occur
actually).


2014-09-23 13:06 GMT+02:00 Jens Kehne <[email protected]>:

> Hi Matt,
>
> Am 20.09.2014 um 01:03 schrieb matthew scaperoth:
> > My question really is how to optimize. I would like to get intra
> > process IPC down to < 200 cycles, but I've sort of hit a wall. I do
> > have fast path enabled and debugging disabled. The code I altered was
> > pingpong and I simply removed the loops and message register
> > iteration so that I could perform a single IPC. I wrapped the IPC
> > call with two variables that catch the clock time before and after
> > the IPC. I do this several thousand times and take an average.
> >
> > Any ideas on what I am doing wrong?
>
> After skimming through your code, I believe the problem is that you try
> to measure the latency of each individual IPC message. I didn't check
> how exactly the functions you are using take the time, but it's very
> possible that their resolution is not high enough to measure individual
> IPC messages. In addition, there is overhead associated with calling
> those functions. If you call them once per IPC message, that overhead
> adds up, which might explain the long IPC latencies you're seeing. The
> original pingpong instead takes the time for n IPC messages and divides
> by n. That averages out both the inaccuracy of the clock itself and the
> overhead associated with reading it.
>
> HTH
>
> Jens
>
> --
> Karlsruhe Institute of Technology (KIT)
> Operating Systems Group
>
> Dipl.-Inform. Jens Kehne
> Researcher
>
> Am Fasanengarten 5
> Building 50.34
> 76131 Karlsruhe, Germany
>
> Phone: +49 721 608-42645
> Fax: +49 721 608-47664
> Email: kehne@kit edu
> Web: http://www.kit.edu/
>
> KIT =E2=80=93 University of the State of Baden-Wuerttemberg and
> National Research Center of the Helmholtz Association
>
>

--001a11c29f3ef6f3bf0503bb3e7a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You can always call the RDTSC x86 instruction (i assume yo=
ur cpu has it since it&#39;s not that old hw) and move it&#39;s result in t=
he ipc msg.<div>Transmit the msg and on the other end call the RDTSC instru=
ction again. Subtract the value from the ipc msg from the result of the cur=
rent RDTSC instruction and you will have approximately the most accurate me=
asurement + the time for the extra move and subs instructions.</div><div>Si=
nce you know the hw you are running your sw on you can determine the amount=
 of cpu cycles it takes to execute these 2 instructions (mov &amp; subs).=
=C2=A0</div><div>Subtract again this amount from the previous result and yo=
u are looking at the exact cpu cycles your machine took to execute your cod=
e from point to point.</div><div><br></div><div>PS do not freak out when yo=
u receive inconsistent results. These are most likely side effect of the in=
struction and data cache misses (if such occur actually).</div><div>=C2=A0<=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2014-0=
9-23 13:06 GMT+02:00 Jens Kehne <span dir=3D"ltr">&lt;<a href=3D"mailto:keh=
[email protected]" target=3D"_blank">[email protected]</a>&gt;</span>:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">Hi Matt,<br>
<br>
Am 20.09.2014 um 01:03 schrieb matthew scaperoth:<br>
<span class=3D"">&gt; My question really is how to optimize. I would like t=
o get intra<br>
&gt; process IPC down to &lt; 200 cycles, but I&#39;ve sort of hit a wall. =
I do<br>
&gt; have fast path enabled and debugging disabled. The code I altered was<=
br>
&gt; pingpong and I simply removed the loops and message register<br>
&gt; iteration so that I could perform a single IPC. I wrapped the IPC<br>
&gt; call with two variables that catch the clock time before and after<br>
&gt; the IPC. I do this several thousand times and take an average.<br>
&gt;<br>
&gt; Any ideas on what I am doing wrong?<br>
<br>
</span>After skimming through your code, I believe the problem is that you =
try<br>
to measure the latency of each individual IPC message. I didn&#39;t check<b=
r>
how exactly the functions you are using take the time, but it&#39;s very<br=
>
possible that their resolution is not high enough to measure individual<br>
IPC messages. In addition, there is overhead associated with calling<br>
those functions. If you call them once per IPC message, that overhead<br>
adds up, which might explain the long IPC latencies you&#39;re seeing. The<=
br>
original pingpong instead takes the time for n IPC messages and divides<br>
by n. That averages out both the inaccuracy of the clock itself and the<br>
overhead associated with reading it.<br>
<br>
HTH<br>
<br>
Jens<br>
<br>
--<br>
Karlsruhe Institute of Technology (KIT)<br>
Operating Systems Group<br>
<br>
Dipl.-Inform. Jens Kehne<br>
Researcher<br>
<br>
Am Fasanengarten 5<br>
Building 50.34<br>
76131 Karlsruhe, Germany<br>
<br>
Phone: <a href=3D"tel:%2B49%20721%20608-42645" value=3D"+4972160842645">+49=
 721 608-42645</a><br>
Fax: <a href=3D"tel:%2B49%20721%20608-47664" value=3D"+4972160847664">+49 7=
21 608-47664</a><br>
Email: kehne@kit edu<br>
Web: <a href=3D"http://www.kit.edu/" target=3D"_blank">http://www.kit.edu/<=
/a><br>
<br>
KIT =E2=80=93 University of the State of Baden-Wuerttemberg and<br>
National Research Center of the Helmholtz Association<br>
<br>
</blockquote></div><br></div>

--001a11c29f3ef6f3bf0503bb3e7a--