In FBA emulation which ggpo uses, PPP inputs seem like they will always have a small random chance to fail when done manually and without a PPP bind. The reason is that all 3 punches must be input on the same frame, and the detection method used by the emulator is to simply poll the button states at every frame start.
This means that if you input lp, mp in the middle of the frame and then hp right after the polling occurs, you will not get the ppp input even if your inputs fall within a 1 frame window.
Visual example where you get credit for a ppp input:
0 1 2 3 4
|--------|--------|--------|--------|
| | lpmphp | | |
|--------|--------|--------|--------|
Visual example where you do not get credit for the ppp input:
0 1 2 3 4
|--------|--------|--------|--------|
| | lpmp | hp | |
|--------|--------|--------|--------|
If your input falls right before a frame is polled by the emulator, then a < frame delay in your hp input can cause the ppp input to register.
If an input poll occurs every ~16.67 ms, then that means a 4ms spread between your first punch input and last punch input is a ~24% chance of failure. A 1ms spread is ~6% chance of failure.
Anyone that is human will almost always fail when attempting to input ppp 100x in a row. Even though it is actually very easy to input ppp within ~16.67ms, the input detection requires an almost 0 ms spread for a near 100% success rate. Even if someone could hit the input with only a 1ms spread, they will faill 99.8% of the time if trying to attempt the input successfully 100x in a row.
Does arcade ST behave similarly in detecting inputs? Is this just a fundamental flaw in the input system since arcade that will randomly drop ppp/kkk inputs?
Note that this problem seems to be exhibited in any emulated game where two or more buttons need to be input simultaneously on the same frame.