first post
ivos...@gmail.com
I've picked up whatever topics I have seen suitable for the FAH WIKI
and put it up, but surely it is not enough. Some pages have seen many
improvements over time, but majority of topics are still the way they
were created.
Bas Couwenberg
My problem with expanding the existing topics is that I find it very
hard to get the right aswer for the problem. Or otherwise make sure
that whatever I wish to update is actually correct.
I thought about asking someone at Pandegroup, but I think they'll get
tired of answering questions all the time, or simply don't have that
time at all.
This group might be a very good medium to discuss those kinds of
changes where the correctness of the change is not sure.
Having people from Pandegroup on this list to give an official
confirmation would rock my boat even more.
Bas
--
Disclaimer: Any errors in spelling, tact, or fact are transmission errors.
the.uncl...@gmail.com
exist as stubs, simply because the amount of time required to research
the issues is quite significant.
Maybe we need to think about how the wiki needs to be arranged with
regard to what goes in each article, as there are many which I feel
could be merged into something more descriptive and/or helpful.
A suggestion would be, that a group of us set about researching stubbed
articles to give some real depth to them, instead of being just a
simple collection of links. We could have a system where a "researcher"
chooses an individual article to work on and tries to make it as "full"
as possible then declares it complete here, where the rest of us could
then check it over etc. I know this isn't the initial priniciple of a
Wiki, but it could work whilst we fill out the articles to make them
more informative.
Any thoughts?
ivos...@gmail.com
than no topic at all. The wrong answer will get fixed and the FAH WIKI
does have content.
ivos...@gmail.com
http://boinc-wiki.ath.cx/
Clodoaldo Kakao
>
> A suggestion would be, that a group of us set about researching stubbed
> articles to give some real depth to them, instead of being just a
> simple collection of links. We could have a system where a "researcher"
> chooses an individual article to work on and tries to make it as "full"
> as possible then declares it complete here, where the rest of us could
> then check it over etc. I know this isn't the initial priniciple of a
> Wiki, but it could work whilst we fill out the articles to make them
> more informative.
>
> Any thoughts?
My suggestion is to create a page containing a list with some topics
elected as prioritary and place a link to it in the first page. The
page would declare these topics as needing colaboration.
If someone picked a topic to work on he could mark it as "taken".
I think it should be stressed that a complete and definitive topic
research it not necessary. A simple presentation where the problem is
structured/analyzed is a good start.
ivos...@gmail.com
> elected as prioritary and place a link to it in the first page. The
> page would declare these topics as needing colaboration.
>
> If someone picked a topic to work on he could mark it as "taken".
>
> I think it should be stressed that a complete and definitive topic
> research it not necessary. A simple presentation where the problem is
> structured/analyzed is a good start.
This is a good plan.
ivos...@gmail.com
consolidation and writing about. Anyone willing to take it?
Bas Couwenberg
Basically didn't do much more than clearify what was already there and
include some info form the linked topics.
Any specific thought into how a big a scope you want to set for "WUs
and points"?
I though we should include or prominently link to FAQs concerning
credit. Like I submitted a WU where are my credits?
Thoughts?
Bas
On 5/7/06, ivos...@gmail.com <ivos...@gmail.com> wrote:
>
> I think the points and stats is the topic what does need some
> consolidation and writing about. Anyone willing to take it?
>
>
ivos...@gmail.com
topic then it is very easy to do.
Surely links from various parts of the FAQs to other topics is needed.
Bas Couwenberg
knowledgeable about.
And in the process I stumbled upon the topics "Dual CPU" and "Running
multiple FAH clients per CPU".
They both cover mostly the same topic only from a different angle. The
first is just general info on the state of SMP support in F@H, the
second tells you how you can make use of your SMP system by running
multiple F@H instances, but is mostly about running multiple FAH
clients on a single CPU .
I think these topics should be merged.
I was going to ask if there is a way to find out which pages link to a
certain page, but I found that in the Toolbox while writing this :-)
Now my problem is that I'm not sure how to structure the new page. In
general I'd like to stick to the structure I used in the Stats pages,
with a general section and more detailed sections. The "Running
multiple FAH clients per CPU" page could then become a section in this
FAH & SMP page.
What do you guys think? Should they be merged or should the Running...
topic stay separate?
Andrew Schofield
Bas Couwenberg
On that page I've tried to merge serveral SMP related pages as you can
see in the note.
It is not linked to by other pages yet, because I'd first like some
feedback on it.
If you all agree that this should replace the other topics, all that
needs to be done is replace the links from the old topics to this new
one. And possibly deleted the old ones, unless they have historic
value.
I'd love to hear what you have to say.
Regards,
Bas
Andrew Schofield
Minor points, I noticed a few spelling/grammatical errors, and I think the section "Multiple Core CPUs" should really be "Multiple (Core) CPUs" because it applies to both dual (for sake of argument) cores and dual CPUs.
I could probably pad out the HT section with a few more details too.
Andrew
Bas Couwenberg wrote:
Alright guys, have a look at: http://fahwiki.net/index.php/FAH_%26_SMP
On that page I've tried to merge serveral SMP related pages as you can
see in the note.
It is not linked to by other pages yet, because I'd first like some
feedback on it.
If you all agree that this should replace the other topics, all that
needs to be done is replace the links from the old topics to this new
one. And possibly deleted the old ones, unless they have historic
value.
I'd love to hear what you have to say.
Regards,
Bas
Andrew Schofield
Nicolas Vervelle
A few remarks :
- General section: I think a little note about what is meant by
"multiple CPUs", i.e. several separate processors, multi-cores, (HT ?),
would clarify
- HT section: why "is not seen by the fah client as a dual CPU" ? It's a
little confusing IMHO, because the fah client itself doesn't make a
distinction between HT, dual core, ... it's just that on HT if the
"second" core works, the "first" will do less work.
- HT section 2nd § : add "... to generate new WUs" ?
- Running multiple clients section: add links to pages explaining how to
configure clients and add flags
- "See also:" nothing after ?
- a few spelling mistakes ;)
Nico
ivos...@gmail.com
I've seen no information what will indicate it. The v6 will likely just
add some groundwork for SMP support in the future, but I doubt that v6
will have anything SMP related in it.
Bas Couwenberg
> Minor points, I noticed a few spelling/grammatical errors, and I think the section "Multiple Core CPUs" should really be "Multiple (Core) CPUs" because it applies to both dual (for sake of argument) cores and dual CPUs.
My idea was to use the general section for the way F@H deals with
traditional SMP systems, and have separate sections for the special
cases Hyper-Threading and Dual Cores.
Dual Cores feel like a normal Dual CPU SMP system, but are confined to
a single CPU.
If that's your definition of "applies to", then we agree :-)
I think that when I extent the general section to talk a bit more
about traditional SMP the Dual Core title will be more clear. Or maybe
rename the general section?
> I could probably pad out the HT section with a few more details too.
I personally have very little in-depth knowledge of HT and I didn't
want to provide false information, especially since the HT issue
is/was such a hot topic.
I've removed the request for no editing, which first of all was not
meant for you guys, but mostly for everybody not on this list who
might have found the page through the recentchages page. I didn't want
to have to revert edits done while I was on my way home.
So please feel free to improve the HT section. :-)
I'll first research the issue a bit more before going into more
details in the HT section.
On 5/11/06, Nicolas Vervelle <nver...@club-internet.fr> wrote:
> - General section: I think a little note about what is meant by
> "multiple CPUs", i.e. several separate processors, multi-cores, (HT ?),
> would clarify
With Andrew above, that makes two change requests. I noted some
explicit examples, I think that should clear it up a bit more.
> - HT section: why "is not seen by the fah client as a dual CPU" ? It's a
> little confusing IMHO, because the fah client itself doesn't make a
> distinction between HT, dual core, ... it's just that on HT if the
> "second" core works, the "first" will do less work.
I tried to keep the talk related the traditional SMP systems with
multiple physical CPUs. Since a HT CPU appears to fake a second CPU, I
thought it should be included as a special case in the broader Multi
Processor/Multi Client context.
> - HT section 2nd § : add "... to generate new WUs" ?
Good point. Makes it more clear what they actually do with the WUs.
Consider it implemented :-)
Maybe we should link for further info the Run, Clone, Gen page, etc?.
> - Running multiple clients section: add links to pages explaining how to
> configure clients and add flags
Done. Maybe more?
> - "See also:" nothing after ?
The URL got eaten by a grue ;-)
> - a few spelling mistakes ;)
Due to popular request, I fed the content to aspell. :-)
On 5/11/06, ivos...@gmail.com <ivos...@gmail.com> wrote:
> You state that the v6 should have SMP support. Where you heard that?
Several people speculating:
http://www.google.com/search?hl=en&lr=&safe=off&q=SMP+v6+site%3Aforum.folding-community.org&btnG=Search
and specifically the speculation at:
http://forum.folding-community.org/viewtopic.php?p=84010#84010
and
http://fahwiki.net/index.php/FAH_%26_Clusters
because what I mostly just did was include the info which was already
in the other wiki pages I'm trying to merge into one (semi-)coherent
story.
I changed the wording to be more explicit about the fact that it is
still unsure when SMP support will be in the client.
When I read the Highperformance FAQ, I think v6 might not be as
probable as I first thought myself, it seems to confirm 7im's comment
in "Improvements I would like to see":
http://forum.folding-community.org/viewtopic.php?p=111393#111393
I implemented most of the suggestions and comments you all gave me.
Thanks for that feedback. As I stated before, the page is no longer
under embargo or other silly things I though up. So I hereby declare
Edit Season to be opened :-P
Andrew Schofield
--
Andrew Schofield
Bas Couwenberg
the FAH & SMP page is ready for the unwashed masses. ;-)
So I've updated the links to the old pages to point to the FAH & SMP
page, or the specific section of that page if applicable.
I left the old links in the FAQ, they are only commented out, if one
were to wish to restore the old links without have to dig through the
revision history.
Ofcourse the FAH & SMP page could use some more love here and there,
but that's the same with all the other wiki pages IMO. But all the
info which was already in the wiki is now on the page as far as I can
see.
I couldn't find a way to merge in the FAH & Clusters page, because
it's not really SMP related, only that SMP code might be gotten from
that project. So it having it's own page looks like the right thing
atm.
ivos...@gmail.com
Bas Couwenberg wrote:
> With Andews very nice addition to the Hyper-Threading section, I think
> the FAH & SMP page is ready for the unwashed masses. ;-)
>
> So I've updated the links to the old pages to point to the FAH & SMP
> page, or the specific section of that page if applicable.
>
> I left the old links in the FAQ, they are only commented out, if one
> were to wish to restore the old links without have to dig through the
> revision history.
If those old pages are merged then there is no need to have those
anymore and should get deleted. Our hands are free to make a good FAH
WIKI and we need not to tie ourselves to the old one.
Bas Couwenberg
> anymore and should get deleted. Our hands are free to make a good FAH
> WIKI and we need not to tie ourselves to the old one.
I agree wrt the freedom and tieing.
This is just my way of working. Untill I've verified that nothing else
is broken by my change, I always leave the original code in comment
above the new change.
In this case broken is not really applicable, as it is a wiki and not
some software. But if one of you guys had a major complaint about my
action I had overlooked.
It's a habit which resulted out of serveral years of programming
without a revision control system.
So unless you guys beat me to it, I'll remove the old links and pages today.
Bas Couwenberg
the new page, so that links posted elsewhere will end up at the
correct page?
Bas Couwenberg
> Thinking about the old pages. Could we set them up to be a redirect to
> the new page, so that links posted elsewhere will end up at the
> correct page?
The redirects have been implemented on the 4 pages which have been
merged into FAH & SMP
So old links on folding-community and elsewhere will not 404 :-)
Bas Couwenberg
Most of it has already been done, but it still needs work.
One of the things which needs work is the duplication of the text
about how the clients deals with deadlines wrt reissuing WUs. At the
moment I can't come up with a good way how it should be structured
and/or worded.
Another work needed item are the Client/WU errors. There are several
pages about errors which could/should be merged. And possibly even
into the WorkUnits page, but I'm also unsure on the right way to do
this.
Any thoughts?
Bas
ivos...@gmail.com
Bas Couwenberg wrote:
> I've been merging wiki pages on Work Units into the WorkUnits page.
> Most of it has already been done, but it still needs work.
Good work.
> One of the things which needs work is the duplication of the text
> about how the clients deals with deadlines wrt reissuing WUs. At the
> moment I can't come up with a good way how it should be structured
> and/or worded.
>
> Another work needed item are the Client/WU errors. There are several
> pages about errors which could/should be merged. And possibly even
> into the WorkUnits page, but I'm also unsure on the right way to do
> this.
Client/Core error pages are too cryptic/confusing for meaningful
merging. I think they should remain separate.