If the software needs to output to 3 channels for each R,G,B this would be 760,320 changes/second.
My understanding... DMX protocol works by shipping the entire state of the lights with each packet. You have 512 channels on DMX, and all 512 are sent with each 'refresh'. I haven't looked at the protoco definition, but I've heard of one special byte that is used to start the packet. The data consists of one byte per channel -- the byte represents the intensity of the channel. 0=off, 255=full, 127=50%, etc.
So... any communication problems can instantly be corrected with the next packet of 512 channels. The packet is resilient, though not error free. this is an improvement over LOR that only communicates changes in the levels.
This means that the communication is done at a predictable/constant pace -- with little delay between channels... though I am not quite sure of that in my own analysis.
What does DMX have to do with pixelnet? I understand pixelnet to be highly-leveraged, changing timings (shorter), and the number of channels (512 becomes 4096), but the basics are the same.
The fixed channel counts give you predicable performance.
The refresh rate can be adjusted in LSP and other tools, but for Lynx the recommended (required??) rate is 50ms. So, instead of 30fps, Lynx works with 20fps. Going faster would adjust transmission timings and would introduce errors over the cable lengths used by most displays. At 50ms/20fps there is enough of an error margin built in that poor cables, or long cables will still work reasonably well. I don't know for certain that you couldn't do 25ms/40fps.
Understand too, that some installations may use wireless, and it may have its own limitations on the bytes/sec available to pixelnet traffic -- especially if 16384 channels (4 universes) are updated at 50ms... is there enough bandwidth to double the rate?
Someday I'll have to read the specs to provide more accurate responses -- but to do that would be to step over a line and make this more like work, and less like a hobby.