I’m not sure I completely understand what you’re asking here, but let me suggest a few things that might be relevant.
In general, we tend not to get specific about overall “speed” because there are just so many variables involved, including network traffic and which I/O modules you have plugged into a rack – just to name two.
When you say: “high speed reactions to a process” the first thing that pops in my head are the Event/Reactions one OptoFan raves about in this post.
Also, as Ben mentioned in this post, if you can have all your logic on that same R1, that’s the most efficient and takes the most advantage of “distributed I/O.” After you’ve done the high-speed process stuff, then you might report back to a master S1 about how many widgets were built or whatever.
Another thing folks overlook sometimes is the speed of the module itself. There’s no point in grabbing information from a module faster than the module itself can update. Check your specific modules specs for numbers like these:
Also, depending on what you’re doing on your R1, there are options in the memory map to turn off your analog scanner, digital scanner, and even the control engine (or any combination). Search for “scanner flags” in form 1465. Turning off what you’re not using can free a few more CPU cycles up for what you are using.
I think you’re asking about SoftPAC too, which is primarily going to help folks who’d like faster speeds for the logic itself (especially math and string processing), more charts, and more room for storing data in memory and in files. Since it’s running under Windows, when you communicate with another PAC like an R1 or S1, it’ll be through the Windows TCP/IP stack which has, well, limitations. Don’t get me going on that topic!!
There are a couple other considerations when you’re trying to eek out faster performance, but I think that’s a good start for now. Do you want to give us more details about what you’re trying to speed up, exactly?