Problems with read_eager and Telnet

Robi roberto.inzerillo at gmail.com
Mon Feb 28 21:46:40 CET 2011


> Given that FlightGear is a graphical flight simulatorhttp://www.flightgear.org/https://secure.wikimedia.org/wikipedia/en/wiki/FlightGear
> using a text terminal connection seems a bit odd,
> unless using it just to get/set configuration,
> in which case, speed should hardly seem an issue.

Right, I'm using it that way, I get/set properties changing them in
real time (I whish!).


> I presume you are using read_until(b'\n').
> read_until cannot return any faster than the server sends complete lines

Actually it's read_until('\n') (because it's python 2.6, anyway I know
what you meant with b'\n').
And yes, after today I've come to the conclusion that even read_eager
is of no use to me. I have to settle down for that poor telnet speed,
I can't get more than that :-( In fact, the telnet connection speed is
not the issue, it's the time FGFS spends in reading its internals and
answearing back to the telnet client.

I've made some tests, it looks like it doesn't matter how many fgfs's
properties I try and read with telnet at the same time with python, I
always have the same lag, I can even run multiple python instances of
the same script, in order to get/set those same amount of properties
in parallel, well ... result is I always get the same lag, it doesn't
even become slower.

In my test I run a simple loop, in each loop I do a telnet.write() and
a telnet.read_until('\n'). I get back results at 20Hz (that means I
get 120 write/read cycles in 6 seconds).
I repeated the same test doing three telnet.write() followed by three
telnet.read_until('\n') in each loop. Result is always 20Hz (but now
that means I get 120 loop cycles in 6 seconds, which is now 120x3
write/read cycles in 6 seconds).
I even run three instances of the same script at the same time (trying
to saturate fgfs's capabilities and find some limits). No luck (or
yes?!?), I always get a 20hz frequency.

My conclusion being, fgfs cannot answer back quicker than this: 20Hz.

This is quite poor for a quasi-realtime hardware interface (which is
in my intention).
Maybe it's enough for something ... I'll give it a try anyway and find
out what can be a usable scenario for such values.

I guees even telnet is not the best apporach to use for my project,
I'll keep experiencing.

Thank you all anyway, it's always a pleasure to share some
considerations and get back usefull hints.




More information about the Python-list mailing list