Basic questions about telecommunications

On 1/1/2011 7:25 PM Jeff Liebermann spake thus:

What Firefox add-on? Didn't you read through the thread? The speed reporting is from my firewall, Sygate Personal Firewall.

I just went to find their website and was dismayed to find out they've been bought out by Norton (ugh):

On 1/1/2011 4:19 PM Jeff Liebermann spake thus:

Regarding that: I looked at the first site and am intrigued, but don't understand something. I see you need a host and client to make this work, which makes sense, and as you point out you might (or might not) be able to use someone else's web-based host; but if not, what then? Can you somehow set up both host and client on your computah and have the packets make a "round trip"? (Although that would be a problem since I notice my upload speeds are a lot slower than download.) How would I use this to test my dial-up connection?

Also, do I want to test using TCP, UDP or both? Which are used when I talk to my ISP?

If you can't find an iperf server, you're stuck. I did some quick Googling and couldn't find one that's publicly accessible.

I use IPerf and JPerf mostly for local wireless testing. I setup one machine to act as a server, and test thruput via wireless under various conditions. For testing a dialup connection, you would need an IPerf server located at your ISP or somewhere on the internet. I could set a temporary server here, at my house, but you would be limited to my 384Kbit/sec DSL outgoing thruput. Probably good enough for a dialup modem test. If you want to try that, please let me know.

No. It's not possible to use one computer for both a client and server. Well, actually, I haven't tried it, but I suspect there will be problems.

Do TCP and forget about UDP for now. UDP testing is tricky and sometimes results in bizarre results. TCP is reliable.

I just re-read all 10 of your messages in this thead and did not see Sygate mentioned anywhere. Unless there was an article that didn't appear on Giganews, I don't believe you mentioned that the graph came from Sygate. You did mention that your "test application" was Firefox, which is why I guessed that it was an add-on.

The mediocre shall inherit the earth.

I was going to try and duplicate your setup, but with such an old program, it's not going to happen. Sorry, but I've gone as far as I can trying to explain why you're seeing those variations in speed.

Try this speed test:

It's not a nice neat graph as you were expecting, but it does give repeatable tests from a well connected server. I'll see if I can find another server that gives repeated data suitable for graphing.

This looks like a likely candidate:

No clue if it works with W2K.

On 1/2/2011 12:03 AM Jeff Liebermann spake thus:

I did try it. Interesting.

The test ran fine, but I was surprised to see the Java speed indicator zoom up to ~700 kbps. I figured there was something perhaps bogus about the speed test, but then I noticed that my Sygate monitor window also showed speeds I'd never gotten before; the incoming (download) speed went up to something like 120 K. Remember, my speeds usually bounce between ~4 and ~6 K here.

So now I'm really confused. Are these transfer rates real? Remember, I'm on a 56K modem.

Here's what they reported:

Your download capacity of 627 kbps is very low compared to most broadband connections.*

Your upload capacity of 493 kbps is acceptable.

Your Quality of Service was measured at 30%, which shows that your connection is unable to produce a constant stream of data.

• Except, of course, that I don't *have* a broadband connection!

Regarding your generous offer to perhaps set up a host for me to use to check speeds, thanks, but remember this is just idle curiosity on my part.

If I ever have a real problem, maybe I'll take up your offer, and then I'll really owe you one.

It's accurate. As someone else mentioned the modems break the data into packets as it is sending the data down the line. The data in each packet is compressed before being sent.

If the speed test were to send truely (or close to it) random packets of 1024 random 8 bit patterns, they would travel at less than rated speed down the line because there is overhead in packetizing the data, adding checksums, etc.

If the speed test sends a simple pattern, constantly repeated, then the modems will compress it to a very small string and send that string down the line, recreating at the far end.

So by analyzing packet timestamps, you could see that a 1k packet of data comes down the phone line to the modem at some enourmous rate of speed, say

So it would show up as a very fast line with lots of instability in performance, which in this case it is.

In a case with a more random spread of data, it would perform more to your expectations.

If you wish to have a real test of how well your line performs, find a site that lets you download video files and time downloading one from start to finish. As far as modem compression algorythms, video data is almost

I also would check carefully what you are paying for the combination of telephone usage ISP charges. I understand the US is a telecom company's regulatory paradise, but in many places in the world, a cheap broadband connection has been cheaper than a dial up for many years.

Geoff.

It may very well depend on what data they're sending in their test.

Most modem connections incorporate V.42bis data compression. The sending modem compresses the data before transmitting it, and the receiving modem decompresses after validating the CRCs in the data frames.

The effectiveness of the data compression will depend on the data being sent. HTML, other ASCII text, etc. will usually compress fairly well (2:1 isn't uncommon), test data consisting of just a single byte (e.g. zeros) repeated over and over will compress *extremely* well, and pre-compressed binary data (e.g. .zip archives, .png and .jpeg and .mpg files) usually won't compress at all.

If the upload and download speed test consists of TCP streams full of zeros or some other constant data, you could be getting extremely high compression ratios, and thus an artifically-high link throughput number.