pygame and socket.recv

[Aaron Brady]

On Apr 2, 1:19 am, "Hendrik van Rooyen" <m... at microcorp.co.za> wrote:
> "Aaron Brady" <cast... at gmail.com>  wrote:
>
> > Hi,
>
> > I tried writing a small game on a pygame layer.  The graphics are
> > fine, and at the moment, it is not graphics intensive.  It is multi-
> > player, and for the communication, I am sending a pickle string across
> > a LAN, once per frame.
>
> How big is this pickle - i.e. how many packets does it translate to
> on the wire, given that an ethernet packet is less than 1500 bytes?

The client sends a dictionary to the server.  If it doesn't have any
news, it's an empty dictionary, ~10 bytes.  If it does, it's one or
two entries, a short string to a short string or integer, ~40 bytes
total.

The server sends a dictionary back: { str: str, str: num, str: { int:
X, int: Y, ..., int: Z } }, where X, Y and Z are the dictionaries it
received from the individual clients, ~100 bytes total.  I don't
anticipate this number growing past 1K at later stages in the game,
and I can always make it a fixed-length struct or CSV.

> What is the maximum number of full size packets that a simple
> echo server will echo per second on your setup?  I predict that
> you will find that this is far less than what a calculation based on
> the bit rate will suggest...

The test on localhost->localhost and back reached 700 cycles per
second.  The test on localhost->other machine and back ranged 100-300
cycles per second, IIRC recently.

> > I'm observing some latency.  It seems that socket.recv isn't
> > performing consistently.  The server is using time.clock and
> > time.sleep to keep the frame rate at 40 frames per second.  Latency
> > occurred regardless of whether the connection was ethernet or
> > wireless, although worse with wireless.
>
> What does "some latency" mean? - barely visible jitter, or a half
> second freeze?

I've got a rather amateur loop keeping the frame rate capped at 40
fps.  The game won't exceed that, but when it drops /below/ it, it can
fall to 30 or 20 or 15 fps.  That was just a per-second averaging
calculation; the bad freezes are about half a second.  I'll try to get
a reading of individual calls to 'recv' that are themselves below the
threshold.

Here's the loop: wait half the time left, then half that, then half
that, and so on, until less than 1/1000th second is left.

        while 1:
            tcurr= time.clock( )
            delay= ( ( tprev+ secsperframe )- tcurr )* 0.5
            if delay< 0.001:
                break
            time.sleep( delay )
        tprev= tcurr

I don't know if it could be responsible.  Would a mutex or Queue be
better using a threading.Timer?

> What do you do when the total round trip time takes longer
> than your target of one fortieth of a second?

I want to know that too!

> The fact that wireless is worse (54Mb/s? - down from 100Mb/s)
> makes me think you are running out of bandwidth, or that the
> LAN is busy and that the bandwidth is wasted on collisions.

Another party (friend, participant, colleague, etc.) and I tested it
with wires.  It improved it, but didn't eliminate it.

> What happens when you drop the frame rate to 20 per second?
> (it is parameterised, isn't it?)

Yes.  It still gets half-second freezes, and the aggregate per-second
average still reads as low as 15.  Yes it's parameterized, in the
'secsperframe' variable, seconds per frame, or fps**-1.

> > Does anyone have any hints or suggestions?  I am on Windows XP.
>
> What else is running on the machines at the same time? - your game
> may be sucking at the hind tit of processor time...

On one test, one machine ran only the server, and the other machine
ran only one client!  That is where the numbers I gave were
generated.  When one machine runs a server and a client, it's not much
worse, though I didn't try that since I moved the delay loop to the
client side.

Thank you for your questions!