I ended up with one of the big ones succeeding, so it appears they do not all fail.

BETA_ erag_ a172_ ps0000_ 2

I agree to the relaxed bandwidth limits as long as its not 56k dial-up. Tighten up the hardware spec though - low DCF should be best. Type A eats a lot of memory so if the computer is not a dedicated cruncher, trouble awaits.

@X-files 27: I think the Type As don't need so much physical memory (220MB ea) as virtual memory (page/swap file) (1.3GB ea).
And I think the virtual memory is not accessed very often. While my 2nd WU was running, there was no noticeable increase in my disc activity. Total page faults, which I assume is a proxy for accesses to system cache/page file, got to 60000 early on, and when I last looked, at about 50% done, it had crept up to only about 65k. For the first 11min, until my 1st WU got error 29, my quad was running 2 Type As plus 2 other WUs (HCC and/or FAAH) in 2GB physical memory, which is less than the 2 x 1.3GB VM needed by the 2 Type As alone.
I have limited knowledge of current virtual memory/swappping characteristics though. For example, I recently discovered that 32- and 64-bit Windows XP may not handle swapping between WCG tasks beyond physical but not pagefile memory, properly. Suspended tasks can get killed with exit code 0. BOINC silently restarts these from checkpoints when need be, so the problem is usually hidden.

@Sek: (Quote):"OT, but can you expand on that last paragraph" - OT?
Scenario: Quad with only 1GB memory, waiting for return of 2x1GB sticks from RMA. LAIM is ON. Running FAAH + HCC.
I like to keep an even mix of the 2 running, so I micromanage when I'm around, which means suspending & resuming tasks. WTR tasks have absolute priority over RTS, so I grab next-to-run WUs by starting them, running them for a short while, then resuming previous tasks. This goes OK while starting a new WU, and while it allocates itself memory about 2min into the run. (At this point, BOINC Progress moves off 0%). However, when I then suspend the new task to resume a previous one, there is the likelihood that all suspended tasks will be spat out, even though Task Mgr Commit Charge is well below Limit. The tasks will disappear from Task Manager, and BOINC Messages will suggest resetting the project, but they will stay unchanged in BOINC Tasks list. When they resume, they will start from 0 CPU time in Task Manager, but from the checkpointed time (I asume) in BOINC. Only tasks that were suspended very near the start, restart from 0% in BOINC.

Workaround: Suspend the next-to-run WUS after only a few seconds, before they start grabbing lots of memory. They stay in their original spot in the Tasks list where I may not notice later that they are WTR, though.
This workaround may not work for DDDT2-Type A, because these go to 170MB at or very close to startup.

Is there any word on when/if the errored wus will be resent? I see some of my results have other wu's in the "waiting to be sent" status.