Related to: #96

This is still an open ticket (the last one seems to have been buried), and I ran into this same issue today.

Using the current version of the FTB Infinity Evolved pack.
Current AE Version: rv3-beta-5
Current Forge Version: (Forge Mod Loader version?) 7.10.99.99

My example setup:
http://imgur.com/a/uYtpE

Adding enough materials to craft 32, or even a stack of the product, lets it run again. Base cause of issue seems to be that acceleration cards make the system ONLY craft in specific-size batches; it won't attempt to craft say, 10 of an item if it has 3 acceleration cards in it.

you mean, adding acceleration cards to an crafting card in export busses shall increase the amount of items crafted in parallel ... sounds like a good idea to me ;)
do you probably have an idea for the capacity card too? as it needs an usage in this scenario too, don't you think?

Well, to my understanding, co-processors allow a crafting storage to craft more things in parallel. This is not quite the same thing. Seems more likely a bug.

The following is the closest I've come to understanding the mechanics behind it, without actually digging through the source code:
Lets say export busses push out 1 item every time they run. Adding an acceleration card makes it push out 16 items every time it runs. 32 with 2, 48 with 3, and 64 with 4.
EDIT: I tested it, and the numbers are: crafts 8 at a time for 1 accel, 32 at a time for 2 accel, and 64 at a time for 3 accel.

The issue is that, when it is crafting-while-exporting, it will ONLY push items out in those amounts. So say you have enough items to craft 10 chests, and the export bus has 3 acceleration cards. It will try to craft 64 chests to push into the inventory, but it won't have enough materials, so it won't craft any chests to push into the inventory until it gets more materials.

Ideally the number of acceleration cards would limit the max amount of items moved at a time, and not the minimum number of items moved at a time.
This only occurs when trying to craft something via export bus. Normal export of items into another inventory works without issue (It will export 10 of 1 item in a 4-acceleration card export bus)

oh so i misunderstood, sorry XD maybe i took it out of context because of the original idea
by "parallel" i meant like you described ... just bad wording from me

A crafting export bus is just behaving like a player. If you want to craft 32 Chests as a player the system will also stop you from crafting since the required material are not satisfied. There is a suggestion to rewrite the crafting engine though to support this where it suggests the player if he still wants to craft 30 chest at least.

Rewriting is not really feasible thanks to how minecraft crafting work. Especially with container items.

Without them we might be able to convert it into a 2 (or more) pass system, construct the crafting tree by using the patterns and in a second pass validate it against the network inventory. It would add some overhead as the validation can cut of whole branches when there are already enough items around. But we are still mostly in a O(n) (depth of the tree/distinct crafting steps) or O(1) (things like the amount to craft) and even with ridiculous complex trees, there probably will not be more than a few hundreds for N.
And it would actually replace another bottleneck of O(n log n) (or more) with n being the amount of types stored in a network with something along the line of O(n) and n being the distinct item types used in the crafting tree (certainly less then all existing item stacks)

But container items (buckets, tools with durability and such) simply break it. They change most calculations from O(1) to at least O(n). It is no longer multiply by amount requested, now it has to calculate 1 step per crafting operation. Request 10 items, it has to simulate it 10 distinct operations instead of 1. Request 10000 and it is 10000 instead of still 1 without container items.
And without doing a full calculation, we cannot predict the outcome. So we have to recalculate it until we found how much we can craft. We might get lucky and there are enough materials to craft 9999 items from the requested 10000. Or extremely unlucky and can just craft 1. So we have to rerun the calculation 10000 times. So pushing the current worst case of O(n) to at least O(n^2). Also in terms of space complexity it is really bad. Non container based ones are O(n) with n being the amount of distinct crafting steps. So crafting 10000 planks from logs would still be 1. With container items it would be 10000. There are already a few certainly broken recipes using this approach in a recursive way. Something like tiered items with 8^n as total items needed, which can already kill servers.

There are some solution like use something like a binary search for it. But that will still turn the worst case of O(n) into at least O(n log n). So it would certainly make the worst case more worse and also the normal cases a bit more worse (~O(log n) instead of O(1) when missing items)

So it's the way it is, for performance reasons?

You'll never have an n value of infinitely large amounts though with a crafting-export bus. At most it can do 64 items. It already has to calculate how many of a given item it can export for normal exporting-mode (checking 1 through 64)