The lag in this game seems to be systemic

6 Mbit is all I get for my downstream speed, so 6mb - whether you mean bits or bytes - far from fine for me. The difference between this and SupCom's networking model, peer-to-peer lockstep, is that the latter only sends user inputs - which remain more or less constant over time - while the former has to send all game-state deltas 10 times a second.
I am honestly amazed at you not being able to spot the difference in bandwidth consumed. Sure it is amazing from a technical viewpoint and even from a gameplay one. But only if you are blessed with the kind of bandwidth that is hard to come by outside of the bastions of modern civilisation.

I was referring to mega bits.... And 6 mbit down is sufficient for pa (as that is what I play on when away). Remember that pa is limited to 2mbit anyway at uber's end.

One thing I have discovered, I can't play using WiFi. So for that 6mbit connection to be usable I have to connect to the router with a cable. Also note that when I'm at home I have a 30 mbit cable connection and it isn't any faster. I think people assume allot due to it being client server however bandwidth usually isn't the issue (perhapse their self imposed 2mbit cap is?)...

You should check your WiFi, your throughput seems far too low even for a lowly 54Mbit/s connection operating at around 10% connection quality.

I see what you are getting at, though, and of course you are right given the current baseline for PA games. The thing is, though, that the client-server approach scales very poorly for both increases in game size and player number, and most jarringly: observer number. Peer-to-peer on the other hand scales very poorly in those cases only if (additional) players hit their performance cap well before the others.
So colour me very interested in PA's network performance when having to deal with tens of thousands of units, dozens of players and hundreds of observers, especially in conjunction with the possibility to join a live game.
A detailed explanation by a developer regarding this topic would be nice, actually.

Very true, I think regarding the WiFi that the problem isn't one of bandwidth, but latency. I've found some games run silky smooth, and others 'lag' with very little going on even on my 30-mbit connection. Now Uber assign a server per user with a certain amount of bandwidth and dedicated resources so really games shouldn't randomly lag like this. I think latency might be just as important as bandwidth in PA's case as all the user commanders are being interpreted and acted upon by the server before being sent back. I don't think any of the stat screens show ping to the server but I'll bet that might be high in games that inexplicably lag even at the start.

Interesting point you raise there! We will see how it pans out in the long run. Client-server has been communicated very clearly as the architecture of choice so I knew what I was signing up for. There still remains an academic interest in the whole subject matter, though.

Since Uber uses the TCP protocol, rather than the UDP protocol, packet loss can be a serious lag inducer. In TCP, if a packet is lost in transit (common enough), the client re-requests the packet, and has to wait for it to arrive. This can be very slow, and when connected by a bad wifi connection, packet loss goes through the roof, which can cripple transfer rates.

UDP however would be problematic itself, and it would be very easy for a game to fall out of sync when packets are lost.

Packet loss and latency, 2 of the scariest monsters gamers talk about when gathered (indoors) around their simulated camp fires....