Yes right. Perhaps I should have been more detailed in my question! ;)
I'm interested in trade-offs between package frequency and size being made nowadays in production grade real-time multiplayer games, and what bandwidth and latency game developers assume/require the players to have.
In the MMO I'm working on I'm currently sending world state updates in the range of 1-5 kb, 5-10 times per second. It's a strategy MMO and as such doesn't quite have the precision requirements of an FPS. But I have yet to write a more advanced package splitting and data compressing logic. I don't know if that is likely to be necessary so I'm curious at what others are doing regarding network IO performance.
1 kilobyte per packet, 5-10 times per second, per player, sounds like an order of magnitude too much for a first-order approximation. Then again, if it enables gameplay that you really want, and you (and your players) can provide that bandwidth, then it might be fine.
In general, the "fast action" games on consoles trend towards sending fewer packets with better prediction -- although "fewer" in that case might mean 15 per second. Each packet is usually tiny, though -- a few hundred bytes, at most.