Hello Don,
Thanks for providing your feedback regarding use of
SpamPro. At this point, SpamPro is relatively new,
plus you were testing it against QTSS 3 Public Preview
(which is not yet complete and is still being worked
on and tuned here at Apple). Consider the SpamPro
v240 as also a "Public Preview" version of the tool...
> SpamPro 3.0Preview[v240] Oct 7, 2000
If you have a QTSS 2.0.1 GM server to test against,
you might want to try some of these same SpamPro client
tests against a 2.0.1 server.
This would give a little more information in determining
if the problem really is in SpamPro, QTSS 3 Public Preview,
or a combination of the two - by comparing how SpamPro
works against QTSS 2.0.1.
If you don't have time to re-run any of your tests
against a QTSS 2.0.1 GM server, that's alright, but
is something I'd consider doing. Internally at Apple
we are continuing to work on both QTSS 3 and SpamPro,
and are interested in all feedback and requests from
users.
--
Thanks again,
Billy Brown
>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
