We have set the memory requirement for this project high for a number of reasons. One major reason is that machines with lower memory (even on linux) do not have a VM (Swap) space that can handle the allocation that is required by this application. I have many machines in my lab that have less than 512 MB of memory and they struggle with this application. And don't get me started on the P2 machine in my lab :)

Please remember that the purpose of running WCG is to have it run in the background as much as possible and not affect the member's normal computer usage.

Sek, for your memory message. Here is an example from my older machines.



-Uplinger

(note: for those not sure what P2 is, that's Pentium 2, still running)

Thank you Uplinger, here is for the French speakers

Sur le Forum Grid-France
Merci Uplinger, voici pour les Francophones

Type A ("ps"): Ces unités de travail sont les très longues.
Temps de calcul: 30-100 Heures
Quantité: Environ 36,000 WUs
Download: ~20 MBytes
Upload: ~2 MBytes
Identification (les premières lettres du leur nom): ps
Résultats: Chaque WU type A Créés 2 WUs type B: (Une "se" et l'autre "pe")
Checkpoints: 50 fois durant le calcul de l'Unité de travail. Environ tous les 2% d'exécution.

Type B ("se" ou"pe"): Ces unités de travail sont plus rapides avec des points de contrôle très fréquents.
Temps de calcul: 5-10 Heures
Quantité: Environ 72,000 WUs
Download: ~2MBytes (se) or ~20MBytes (pe)
Upload: ~2MBytes (se and pe)
Identification: se, pe
Résultats: Chaque Unité de type B créé environ 250 à 350 Unité de type C
Checkpoints: A une fréquence d'environ 10 secondes, et en fonction des préférences de projet du profil

Type C: Ce type d'unité de travail représente la plus grande partie du travail à faire.
Temps de calcul: 1 à 5 Heures
Quantité: Environ 22,000,000 Unités de travail.
Download: ~2MBytes (sq, sd, sr) or ~20MBytes (pq, pd, pr, pc, pl)
Upload: < 1MBytes
Identification: pq, pd, pr, pc, pl, sq, sd, sr
Résultats: Ceux-ci sont l'étape final. Les résultats sont envoyés aux chercheurs
Checkpoints: A une fréquence d'environ 1 minute, et en fonction des préférences de projet du profil

Ah, so it's guesswork. A machine with 256MB RAM could easily have 1GB or more of swap space.
e.g. Here's a snippet of top output for a worse example than DDDT2:

Cpu(s):100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    255948k total,    38168k used,   217780k free,     3628k buffers
Swap:   979924k total,        0k used,   979924k free,    18448k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2299 root      25   0 1025m  244  192 R 99.9  0.1   4:51.51 worsethandddt2
 2320 root      15   0  2228 1096  856 R  0.3  0.4   0:00.07 top
...

Even as things stand, DDDT2 will run on a 512MB machine with 256MB swap. However, if you are worried that some machines will not have enough swap configured in order to be able to start the process, why not remove the declarations of unused variables (amounting to about 348MB) from the executable? Then you could even reduce the requirements to 256MB.

So now that some type A's have been validated, does that mean some type B's have been generated (anyone have any?) Or is there some delay (Do all the type A's have to be complete?) before the type B's become available to download?

Just curious how the timing works.

Somewhere -Uplinger mentioned the A types were sub-divvied in groups of 25 [else we'd be waiting till St. Jude.]