severity 696138 wishlist
thanks
Martin Pitt dixit:
>>From IRC ping:
Thanks for following up on this.
>[19:18:02] for example, on my box, the script timeouted just beforee the db
>came up successfully
Actually, that was while doing a build in parallel, so it should
probably finish within 45s or less on normal activity.
>This needs some thinking as I don't quite like a complex arch →
>timeout lookup table, but more than a minute is quite excessive on
>architectures which are realistically being used as a database server.
Right, but this is not necessarily about being used as a database
server. Sometimes, it’s about availability, or even installability,
or just for testing purposes. Currently, an apt-get install can fail
because the automatically generated main cluster doesn’t come up, even
if it does.
Instead of a complex lookup table, how about something like a positive
list of architectures for which to take 1 minute, and 3 minutes for all
others? Just increasing it to 2 minutes for all might be possible or not
desirable, depending on your choices… probably about having fast(er)
feedback.
Hm.
There *are* slow i386 boxen, too. How portable is something like this:
root@aranym:~ # fgrep -i bogomips /proc/cpuinfo
BogoMips: 191.89
Considering linux_logo parses that… possibly not too much. :(
Apparently, parsing /proc/cpuinfo for bogomips/BogoMips/BogoMIPS
is enough on all but SPARC which also does an fnmatch on
"Cpu[0-9]*Bogo*" there; the remainder of the line appears to
be the float value in all cases. (This from looking at the
linuxlogo source code.) Where “all” are the Linux architectures
alpha amd64 arm avr32 cris frv i386 ia64 m32r m68k microblaze
mips parisc ppc s390 s390x sh3 sparc vax. On kfreebsd and hurd,
it probably counts the delay loop itself…
Then, there’s pystones. The default run of them is 10'000 times,
which is a bit much for us. 100 runs is almost immediate even on
m68k and could be used. Or maybe 500. 500 runs go through in a bit
more than one second wallclock time on the example box, which is
faster than many m68k boxen though.
root@ara2:~ # python -c 'from test import pystone; pystone.main(100)'
Pystone(1.1) time for 100 passes = 0.08
This machine benchmarks at 1250 pystones/second
On the other hand, on a Celeron 2.4 GHz (those with 64K cache in
total…) 100 runs gives nothing:
tg@frozenfish:~ $ python -c 'from test import pystone; pystone.main(100)'
Pystone(1.1) time for 100 passes = 0
This machine benchmarks at 0 pystones/second
tg@frozenfish:~ $ python -c 'from test import pystone; pystone.main(500)'
Pystone(1.1) time for 500 passes = 0.02
This machine benchmarks at 25000 pystones/second
A 6200 bogomips amd64 machine is even worse:
root@tglase-dev:~ # python -c 'from test import pystone; pystone.main(100)'
Pystone(1.1) time for 100 passes = 0
This machine benchmarks at 0 pystones/second
root@tglase-dev:~ # python -c 'from test import pystone; pystone.main(500)'
Pystone(1.1) time for 500 passes = 0
This machine benchmarks at 0 pystones/second
root@tglase-dev:~ # python -c 'from test import pystone; pystone.main(1000)'
Pystone(1.1) time for 1000 passes = 0.01
This machine benchmarks at 100000 pystones/second
The time needed to run 1000 pystones is already very noticeable.
One way could be to run the pystones once, at postinst time,
and cache the result.
Another way could be to try with 250 first (possibly not more than
two seconds even on slower m68k and avr32) and then retry with 10000
if the value read is 0 pystones/second.
Then define a cutoff.
Or just ignore this problem, which is also valid. I’ve lowered
the severity. This may be something for when bored…
bye,
//mirabilos
--
<hecker> cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht noch 3 Jahre warten können? <mirabilos> bis dahin gibts google nicht
mehr <hecker> ja, könnte man meinen. wahrscheinlich ist der angekündigte welt-
untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum
müssen die die doodles vorher noch raushauen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
