Message123663
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. |
|
Date |
User |
Action |
Args |
2010-12-09 00:01:41 | Brian.Cain | set | recipients:
+ Brian.Cain, terry.reedy, jnoller, Ian.Davis |
2010-12-09 00:01:41 | Brian.Cain | set | messageid: <1291852901.9.0.891078333917.issue8426@psf.upfronthosting.co.za> |
2010-12-09 00:01:39 | Brian.Cain | link | issue8426 messages |
2010-12-09 00:01:38 | Brian.Cain | create | |
|