Skip to Content.
Sympa Menu

sm-discuss - RE: [SM-Discuss] Benchmarking Spell?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Phil/CERisE/KG6MBQ <cerise AT littlegreenmen.armory.com>
  • To: Reapl Paratorn <reapl AT reapl.net>
  • Cc: "'sm-discuss'" <sm-discuss AT lists.ibiblio.org>
  • Subject: RE: [SM-Discuss] Benchmarking Spell?
  • Date: Mon, 5 Aug 2002 01:35:14 -0700 (PDT)

Reapl Paratorn said:

> I wasn't saying we didnt need the reboot. I was just saying I didn't know if
> we should currently write a spell to have it automatically kick off the
> performance of a test on a reboot when any disk cache would be free.
>
> I thought the startup/init stuff will exactly work is still being defined so
> instead suggest this cludge of a spell that had two steps.

It could get plugged into an rc.local-type script. That's a
Slack-ism though.
It seems like the sort of thing which could be potentially useful.
If M$ starts making linux software, I'm sure they'll make heavy use of
it ; )
I figured it might be nice when one rebuilds a kernel, but I have
preemptory bad feelings about that.

> One make sure the file areas on the disk are clean, but not execute test.
> Then on next running the files wouldnt be found so ask the user if they have
> rebooted and if they say they have then perform the test.

That could be done by doing everything in a temporary
directory/mount point. That's part of cast. Don't sweat that.

> Maybe the first step should more correctly be something like summon source
> and execute a clean on it so there is clean source. Then tell user to
> reboot. Then have second step from above. Again reminding user to make sure
> they have rebooted to clean the disk cache and only doing test when they
> confirm they have.

Well, ideally, we aren't necessarily going to want this to run all
that often. All a benchmark spell should be expected to do is:
1)reboot
2)summon a test tarball
3)cast it (which should clean up after itself)
4)display time
After that, it could be run arbitrarily.
I'd suggest a nice readable option for which tarball to summon &
cast.
I'd also suggest in the interest of presentation that the
information is stored and applied to determine how long other things
will take to compile. We could start putting in progress bars which
(l)users will curse at when they're 50 minutes off or some such. 8)
Also, to clarify, the first listing in time is 'wall' time. I don't
know who started that term, but I hate it. Real time is so much better
8)

-Phil/CERisE/KG6MBQ





Archive powered by MHonArc 2.6.24.

Top of Page