Re: Net Meter [radio station bit rate] tutorial please? I want to nail this????????

<jamie_p84@xxxxxxxxxx> wrote in message
news:0af7e95c-28a7-462d-bcd0-9a5a0f56a70f@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jun 17, 10:32 pm, "DAB sounds worse than FM" <dab.is@dead> wrote:

Stop trying to make out you're teachng me stuff I don't already
know.

If you give people bad advice by failing to mention relevant issues,
then I shall automatically assume that you aren't aware of them.


The following post was the first time I mentioned NetMeter:

http://groups.google.com/group/alt.radio.digital/msg/4f792bbc76707c84?hl=en

and in it I wrote this:

"I'm not sure
whether the amount downloaded includes TCP/IP packet headers or not,
but headers are meant to account for as low a percentage of data
downloaded as possible to be efficient, so I doubt it would make much
of a difference - I might check that one day, actually."

If I'd have thought some student would have pedantically jumped on
what I was going to say a few days down the line, like you have done,
I would have stopped and thought about it and concluded that the total
downloaded would include TCP/IP packet headers. But don't try to make
out that I'm not aware that they create overhead, because the above
sentence shows that I have always been perfectly aware that they do.

Also, you said this about measuring the bit rate using NetMeter:

"but it's hardly suitable for his intended purpose"

That's bull***, because if you measure the bit rate of an Internet
radio stream and the bit rate measured is say 132 kbps, you can be
pretty confident that the actual bit rate of the stream is 128 kbps
(I've never come across an Internet radio station that doesn't use
CBR).

So NetMeter is a perfectly good tool to provide reasonably accurate
bit rate measurements.


TCP has absolutely no "error correction" whatsoever - it has error
*detection*, and it asks for packets to be re-transmitted that it
hasn't received or that are in error.

TCP uses a 16-bit checksum to detect errors and corrects them by
asking for the offending packet to be resent, storing any newer
packets in the meantime, and then rearranging them in the correct
order. It does this in order to correct errors. If you choose to be
pedantic and insist on calling it "error detection" instead, then I
couldn't care less.


This is what you said:

"TCP has overhead because it includes extensive error correction,
packet management and congestion control."

What on earth could you mean by "extensive error correction" if you
didn't mean "error correction", especially when you also said in the
same sentence that it provides "packet management", because it is
actually the packet management feature of TCP that ensures that the
stream delivered to the application layer is error-free.

Sorry, you fucked up yet again.


It is used almost exclusively for streaming
media where it doesn't matter if a few bits get corrupted - the
listener/viewer may experience a small glitch in the playback, but
this is not fatal.

Thanks for trying to teach me things I already know.

If you had know about it, you'd have explained it to Neil in the
first
instance.


Neil hasn't managed to calculate what the bit rate is yet from figures
showing the amount downloaded and the time that the stream was
running, so there was no point in confusing him further by saying that
the bit rate that he was trying to calculate won't be deadly accurate
due to the existence of TCP/IP packet headers.


BTW, could you explain what you meant in your previous post:

"TCP has overhead which means extra data is being transferred in
addition to the audio stream (UDP doesn't, but it still has some
headers etc and, in any event, lots of audio streams still use
TCP)"

It makes no sense. You say that UDP doesn't have overhead, but it
still ahs some headers. WTF do you think headers are other than
overhead??

It was supposed to say "TCP has considerable overhead". OMG I missed
out a word - you are master of the internet!


Oh, how convenient that you now say that you merely missed a word out.


FYI, here's the UDP and TCP header formats:

http://www.networksorcery.com/enp/protocol/udp.htmhttp://www.freesoft.org/CIE/Course/Section4/8.htm

Remember there's also the IP packet header, and the network access
layer header, and the application header as well (if applicable).

Too much googling and too little clue, I'm afraid. Netmeter doesn't
measure data below the TCP layer, so the network access layer header
data is irrelevant.


At the end of the day, NetMeter is supposed to measure how much data
has been downloaded, for example to help people measure how much
they've downloaded to make sure they stay within their bandwidth caps,
so you would expect that NetMeter would measure the amount of data
downloaded at a lower layer than the transport layer. It is certainly
possible to measure at the internet layer, and I think it would be
possible, or it would be possible to infer how much has been
downloaded at the network access layer as well if NetMeter can figure
out which protocol is being used for the connection from the user to
the ISP, because you could then add the frame headers to the amount of
data downloaded at the "top" of the network access layer, because the
size of the frame headers are known from the protocol used.

If you doubt that it is possible to measure the amount of data
downloaded at the network access layer, I suggest you read this:

http://www.winpcap.org/

"WinPcap is the industry-standard tool for link-layer network access
in Windows environments: it allows applications to capture and
transmit network packets bypassing the protocol stack"


At the end of the day, going back to the original issue of whether
you
can use NetMeter to measure bit rate levels: if you measure a
stream
and the bit rate works out to be say 132 kbps, you can basically
assume that the audio bit rate is actually 128 kbps (assuming it's
a
CBR audio stream).

Using your NetMeter method you have no way of telling:
- whether it's a CBR stream or not


I've yet to come across an Internet radio stream that doesn't use CBR,
so I'd say it's a good guess that it woudl be.


- whether UDP or TCP is in use


You can look up what connections are active and what protocols they're
using with netstat.


- the UDP datagram length where applicable


That isn't very important - it's the averages you're interseted in.


- the TCP error rate where applicable


You can find out how many TCP errors there have been using netstat.


- whether anything else is using the network interface at the same
time


Assuming you don't have any P2P programs running, the amount of data
downloaded on other connections wouldn't be all that big.

I return to what I've said before, which is that using NetMeter alone
you can figure out with reasonable confidence what the bit rate of a
CBR Internet radio station stream will be from the average bit rate
measured. I've just tested this with a downloaded file and zeroed the
totals downloaded in NetMeter. The file I downloaded was 78.3 MB in
size, and NetMeter said that it had downloaded 83.2 MB. That works out
to be a 6% overhead.

1.06 x 128 kbps = 135 kbps

If you measured an Internet radio station stream for a few minutes and
you calculated that the average bit rate was 135 kbps, you would be
confident that the stream bit rate would actually be 128 kbps. The
same thing goes for other bit rates. I measured another audio stream a
couple of days ago, and it worked out to have a bit rate of about 33
kbps. It was an audio stream, so what's the betting that the bit rate
was actually 32 kbps? I'd say the betting would be very high.

This is about common sense, basically.


- other factors which I can't be bothered to list.
so the figures derived from it are useless.

Basically, your advice was typically useless and retarded


Totally wrong. My advice has been fine. See above. If you disagree,
you're either innumerate or you have no common sense.




--
Steve - www.digitalradiotech.co.uk - Digital Radio News & Info

The adoption of DAB was the most incompetent technical
decision ever made in the history of UK broadcasting:
http://www.digitalradiotech.co.uk/dab/incompetent_adoption_of_dab.htm


.

Loading