<html>
<head>
</head>
<body>
Does this issue effect the native RTEMS method of using threads / tasks i.e.
non-posix methods? <br>
<br>
Joel Sherrill wrote:<br>
<blockquote type="cite" cite="mid:3DEE0C1C.4F169E9A@OARcorp.com">
  <pre wrap=""><br>Till Straumann wrote:<br></pre>
  <blockquote type="cite">
    <pre wrap="">MEA CULPA.<br><br>Ooops, I'm to blame for a really bad one, sorry.<br>Obviously, I'm not too experienced with the pthread API :-(<br></pre>
    </blockquote>
    <pre wrap=""><!----><br>Don't feel bad, even after having reviewed and commented<br>upon various drafts of the pthreads spec, implementing most of<br>it in RTEMS, porting GNAT to RTEMS pthreads, and implementing<br>applications using it, I still find it obtuse and confusing.<br>It is VERY easy to make mistakes. :(<br><br></pre>
    <blockquote type="cite">
      <pre wrap="">My benchmark code fails to set PTHREAD_EXPLICIT_SCHED and hence<br>the benchmark task runs at the wrong priority. I had developed the<br>pthread stuff for RT-Linux (where EXPLICIT_SCHED is the default,<br>as it is on some other systems, it seems).<br></pre>
      </blockquote>
      <pre wrap=""><!----><br>I searched some last night<br> <br></pre>
      <blockquote type="cite">
        <pre wrap="">After fixing this, it looks like pthread performance is very similar<br>to using RTEMS native threads.<br><br>An updated version is available at<br><br><a class="moz-txt-link-freetext" href="http://www.slac.stanford.edu/~strauman/rtoslat/index.html">http://www.slac.stanford.edu/~strauman/rtoslat/index.html</a><br></pre>
        </blockquote>
        <pre wrap=""><!----><br>Not to pick but could you update the table in the paper and post<br>a corrected version of it?  I would like to see a complete corrected<br>version of at least the data.  From what I can tell, the paper itself<br>wouldn't be terribly difficult to update either.<br><br>You mentioned using various blocking mechanisms.  Did any of them<br>show any discrepancies?<br> <br></pre>
        <blockquote type="cite">
          <pre wrap="">My sincere apologies<br></pre>
          </blockquote>
          <pre wrap=""><!----><br>No problem.  I was concerned enough to hunt for it anyway. :)<br><br>Besides benchmarking is difficult to do correctly.  Greg Menke went to<br>a lot of trouble and ended up with a scaling error in his initial <br>reported results.<br> <br></pre>
          <blockquote type="cite">
            <pre wrap="">-- Till<br><br>Joel Sherrill wrote:<br></pre>
            <blockquote type="cite">
              <pre wrap="">Till Straumann wrote:<br><br></pre>
              <blockquote type="cite">
                <pre wrap="">Joel Sherrill wrote:<br><br><br></pre>
                <blockquote type="cite">
                  <pre wrap="">Till Straumann wrote:<br><br><br><br></pre>
                  <blockquote type="cite">
                    <pre wrap="">Kamen Penev wrote:<br><br><br><br><br></pre>
                    <blockquote type="cite">
                      <pre wrap="">Hi!<br><br>Looking at your work comparing RTEMS, RTLinux and vxWorks, I am wondering<br>about the unusually poor RTEMS+pthreads result for context switching on a<br>loaded system. Has this been explained (better yet fixed)by the RTEMS<br>development team?<br><br><br></pre>
                      </blockquote>
                      </blockquote>
                      <pre wrap="">Which RTEMS version/target CPU/configuration?<br><br></pre>
                      </blockquote>
                      <pre wrap="">I believe it was ss-20011025 (I can re-run the test later today on a<br>later version).<br></pre>
                      </blockquote>
                      <pre wrap=""><br>That is pretty old and I am 100% positive it predates the work<br>I did to improve results on your benchmark.  The ChangeLog entry<br>for that is 2002-07-01.<br><br><br></pre>
                      <blockquote type="cite">
                        <pre wrap="">The target was a 604 series PowerPC on a Motorola MVME23xx board.<br></pre>
                        </blockquote>
                        <pre wrap=""><br>Do you know what the test is doing?  Is it the same as yours?  Saying<br>something is slow doesn't help me much.  RTEMS usually performs<br>comparable to VxWorks on benchmarks.  But each time we hit a new<br>benchmark comparison, there is new data to optimize against.<br><br><br></pre>
                        <blockquote type="cite">
                          <pre wrap="">-- Till<br><br><br></pre>
                          <blockquote type="cite">
                            <pre wrap=""><br></pre>
                            <blockquote type="cite">
                              <blockquote type="cite">
                                <pre wrap="">Thanks.<br><br>Kamen Penev<br>Adept Technology<br><br><br><br><br><br></pre>
                                </blockquote>
                                <pre wrap="">Good question. I am not using pthreads and the honest answer is "I dont<br>know".<br>I remember, however having brought this to Joel Sherrill's attention<br>(back in 2001<br>when I did the tests) and I believe he had some ideas about the cause...<br><br>-- Till<br><br><br></pre>
                                </blockquote>
                                <pre wrap=""><br><br></pre>
                                </blockquote>
                                </blockquote>
                                </blockquote>
                                </blockquote>
                                <pre wrap=""><!----><br></pre>
                                </blockquote>
                                <br>
                                <pre class="moz-signature" cols="$mailwrapcol">-- 
Angelo Fraietta

PO Box 859
Hamilton NSW 2303

Home Page


<a class="moz-txt-link-freetext" href="http://www.users.bigpond.com/angelo_f/">http://www.users.bigpond.com/angelo_f/</a>

There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
There are those who seek knowledge to be known by others - that is VANITY
There are those who seek knowledge in order to serve - that is LOVE
    Bernard of Clairvaux (1090 - 1153)</pre>
                                <br>
                                </body>
                                </html>