Is it possible to use python to get True Full Duplex on a Serial port? - conclusions

[Hendrik van Rooyen]

On Sunday 16 August 2009 08:20:34 John Nagle wrote:
> Hendrik van Rooyen wrote:
> > On Saturday 15 August 2009 14:40:35 Michael Ströder wrote:
> >> Hendrik van Rooyen wrote:
> >>> In the past, on this  group, I have made statements that said that on
> >>> Linux, the serial port handling somehow does not allow transmitting and
> >>> receiving at the same time, and nobody contradicted me.
>
>      Absolutely false.

No its true, if you open the serial port  with the standard open() instead of 
os.open().  And it is also true that I was not contradicted in the past. :-)

>
> >> Despite all the good comments here by other skilled people I'd recommend
> >> to determine whether the transmission line to the devices accessed
> >> support full duplex.
>
>      All standard PC serial ports are full-duplex devices.
>
I know this, and I started the thread because they would not work full duplex 
for me.

8< -------------------- pyserial baudot program  link -----------------------

> > You raise a good point, that is probably not well known amongst the
> > youngsters here, as simple serial multidropping has gone out of fashion.
>
>      Actually, no.  Dynamixel servos as used on the latest Bioloid robots
> are multidrop serial RS-485.  But outside the embedded world, nobody uses
> that stuff any more.  (Embedded is going Ethernet; it's overkill but
> works fine and is now cheap.)

Exactly - it is no longer part of mainstream fashion. We also still use RS-485 
because it is cheaper, and we have better control over timing.

I enclose two naive test implementations.
To run them you will need a loopback connector.
One can be made by shorting pin 2 and 3 together on the standard DB9.

The results are illuminating - on my development machine, (dual 64 bit, some 
gigs), the last lines look like this:

test.py:
The quick brown fox jumps over the lazy dog 1023
That took 3.91238284111 seconds - 3.82068636827 Millisecs per record, 
261.733077152 recs per sec
hvr at Linuxbox:~/dos/JOBS/sms/lib>
   
test1.py:
The quick brown fox jumps over the lazy dog 1023
That took 3.90402388573 seconds - 3.81252332591 Millisecs per record, 
262.293477185 recs per sec
hvr at Linuxbox:~/dos/JOBS/sms/lib>   

Almost no difference between the two implementations.
This is basically because there is enough processing power to keep the link 
running at full speed in both instances.

On the eBox, (486, 400MHz, 128Mb, no FP), the difference is startling:

test.py:
The quick brown fox jumps over the lazy dog 1023
That took 69.2863521576 seconds - 67.6624532789 Millisecs per record, 
14.7792453797 recs per sec
root at ebox:/home/user/sms/lib# 

About eighteen times slower than the development machine.

test1.py:
The quick brown fox jumps over the lazy dog 1023
That took 10.391780138 seconds - 10.148222791 Millisecs per record, 
98.5394211964 recs per sec
root at ebox:/home/user/sms/lib# 

Less than three times slower than the development machine.

The little processor + Slackware + python cannot keep the link busy.
Python, as a character handler, well let us say that it is suboptimal,
because saying that something sucks, sucks.
An almost seven times ratio between the implementations is not to be sneezed 
at.

So the conclusions I have come to are the following:

1)  Thou shalt not use ordinary python files for serial ports, on pain of 
death.
2)  Thou shalt strive mightily to minimize python calls, doing all in thy        
power to move away from character input to string input.
3)  Thou shalt expend real treasure for real processing power as there is no 
such thing as a free lunch.

I would like to thank everybody who took the trouble to respond to teach me 
the error of my ways.

- Hendrik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1.py
Type: application/x-python
Size: 1900 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20090816/153acdee/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.py
Type: application/x-python
Size: 1832 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20090816/153acdee/attachment-0003.bin>