We have been using DSS, Preview3 on Linux 2.4.0(test8) for several weeks,
using SpamPro 3.0Preview[v240] Oct 7, 2000. We have been testing DSS
behavior under high and low stream counts, and noticed inconsistencies in
the number of active clients (e.g. RTSP and RTP connections) reported by
SpamPro and the DSS administrator / WebStat URL. Specifically, if we start
SpamPro with 50 clients with the same URL (on a single machine), we get:
Active Playing Attempts Success Errors Failed
...
50 50 50 0 0 0
...
The clients are all running the same 60 minute 20k stream. The SpamPro log
file (enabled in spampro.conf) has no entries as SpamPro continues scrolling
the same numbers, leading us to believe 50 clients should be running with no
errors or problems.
Now when we go to DSS Admin, we might see 50+ clients at first, but over the
next few minutes we see this number vascillate -- 45, 50, 35, 32, 38, 40
... When we check the DSS error logs, nothing is output concerning any
problems, and the SpamPro output is always clean. This problem gets worse
when we add thousands of streams -- the difference between what SpamPro
reports and what DSS Admin reports differs by up to 75%. We also note that
if a heavily loaded SpamPro App crashes (lack of resources, segmentation
fault, or whatever), DSS Admin reports those streams until the 60 second
timeout elapses, after which it cleans them up. When we select spampro.conf
to "loop", failed clients can get restarted, resulting in a temporary
erroneous stream count (DSS reports more streams than could possibly be
playing), but the apparent severe undercounting of streams by DSS Admin is a
mystery.
When SpamPro exits, we get a completed "spam.log" file which also has
interesting results:
"
Client Complete. IP addr = ..., URL=...
"
Most lines indicate the client completed "normally", but the packets
received number, and bandwidth numbers, are only half (or less) the expected
number on some clients. There are no port numbers associated with clients
(in the spam.log file), so there is no practical way to examine an ethernet
capture trace to determine exactly how many packets actually made it across
the wire. QTFileInfo tells you how many RTP packets to expect (for audio,
video tracks) for the hinted file, and many clients report this number as
expected. How can some clients report half as many with no indication of
errors or lost frames? Is it the result of "thinning"?
We have also run the test code for .rtp files (packets on disk). In this
case, we get numerous errors with:
"
Client Complete. IP addr = ..., URL=.../spampro.mov.rtp
Connection Status: Disconnected while playing.
"
We tried to disable disconnect logic in the xml config files (by setting
very large maximum_connections, maximum_bandwidth, safe_play_duration 0,
etc). Is there anyway to debug the reason for disconnection? (This happens
with more than 50% Idle CPU and plenty of available memory for DSS.)
Also,
"
Connection status: Failed RTSP request. Failed request status: 415
"
If this status follows the codes from RTSP specs (RFC 2326, April '98, sec
7.1.1), 415 is "Unsupported Media Type". This seems bogus since hundreds of
streams with the same URL were opened and completed normally.
Can anyone shed light on these questions? Is there any FAQ or documentation
on SpamPro? Will the source for SpamPro ever be opened? Are there any
reliable open tools with similar functionality to SpamPro?
Thanks,
Don
