Primenet web design

[blip]

Originally Posted by Madpoo

I *think* that's the only page where I added the full-width borders to each sub-section... I don't know why exactly, but I think it helps the sections stand out better... they act as kind of a proxy for a table title, for example, since the tables are full width as well.

White space gets you a looong way towards making sections stand out. There is a fair amount of expertise around that in (old school, physical) typesetting and typography. Mathematicians get a feeling for that as soon as they start using TeX/LaTeX.

Originally Posted by Madpoo

Eww... I'll have to disagree with you there. :) I like tables with borders unless the table is just being used as a layout shortcut. Am I just old skool on that? Maybe?

Well, old school can be seen in pre-internet printed books. A good guide to table design can be found here.

Originally Posted by Madpoo

It doesn't *add* anything, but it's kind of cool and, no pun intended, it does make the graph pop out, visually. Now I"m thinking the bar chart for work types should also be 3D. LOL

Ockhams's razor applies here as well: If you don't need it to make a point - don't use it! On the other hand: If there is some important/interesting point to be made, make sure it pops out when you prepare the visualisation.

[chalsall]

Originally Posted by Madpoo

I honestly did try to keep some things as-is, especially in the manual result/manual assignment pages, if I had a good reason to think GPU72 in particular might be keying off certain things, but even then, it was just a guess on my part. For GPU72 at least, I figured it was using URLs to get work and read the output which I didn't change at all, and for checking things in, the submit button is moved now but it shouldn't care if it's just submitting the form through a script.

Thank's again for your work Madpoo. Just popping in for a moment, then have to get back to "real work" (sorry for the high-bandwidth below)...

1. The only thing which broke any of GPU72's spiders was the removal of the "You are visitor number" string (which I was stupidly using to ensure the full dataset had been brought down. A simple fix).

2. So you know, GPU72 only reserves and unreserves work, it never submits work (except via the Proxy, but that's entirely Worker/Client to Primenet).

3. With regards to exposing data via XML, that would be really (really) cool! Personally it would help me if the data contained on the thresholds page was made available thusly ASAP. Perhaps use this as a test? ( )

3.1. I haven't yet had time to write a parsing spider for that data, and it affects the GPU72 "Manual Reservation Spider" (which reclaims candidates at below 74 when we can handle it, and releases candidates at 73 iff needed).

3.1.1. Somewhat embarrasingly, I thus have to manual view the above page every few days, and update the value for the "Cat 4 cut-off" in my database ("Never send a human to do a machine's job...").

Kindest regards to all.

[Madpoo]

Originally Posted by chalsall

Thank's again for your work Madpoo. Just popping in for a moment, then have to get back to "real work" (sorry for the high-bandwidth below)...

3. With regards to exposing data via XML, that would be really (really) cool! Personally it would help me if the data contained on the thresholds page was made available thusly ASAP. Perhaps use this as a test? ( )
...

We'll probably have to figure out how you'd want the data (and to make sure I actually understand which parts you're looking at).

For example, today's #'s represented one way (and I'm just doing a FOR XML query in the db itself) would be:

<DailyLimits type="1" date="2014-10-06">
<num_exponents>1500</num_exponents>
<limit_exponent>33474272</limit_exponent>
</DailyLimits>

There are 6 limit types... limit type 1 there is that first double-check section... the num_exponents and limit_exponent are maybe what you're interested in?

Format aside (I haven't explored the relationships of that data to anything else), is that the kind of info you're after?

[chalsall]

Originally Posted by Madpoo

Format aside (I haven't explored the relationships of that data to anything else), is that the kind of info you're after?

Yes.

[Madpoo]

Originally Posted by chalsall

Yes.

Okay, give this a try... I just ran this manually, so it's not set to auto-update yet or anything. If the format looks cool we can have it update at the same time that the data itself is being updated (it runs on it's own schedule @ 23:20 UTC currently).

http://www.mersenne.org/thresholds/thresholds.xml

The types 1, 2, 3, 11, 12, 13 correlate to:
DC thresholds (1, 2 and 3)
LL thresholds (11, 12 and 13)

I could add a text field to briefly describe each thing, like:
1: description="DC completed in < 60 days"
2: description="DC completed in 61-100 days"
3: description="DC completed in 101-240 days"
..
11: description="LL completed in < 90 days"
12: description="LL completed in 91-150 days"
13: description="LL completed in 151-270 days"

etc. But that's just describing what the website already says, and that's probably a better place for anyone wanting a better understanding. If George ever changes those, he wouldn't have to update the query that spits those out as well. :)

[snme2pm1]

Originally Posted by Madpoo

According to the source of those graphs, it's a measure of the GHz-hours for the past 24-hours and 90-days.

It should probably be labeled on there

That doesn't sound right. Is it wise to believe everything you read!
I understood the measure to be relative to registered equipment deemed capability, up to 100%.
However for many folk lodging GPU work results the red needle is persistently banging hard against the upper stop with figures in the thousand and more percent, though nowhere is there any hint as to what full scale 100 means.
The recently added title "GHz-Hours for 24 hours and 90 days" doesn't seem to serve well.

[Madpoo]

Originally Posted by snme2pm1

That doesn't sound right. Is it wise to believe everything you read!
I understood the measure to be relative to registered equipment deemed capability, up to 100%.
However for many folk lodging GPU work results the red needle is persistently banging hard against the upper stop with figures in the thousand and more percent, though nowhere is there any hint as to what full scale 100 means.
The recently added title "GHz-Hours for 24 hours and 90 days" doesn't seem to serve well.

Oh...well, I don't know what the heck it is apparently. :)

I skim read and saw like "ghzhrs_last90d" in the code that generates the graph... upon closer reflection, there's more. That's just the dividend to the thing. If it were *just* that, I'd be right. :)

The divisor there comes from a SQL function that I'd have to explore and see where it gets that # from. If there's a chance for that to exceed 100% then it's not working as designed and there's no use labeling it right now anyway.

I removed the (wrong) text I put there for now.

[James Heinrich]

Originally Posted by Madpoo

If there's a chance for that to exceed 100% then it's not working as designed and there's no use labeling it right now anyway.

It most certainly can exceed 100%.
Primenet (thinks it) knows your expected daily throughput based on all the registered machines you have and past performance.
It gets totally thrown by manual results from GPUs because it knows nothing about them (they're not registered CPUs). Not to mention that GPUs tend to put out a lot more GHz-days than CPUs.

[chalsall]

Originally Posted by Madpoo

Okay, give this a try... I just ran this manually, so it's not set to auto-update yet or anything. If the format looks cool we can have it update at the same time that the data itself is being updated (it runs on it's own schedule @ 23:20 UTC currently).

Why, that's rather sweet darling (or is it sir?).

Either way, thanks. That can possibly work.

[snme2pm1]

Originally Posted by Madpoo

I'm updating the dates as I find them... I hadn't considered doing that as part of the update but now that you've pointed it out, it's kind of obvious.

It's great that you're ready to tackle those inconsistencies, and that some places have already been brought closer to iso. Thankyou.
Lot's more to pick through...

Originally Posted by Madpoo

as far as putting the UTC timestamp somewhere... maybe you're the one who asked previously, but I never could figure out a good spot for it. It's probably not super helpful to most people,

Must have been someone else.
There may be another subtle purpose for that timestamp that has been overlooked.
It provides an indicator of timezone that tends to make repeat of such indication redundant at every date/time. Indeed some pages like Account->Results, http://www.mersenne.org/results/, can have lots of times, but the timezone is not mentioned at every table row, nor need it be in a heading row if such is made plain by other means.

I note that mersenneforum.org for an unauthenticated user states at page bottom something like All times are GMT. The time now is 20:57., and for an authenticated user something like All times are GMT +11. The time now is 08:01.
I am not suggesting that mersenne.org similarly vary it's output to the local time of an authenticated user, but the point I'm making is that having clearly established the timezone once on the page it then becomes redundant to anywhere else duplicate that signal. Potential for space saving in some headings (especially tables) also.

[Madpoo]

Originally Posted by snme2pm1

...though nowhere is there any hint as to what full scale 100 means...

Here's where that # comes from (the divisor in that percentage):

potential ghz hours in a 24-hour period = sum( p4_cpu_speed_mhz * cpu_processor_cores ) * 24.0 / 1680.0

GHz_days are based on a single core of a hypothetical 1GHz Core 2 Duo. The Core 2 architecture is worth 1.68 times the P4 architecture. Thus to convert from p4_cpu_speed_mhz to potential_ghz_days divide the P4 MHz by 1.68 to convert to Core 2 architecture and divide by 1000 to convert to GHz.

So let's say I have a system with 12 physical cores at 3.066GHz. My particular P4 cpu speed in MHz for that system is 7073 MHz per core. The "P4 CPU Speed MHz" comes from that particular system's "rolling average" which, right now, is 2307 * the actual core speed 3066 MHz. And since that rolling index is a measure compared to 1000 for a P4, we divide by 1000. Altogether now, 3066*(2307/1000) = 7073.

You can find your own rolling average in your machine's local.txt file in the Prime95 directory, e.g. "RollingAverage=2307"

So my "potential" GHz-Hrs / day equals the sum of all my individual machines indexed speed*# of cores, * 24 hours, divided by the magic fudge factor 1.68, and divided by 1000 to go from MHz to GHz because machines are faster than they used to be. :)

For the one machine in my account, I get (7073*12) * 24 / 1680 = 1212 GHzHrs/day. (It's a bit more in reality because I also have my v4 migrated info showing up in there, but it's a pittance).
=============================

Clearly this all wouldn't hold true for GPUs; they're definitely going to be returning far more results than that "potential GHz" would suggest, if GPUs are even counted in the database the same way in the first place, like CPUs are.

It seems like some apples/oranges going on, and it may be more interesting to see some kind of 30/60/90 day rolling averages or something or just a chart of GHz-hours over the course of a week or two like I mentioned. That wouldn't require any guessing or pre-knowledge of the systems in use, it's more results oriented.

If you had a farm of just CPU work, it could be useful to see the % of output you get compared to what it could be... if you have machines turned off at night or weekends, then your total throughput would be reflected as, for example, 50% of total capacity. But that's only true for the long term 90-day view... the 24-hour dial might not be as interesting if you only have a few systems/cores doing work.

On the other hand, Curtis' account must be pretty interesting since there would always be something going on, results being checked in pretty regularly, or the larger team accounts.

I hope that helps everyone. I know *I* just learned a lot about all of that by digging through and figuring out what's what.