Re: FAST ACM! But "broken" timer? Gurus needed. Was: ACM 4.7-3 with Debian Linux 1.2.4
SUMMARY:
- I dare advance the proposal to slightly change the Debian acm-4.7
package (but Ian Murdock is not the maintainer of the package any more,
so who should I say?).
- I wonder (though I suppose not) whether gettimeofday() gives different
values than in Linux in some non-Linux Unix boxes (say Sun, Sparc and
the like).
- I suppose there's something to see also with 'xlock -mode rotor', it is
VERY slow here (Debian 1.2.4).
1) ACM 4.7 slow.
--------------------------------------------------------------------------
There is a chance that THE ACM DEBIAN PACKAGE IS WORTH BEING
RE-PREAPARED INCLUDING BINARIES BUILT WITH THE REAL_DELTA_T=no SETTING,
that is the binaries given by the self-applying workaround I posted
yesterday under the same subject (besides, they are compiled with more
optimization than the original Makefile's do) and, say, almost the first
and tiniest patch, labeled "A", the one to be able to successfully run the
'configure' script and rebuild the binaries (actually the only one I
prepared that is not so dirty to act on Makefile's produced by the
'configure' script itself, as the other "patches" do instead on going back
to Imakefile's).
Maybe in the past rebuilding of the binaries done in order to just
switch to elf has not considered that the "original" a.out binaries
distributed with Slackware may have been compiled with the REAL_DELTA_T=no
setting.
(
Actually, a more complete work could be done (*) to understand
whether a (Pentium 90) PC is just slow enough to justify the
REAL_DELTA_T=no setting.
Well, a good job would also be that of getting able to rebuild ACM
4.8 under Linux and then prepare a Debian package! Not to start a
competition [also because I think there is _already_ a winner :-)], but I
see that RedHat (4.1) still has acm-4.7-5... while the 4.8 package brings
a great IEEE standard for distributed computing, a spheroidal world...
ftp.netcom.com/pub/ra/rainey/acm/
)
--------------------------------------------------------------------------
Why I say this?
I looked at
acm-4.7/src/manifest.h
and
acm-4.7/src/update.c
and then prepared a small test to see if that gettimeofday(...) is
working differently when compiled and used under that old Slackware August
'95 and under Debian 1.2(.4)... it isn't, it's quite the same.
I rebuilt acm-4.7 under that old Slackware both with and without the
REAL_DELTA_T=no environment variable. AND THE FORMER IS FAST, THE LATTER
IS SLOW, BOTH THERE UNDER SLACKWARE AUGUST '95 AND HERE UNDER DEBIAN
1.2.4, so:
THE BINARIES GIVEN WITH SLACKWARE *MUST* HAVE BEEN BUILT WITH THE
ENVIRONMENT REAL_DELTA_T=no, AND ACTUALLY THEY ARE FAST HERE UNDER DEBIAN
TOO!
THE BINARIES GIVEN WITH DEBIAN (and RedHat 3.0.3, didn't test 4.1
yet) MUST HAVE BEEN BUILT WITHOUT THAT SETTING and the result (almost
here) is very slow motion...
... by the way, why?
(*) Maybe that gettimeofday(...) function works differently on
systems others than Linux? Nevertheless, acms says about 31 fps: the
src/manifest.h header has a compile switch that allows watching frame
rate, WATCH_FRAME_RATE actually. Then you also have to change the related
"printf(...)" output in src/update.c to "fprintf(stderr, ...)" to really
have it.
Someone owning a non-Linux Unix box, say Sun or Sparc or AIX,
should compile and run timetest.c, 1st attachment, and compare the kind of
numbers given with the ones in sample-result.cat, 2nd attachment... but I
suppose that's *NOT* the point, err..... I can't understand how the return
values of that "daily" function can be so great yet, but probably tons of
software born on various non-Linux Unix boxes and relating on that
function are working quite well once rebuilt and run under Linux, so the
true point is that the src/update.c function should be well understood.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
2) xlockmore-3.11 about 'xlock -mode rotor' being that slow: no news,
still to do.
Nicola Bernardelli <nbern@mail.protos.it>
---------------------------------------------------------------------------
Please use <n.bern@mail.protos.it> for messages from any kind of
robot, such as mailing lists. From that address no autoresponse
messages will return even when I'm not at home.
---------------------------------------------------------------------------
On Thu, 1 May 1997, Nicola Bernardelli wrote:
> On Tue, 29 Apr 1997, Nicola Bernardelli wrote:
>
> > On Mon, 28 Apr 1997, Nicola Bernardelli wrote:
> >
> > > On Sun, 27 Apr 1997, Nicola Bernardelli wrote:
> > >
> > > > Sad to say, I'm not replying to my own question about Air Combat
> > > > Maneuvers under Debian 1.2.4...
> > >
> > > Not yet...
> > > ...
> >
> > And not yet, but I can rebuild the binaries now...
> >
>
>
> I notice that with a workaround ACM runs fast. But it is not a clean
> solution, and together with 'xlock -mode rotor' being that slow it makes
> me wonder about possible changes to some timers (?) behaviour under
> Debian. PLEASE, give a look at the script I put as first text attachment,
> I've been working some time to write those remarks, there is a section in
> great evidence focusing the problem. The script is replicated in the tgz I
> put as second attachment, also containing the patch files used by the
> script.
>
> (Last night I also got ACM 4.8 from ftp.netcom.com/pub/ra/rainey/acm/
> and it is even a greater package to learn from, but I can't rebuild it for
> Linux yet, this time :-) it seems it is not enough going to
> /usr/include/sys/ and typing 'ln -s file.h filio.h', nor I can fix the
> -lelf test done by the configure script just with -L/usr/lib/elf.)
>
>
> Thanks to anybody getting curious about this (so far) misterious
> "timing" topic.
>
>
> Nicola Bernardelli <nbern@mail.protos.it>
> ---------------------------------------------------------------------------
> Please use <n.bern@mail.protos.it> for messages from any kind of
> robot, such as mailing lists. From that address no autoresponse
> messages will return even when I'm not at home.
> ---------------------------------------------------------------------------
>
#include <sys/time.h>
#ifndef __ONCE__
#include <time.h>
#endif
#ifndef __CPPOUTPUT__
#include <stdio.h>
#else
#include <iostream.h>
#include <iomanip.h>
#endif
void outSepar()
{
#ifndef __CPPOUTPUT__
printf("----------\n");
#else
cout << "----------\n";
#endif
}
void outTimeVals()
{
struct timeval tp;
struct timezone tzp;
double thisTime;
gettimeofday (&tp, &tzp);
thisTime = (double) tp.tv_sec + (double) tp.tv_usec / 1000000.0;
#ifndef __CPPOUTPUT__
printf("tp.tv_sec == %d, tp.tv_usec == %d\n", tp.tv_sec, tp.tv_usec);
printf("thisTime == %f (thisTime/3600.0 == %f)\n", thisTime, thisTime/3600.0);
#else
cout << "tp.tv_sec == " << tp.tv_sec << ", tp.tv_usec == " << tp.tv_usec << ';' << endl;
cout << "thisTime == " << thisTime << " (thisTime/3600.0 == " << (thisTime/3600.0) << ')' << endl;
#endif
}
#ifndef __ONCE__
void test1(int howManySeconds)
{
while (howManySeconds-- > 0) {
clock_t start = clock();
while ( (double)( clock() - start ) / (double)CLK_TCK < 1.0 )
;
outTimeVals();
}
}
#else
void test1()
{
outTimeVals();
}
#endif
int main()
{
#ifndef __ONCE__
test1(4);
#else
test1();
#endif
outSepar();
return 0;
}
tp.tv_sec == 862600662, tp.tv_usec == 691682
thisTime == 862600662.691682 (thisTime/3600.0 == 239611.295192)
tp.tv_sec == 862600663, tp.tv_usec == 691656
thisTime == 862600663.691656 (thisTime/3600.0 == 239611.295470)
tp.tv_sec == 862600664, tp.tv_usec == 691654
thisTime == 862600664.691654 (thisTime/3600.0 == 239611.295748)
tp.tv_sec == 862600665, tp.tv_usec == 691658
thisTime == 862600665.691658 (thisTime/3600.0 == 239611.296025)
----------
tp.tv_sec == 862600666, tp.tv_usec == 741701;
thisTime == 8.62601e+08 (thisTime/3600.0 == 239611)
tp.tv_sec == 862600667, tp.tv_usec == 741656;
thisTime == 8.62601e+08 (thisTime/3600.0 == 239611)
tp.tv_sec == 862600668, tp.tv_usec == 741654;
thisTime == 8.62601e+08 (thisTime/3600.0 == 239611)
tp.tv_sec == 862600669, tp.tv_usec == 741656;
thisTime == 8.62601e+08 (thisTime/3600.0 == 239611)
----------
Reply to: