I've added ability to optionally change the packet size with the help of
an environment variable, the executable is always the same.
(The technical details comes after the stat.)
Unfortunately, my application is quite complex, multi-threaded, contains
many layers (video4linux, DSP h264 encoder, ...) and at the moment I
cannot refine the statistics results by leaving only Live part of
application. But the results show big user space numbers (regarding to
the system time) for the default maxPacketSize value.
Here are results (using time utility from BusyBox; tries are separated
by slash in each row):
Default (1456, see MultiFramedRTPSink ctor):
User time (seconds):
43.08 / 46.08 / 33.89 / 46.28 / 53.94
System time (seconds):
47.82 / 28.30 / 43.79 / 24.22 / 23.69
Percent of CPU this job got:
71% / 58% / 61% / 55% / 61%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 7.84s / 2m 7.60s / 2m 6.85s / 2m 7.01s / 2m 6.30s
PACKET_SIZE=2048:
User time (seconds):
29.05 / 18.41 / 47.89 / 11.57 / 17.63
System time (seconds):
37.08 / 47.18 / 24.31 / 55.67 / 36.48
Percent of CPU this job got:
52% / 51% / 56% / 52% / 42%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 7.13s / 2m 7.67s / 2m 7.23s / 2m 7.22s / 2m 6.94s
PACKET_SIZE=4096:
User time (seconds):
25.21 / 18.73 / 23.99 / 6.71 / 21.29
System time (seconds):
32.76 / 20.99 / 26.58 / 37.43 / 23.52
Percent of CPU this job got:
45% / 31% / 39% / 34% / 35%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 6.96s / 2m 7.34s / 2m 7.22s / 2m 6.54s / 2m 7.93s
PACKET_SIZE=8192:
User time (seconds):
14.95 / 24.76 / 17.58 / 27.76 / 5.37
System time (seconds):
26.12 / 17.87 / 23.20 / 13.47 / 36.20
Percent of CPU this job got:
32% / 33% / 32% / 32% / 32%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 7.14s / 2m 6.98s / 2m 6.95s / 2m 6.70s / 2m 7.34s
PACKET_SIZE=12288:
User time (seconds):
4.10 / 5.41 / 5.56 / 15.13 / 9.53
System time (seconds):
6.90 / 34.60 / 34.42 / 15.99 / 15.95
Percent of CPU this job got:
8% / 31% / 31% / 23% / 20%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 6.94s / 2m 7.21s / 2m 6.50s / 2m 9.88s / 2m 6.83s
PACKET_SIZE=16384:
User time (seconds):
5.29 / 4.94 / 9.72 / 11.84 / 5.67
System time (seconds):
8.22 / 7.20 / 9.44 / 11.58 / 5.76
Percent of CPU this job got:
10% / 9% / 14% / 18% / 9%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 7.15s / 2m 7.14s / 2m 8.81s / 2m 6.59s / 2m 6.95s
PACKET_SIZE=20480:
User time (seconds):
24.05 / 22.31 / 33.34
System time (seconds):
14.58 / 19.66 / 5.85
Percent of CPU this job got:
30% / 32% / 30%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 6.69s / 2m 10.02s / 2m 6.83s
PACKET_SIZE=32768:
User time (seconds):
13.09 / 3.91 / 19.72 / 5.83 / 15.28
System time (seconds):
25.89 / 23.16 / 16.80 / 7.74 / 25.00
Percent of CPU this job got:
30% / 21% / 28% / 10% / 31%
Elapsed (wall clock) time (h:mm:ss or m:ss):
2m 7.51s / 2m 7.72s / 2m 6.64s / 2m 6.66s / 2m 6.64s
Thech details:
Stream: H264 25fps 1920x1080, ~2500000 bytes/sec
root@target:~ uname -a
Linux cvms-cam 2.6.32.24-davinci1-00205-gbc35ad4-dirty #3 PREEMPT Tue
Jun 23 10:31:35 CEST 2015 armv5tejl GNU/Linux
root@target:~ cat /proc/cpuinfo
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 215.44
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5
root@target:~ /usr/bin/time --help
BusyBox v1.22.0 (2015-05-19 11:47:11 CEST) multi-call binary.
Cross-compiler GCC on the host: arm-none-linux-gnueabi-gcc (Sourcery G++
Lite 2009q3-67) 4.4.1
Parameters of the compilation:
arm-none-linux-gnueabi-g++ -c -Iinclude -I../UsageEnvironment/include
-I../groupsock/include -I. -Os -DSOCKLEN_T=socklen_t
-D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64
-DALLOW_RTSP_SERVER_PORT_REUSE -march=armv5te -mtune=arm926ej-s
-fdata-sections -ffunction-sections -fPIC -DPIC -Wall -DBSD=1 Media.cpp
Best regards,
Max
On 07/23/2015 09:39 PM, Ross Finlayson wrote:
> Increasing the maximum packet size (up to some value < 2^16 bytes) can
> be a good idea if you’re planning to stream only over a LAN. If,
> however, you’re planning to stream beyond a single LAN, then you
> should be aware that some routers (and/or firewalls) may limit the
> size of network packets that they can forward. In that case your
> (larger) packets might not get forwarded at all.
>
> As you noted, increasing the packet size reduces the number of network
> packet sends that get done, and thus improves performance (though
> probably mostly due to to reduced OS overhead, not reduced overhead in
> the LIVE555 code).
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel@lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
