I don't think the problem is limited to when hundreds of megabytes are being transmitted.  I believe I am experiencing a problem with the same root cause whose symptoms are slightly different.  It seems like there's a threshhold which causes not merely poor performance, but likely an unrecoverable fault.

Here's the output when I run my example on SLES11.1:

$ ./multiproc.py $((8*1024)) 2
on 2.6 (r26:66714, May  5 2010, 14:02:39) 
[GCC 4.3.4 [gcc-4_3-branch revision 152973]] - Linux linux 2.6.32.12-0.7-default #1 SMP 2010-05-20 11:14:20 +0200 x86_64 x86_64
0 entries in flight, join() took 5949.97 usec, get() did 0.000000 items/sec
2 entries in flight, join() took 1577.85 usec, get() did 42581.766497 items/sec
4 entries in flight, join() took 1966.00 usec, get() did 65536.000000 items/sec
6 entries in flight, join() took 1894.00 usec, get() did 105296.334728 items/sec
8 entries in flight, join() took 1420.02 usec, get() did 199728.761905 items/sec
10 entries in flight, join() took 1950.03 usec, get() did 163840.000000 items/sec
12 entries in flight, join() took 1241.92 usec, get() did 324720.309677 items/sec
...
7272 entries in flight, join() took 2516.03 usec, get() did 10983427.687432 items/sec
7274 entries in flight, join() took 1813.17 usec, get() did 10480717.037444 items/sec
7276 entries in flight, join() took 1979.11 usec, get() did 11421315.832335 items/sec
7278 entries in flight, join() took 2043.01 usec, get() did 11549808.744608 items/sec
^C7280 entries: join() ABORTED by user after 83.08 sec
...

I see similar results when I run this test with a larger step, I just wanted to get finer resolution on the failure point.